The address of this document is: http://www.perceptek.com.au/kteam/docs/sdd.html

Software Design Document

The MultiMahjong Project

K-Team

 

    Team Members:

    1. Michael Hart
    2. Victor Leung
    3. Joel Brakey
    4. Joanna Araminta
    5. Dean Cortinovis
    6. Long Tang
    		(Project Manager)
    (Technical Research)
    (Web Site Manager)
    (Secretary)
    (Client Liaison Officer)
    (Technical Research and Risk Manager)

    Abstract:

      MultiMahjong is a single/multi player Mahjong computer game. This document describes both the architectural and detailed design of the MultiMahjong system.

    Maintainer:

      Joel Brakey (jebr)

    Version Control:

      $Revision: 1.10 $
      $Date: 1999/10/25 07:15:30 $

 

 

Table Of Contents

  1. Introduction
  2. Design Methodology Chosen
    2.1 Booch Method
    2.2 K-Team's Implementation
  3. Module Designs
    3.1 System Overview
    3.2 MultiMahjongServer Module
    3.3 MultiMahjongClient Module
       3.3.1 UserGUI Module
       3.3.2 Game Module
       3.3.3 ComputerOpponent Module
    3.4 Shared Module
  4. Class Designs
    4.1 MultiMahjongServer Module
       4.1.1 MultiMahjongServer Class
       4.1.2 GamesList Class
    4.2 UserGUI Module
       4.2.1 UserGUI Class
       4.2.2 ActionPane Class
       4.2.3 StatusPane Class
       4.2.4 TabbedPane Class
       4.2.5 PlayArea Class
       4.2.6 GameTypeSelector Class
       4.2.7 MultiGameStarter
       4.2.8 MultiGameJoineer
       4.2.9 OnlineHelp
       4.2.10 ExceptionHandler
    4.3 Game Module
       4.3.1 Game Class
       4.3.2 Player Class
       4.3.3 Hand Class
       4.3.4 CombList Class
       4.3.5 Comb Class
       4.3.6 Payout Class
       4.3.7 Human Class
       4.3.8 Set Class
    4.4 ComputerOpponent Module
       4.4.1 ComputerOpponent
    4.5 Shared Module
       4.5.1 Referee
       4.5.2 RemoteReferee
       4.5.3 Registrar
       4.5.4 Observer
       4.5.5 PlayersObserver
       4.5.6 GamesObserver
       4.5.7 Moves
       4.5.8 Tile
       4.5.9 Wall
  5. Use Cases
    5.1 Starting A New Single Player Game
    5.2 Opening A New Network Game
    5.3 Joining An Existing Network Game
    5.4 Starting An Existing Network Game
    5.5 Setting Up The Game (Single & Multi Player)
    5.6 Playing A Game (Single & Multi Player)
    5.7 Leaving A Game (Single & Multi Player)
    5.8 Exiting The MultiMahjong Program
  6. Scenario Diagrams
    6.1 UserGUI Module
       6.1.1 Starting a New Single Player Game
       6.1.2 Starting a New Multi Player Game
       6.1.3 Joining an Existing Multi Player Game
       6.1.4 Creating the Playing Screen
    6.2 Game Module
  7. Traceability
  8. Glossary

Table Of Figures

  1. Figure 3.1.1 - Dividing the Level 1 DFD of the MultiMahjong System
  2. Figure 3.1.2 - Top Level Modules Of The MultiMahjong System
  3. Figure 3.2.1 - MultiMahjongServer Module
  4. Figure 3.3.1.1 - UserGUI Module
  5. Figure 3.3.2.1 - Game Module
  6. Figure 3.3.3.1 - ComputerOpponent Module
  7. Figure 3.4.1 - Shared Module
  8. Figure 4.2.1.1 - Layout Of The Playing Screen
  9. Figure 4.2.2.1 - Layout Of The ActionPane
  10. Figure 4.2.3.1 - Layout Of The StatusPane
  11. Figure 4.2.4.1 - Layout Of The TabbedPane
  12. Figure 4.2.5.1 - Layout Of The PlayArea
  13. Figure 4.2.6.1 - Layout Of The GameTypeSelector
  14. Figure 4.2.7.1 - Layout Of The MultiGameStarter
  15. Figure 4.2.8.1 - Layout Of The MultiGameJoiner

 

 

1. Introduction

    This document, the Software Design Document (SDD), gives a description of the design of the MultiMahjong system at both architectural and detailed levels.

    MultiMahjong is a product consisting of two programs - a MultiMahjongServer and a MultiMahjongClient. This Server/Client architecture will allow up to 4 players to play Mahjong against each other over a TCP/IP network. The MultiMahjongClient program will also allow 1 player to play in a stand-alone mode.

    To play the game, users will use the MultiMahjongClient. The MultiMahjongServer is to reside on a TCP/IP server and will communicate with MultiMahjongClients.

    The client requires the product for commercial purposes. The MultiMahjongClient program is to be sold to potential users and the MultiMahjongServer is to initially reside on a server owned or operated by the client.

    The client for this project is:

    Our team for the project is called K-Team and consists of:

      Joanna Araminta (jiar)
      Victor Leung (vhle)
      Joel Brakey (jebr)
      Michael Hart (mwhart)
      Dean Cortinovis (dcort) 
      Long Tang (lqkt)      		 Ph: 9889 4423
      Ph: 9706 1560
      Ph: 9859 6038
      Ph: 9859 5419
      Ph: 9798 2684
      Ph: 9540 8992

    The supervisor for the project is:

      Anthony Senyard (anthls)  Ph (W): 9344 1940
      Ph (H): 9417 2839

    The Quality Assurance Reviewer for this document is:

    This document contains many references to the rules of Mahjong, specifically the Chinese rules of Mahjong. It is assumed that the reader of this document is familiar with these rules as many of the requirements are Mahjong specific. These rules can be found in the following book:

      Carkner, K.J. "How to play Mah Jong",
      1993, Penguin Books Australia Ltd.

    It is assumed that the reader has read the Software Requirements Specification document for the MultiMahjong System (http://www.perceptek.com.au/kteam/docs/srs.html) as the design for this system is based on these requirements.

    The SDD is an iteration of the Software Architectural Design Document (SADD). The SADD is no longer valid to the MulitMahjong system and it has been superseded by this SDD. This SDD includes both architectural and detailed design of the MultiMahjong system. The SADD was just used for the initial design steps as specified by step 3 of the Booch method (see Section 2.1) and should be disregarded.

    Design decisions made during the design of the MultiMahjong system are recorded in the Design Notebook. Please refer to this notebook to see why the particular designs that appear in this SDD were chosen.

    Much of the design of the MultiMahjong product relies on the semantics of the Java 2 programming language (also known as JDK 1.2), as this is the programming language being used to develop the product. As such it is also expected that the reader is familiar with the language, and more specifically with the RMI and Swing APIs that Java provides.

2. Design Methodology Chosen

    2.1 Booch Method

      The design methodology we have used is the Booch method of Object Oriented design. In the SRS we have completed the first stage of the Booch method's macro process. This stage is:

        1. Establish core requirements (conceptualisation), (see SRS Section 4)

      In this SDD we have included the next 3 stages of the Booch method's macro process:

        2. Develop a model of the desired behaviour (analysis), (see Section 5)

        3. Create an architecture (design), (see Section 3 and Section 4)

        4. Evolve the implementation (evolution), (see Section 4)

      The final stage of the process is not covered in this document. This stage is:

        5. Manage post delivery evolution (maintenance)

      Stage 2 involves a process whereby a model of desired behaviour is formed from the core requirements from Stage 1. Stage 3 involves the creation of a system design to fit the model of desired behaviour. The parts of this system design are then refined during Stage 4, the evolution phase. Stage 5 concerns the maintenance of the product after it has been delivered and this is not the responsibility of K-Team.

      To complete the macro stages, the Booch method proposes various micro processes to give an object oriented representation of the various parts of the system. These micro processes include:

        1. Identify the classes and objects at a given level of abstraction.

        2. Identify the semantics of these classes and objects.

        3. Identify the relationships among these classes and objects.

        4. Specify the interface and then the implementation of these classes and objects.

      For more information about the Booch method of design please visit the following sites:

    2.2 K-Team's Implementation

      In this document, K-Team will show the following steps with which we implemented the Booch method (see Section 2.1) to design the MultiMahjong System:

        Architectural Phase:

          1. Split the MultiMahjong System into manageable modules (based on SRS), as part of Stage 3 of the macro process.

          2. Develop scenarios of desired behaviour (based on SRS), as part of Stage 2 of the macro process.

          3. Determine the main classes needed to fulfil the scenarios from Step 2 and group them into corresponding modules from Step 1, as part of Stage 1 of the micro process.

          4. Identify the main responsibilities of these classes, as part of Stage 2 of the micro process.

          5. Identify the relationships between the classes, as part of Stage 3 of the micro process.

          6. Refine Step 2 so that the responsibilities and relationships of the classes are now used to represent the desired behaviour in use cases, as part of Stage 4 of the micro process.

      At this point in the design we created a disposable prototype of the MultiMahjongClient program. This enabled us to learn the Java language and validate our architectural design, especially the user interface. We then moved on to a more detailed phase in our design process, which was helped by the knowledge gained from the prototype.

        Detailed Phase:

          7. Refine Steps 4 and 5 to specify the fields, constructors and methods of each class, as part of Stage 2 of the micro process.

          8. Evolve the use cases from Step 6 into scenario diagrams using the methods from Step 7, as part of Stage 4 of the macro process.

          9. Determine Mahjong specific algorithms that will be used in the methods specified in Step 7, as part of Stage 2 of the micro process.

          10. Determine the Java package structure based on the modules from Step 1, as part of Stage 4 of the micro process.

          11. Create Java stub files with empty fields, constructors and methods mentioned in Step 7 and give descriptions of these using Javadoc commenting. These descriptions include parameters, return types and pseudo code of the algorithms from Step 9. This step is part of Stage 4 of the micro process.

      After creating the stubs, we could then proceed to the implementation phase, which involves writing the source code required to implement our design so far. As this document is an evolving document, it relies on the implementation of the code and any redesigning necessary during this phase.

        Implementation Phase:

          12. Try to fill in the Java source code for the stubs so that each class fulfils its responsibilities, as part of Stage 4 of the macro process.

          13. If Step 12 failed at a certain point, then we must redesign. Trace backwards from Step 11, redesigning along the way, until we reach an appropriate level of abstraction where we think the design problem may be able to be fixed. After attempting to rectify the design flaw traverse through the steps again.

      Section 3 of this document shows the split up of modules, the classes in each module and the relationships of these classes determined from Steps 1, 3 and 5. Section 4 shows the descriptions of each class and the responsibilities that they have determined from Step 4. Each class description also has links to more detailed descriptions of the fields and methods determined from Steps 7, 9, 10 and 11. Section 5 shows the use cases generated from Steps 2 and 6. Section 6 shows the scenario diagrams from Step 8, and Section 7 shows the relationship between the requirements from the SRS and the designs in this document.

      Steps 12 and 13 produced "extra" classes that were necessary to implement our design using Java. These extra classes have either utility functions, or are part of some Java dependent structure. As such, they do not appear in any of our architectural design. Section 4 has links to these classes from the description of the class that uses them.

      All object and class diagrams in this document use Unified Modelling Language (UML) notation.

 

3. Module Designs

    This section shows how we divided the MultiMahjong sytem into modules and classes based on the description of the proposed system set out in the SRS. It also contains the class diagrams of each module that shows the relationships between the classes.

    3.1 System Overview

      To break the MultiMahjong System into separate, manageable modules, we split our proposed Level 1 DFD from the SRS (see SRS Figure 3.1.2) into 5 parts: MultiMahjongServer (MMS), MultiMahjongClient (MMC), Game, UserGUI, and ComputerOpponent (CO), as shown in the following diagram:

Figure 3.1.1 - Dividing the Level 1 DFD of the MultiMahjong System

      As can be seen from this diagram, the MMC module is an aggregation of the UserGUI, Game and CO modules. This diagram also shows that the entire system can be implemented using just the MMC module (and its sub modules), without the MMS module. This is because the MMC module represents the MultiMahjongClient program (see Section 1) and this program can play in a stand-alone mode. Likewise, the MMS module represents the MultiMahjongServer program (see Section 1), but this program is only used when users wish to play a multi player game and, as such, only needs to implement a small part of the system.

      The reliance of both the MMC and the MMS modules on similar functionality led to the creation of another module, the Shared module, which will give both programs access to this functionality.

      Our next step was to refine this by creating an object diagram to show the relationships between these modules, as shown in the following diagram:

Figure 3.1.2 - Top Level Modules of the MultiMahjong System

      The modality and cardinality of the objects in this diagram can be explained by the requirements set out in the SRS. Each game can have up to 3 COs (see SRS Section 4.2.4) and each MultiMahjongServer can support up to 10 Games at once (see SRS Section 5.5.2). As will be seen later, the UserGUI is the entry point for the MultiMahjongProgram and, as with most Java programs, it creates all of the other modules for the MultiMahjongClient to run. The MMS module does not have a GUI and so it is the entry point for the MultiMahjongServer program.

      The following sections show the design of the MMS module and the sub modules of the MMC module. The diagrams show the relationships, the aggregation, the inheritence, the cardinality and the modality of the classes in these modules. It also shows the relationships that the classes in the specified module have with the classes in the other modules. Classes in other modules are in grey, and they are surrounded by a grey dashed line indicating which module they are a part of.

    3.2 MultiMahjongServer (MMS) Module

      This module contains all the classes, excluding the classes in the Shared module, that are necessary to implement the MultiMahjongServer program as described in SRS Section 4.1.

      The following diagram shows the classes in the MMS module:

Figure 3.2.1 - MMS Module

      For a more detailed description of the classes in the MMS module, see Section 4.1.

    3.3 MultiMahjongClient (MMC) Module

      This module is the superset of the UserGUI, Game and CO modules.

      3.3.1 UserGUI Module

        This module contains all the classes required for the user to begin and interact with the MultiMahjongClient program. It will use a graphical user interace, which includes all the windows, panels, dialog boxes and their components necessary to begin, play and end a game of MultiMahjong.

        The following diagram shows the classes in the UserGUI module:

Figure 3.3.1.1 - UserGUI Module

        For a more detailed description of the classes in the UserGUI module, see Section 4.2.

      3.3.2 Game Module

        This module is responsible for playing a game of Mahjong. It keeps track of all of the information about all the players, the tiles and other Mahjong specific items.

        The following diagram shows the classes in the Game module:

Figure 3.3.2.1 - Game Module

        For a more detailed description of the classes in the Game module, see Section 4.3.

      3.3.3 ComputerOpponent (CO) Module

        This module is responsible for determining the moves that the CO will make. Due to the complexity of the MultiMahjong System, the requirements for the CO were minimal and as such, this module needs only one main class. However, the interface of this module is designed with extensibility in mind.

        The following diagram shows the class of the ComputerOpponent module:

Figure 3.3.3.1 - CO Module

        For a more detailed description of the classes in the CO module, see Section 4.4.

    3.4 Shared Module

      This module contains all classes that are used by and passed between the MMS and MMC modules. It avoids having to create classes in both modules that share similar functionality.

Figure 3.4.1 - Shared Module

      For a more detailed description of the classes in the Shared module, see Section 4.5.

 

4. Class Designs

    The following section gives a brief description of the classes in each module and the responsibilities these classes have. Each class description also has links to pages containing the detailed design of the class. This detailed design includes descriptions of the fields, constructors and methods used to fulfil their responsibilities.

    We decided to use Javadoc for recording our detailed design because it keeps the design of the classes up to date with the code. It enabled us to write comments in our stub files describing each field and method and convert these into the HTML files linked to by each class description.

    This section can be read at an architectural level by just looking at the description and responsibilities of each class. It can also be read at a detailed level by following the links that open up in a new window.

    4.1 MultiMahjongServer Module

      See Section 3.2 for a description of the MMS module.

      4.1.1 MultiMahjongServer Class

        Description:

          Begins the MultiMahjongServer program.

        Responsibilities:

          Initially, it creates a new Registrar with a reference to a new GamesList. Finally, it sets up the Registrar for RMI (a communicaton protocol allowing objects to communicate over a network). If it fails in the creation of the Registrar, the exception is caught and the program exits.

        Detailed Design Descriptions:

        SRS References:

          4.1.2, 4.1.3, 4.2.3, 4.2.6, 4.2.8, 4.2.9, 5.5.2

      4.1.2 GamesList Class

        Description:

          Stores and manages the list of games currently being played on the MMS.

        Responsibilities:

          GamesList has a list of type RemoteReferee, that represents a game being played by up to 4 MMCs. GamesList creates a new RemoteReferee and stores it in the main array every time a new game is requested by the Registrar.

          GamesList must also keep track of the MMCs that require updated information whenever a new game or player is added to the list. It keeps a list of GamesObservers and notifies them using RMI whenever a change is made. GamesObservers are added whenever an initial request is made for the entire list of games (when a user on an MMC wishes to join a game).

        Detailed Design Descriptions:

        SRS References:

          4.2.3, 4.2.6, 4.2.8, 4.2.9, 5.5.2

    4.2 UserGUI Module

      See Section 3.3.1 for a description of the UserGUI module. As many of the classes in this module involve graphical elements of the game, screenshots from the prototype (see Section 2.2) have been included to help enhance the description.

      4.2.1 UserGUI Class

        Description:

          The UserGUI class contains the main method and is responsible for starting the MMC. This class also serves as a centralised compartment for the storage of references to other specialised GUI-related classes.

        Responsibilities:

          During the early stages of the program, this class is responsible for displaying internal frames within the desktop pane. Three different internal frames have been envisaged, only one of which may be displayed at any one time:

          1. GameTypeSelector
          2. MultiGameStarter
          3. MultiGameJoiner

          The above internal frames will obtain information necessary for starting a game on this MMC. Such information will be obtained locally from the user via input fields, or remotely by connecting to the MMS. A Game object is created with the information obtained.

          The UserGUI class then creates the playing screen, which allows the user to interact graphically with the underlying game engine. The playing screen will be an ordinary panel occupying the entire window. The following diagram shows the layout of the playing screen (based on SRS Figure 6.3.1):

Click to EnlargeStatusPanePlayAreaTabbedPaneActionPane

Figure 4.2.1.1 - Layout Of The Playing Screen
(Click on an area of the screen to jump to the description of that class,
or click on the title bar to enlarge the whole image)

          After all initialisation is completed, the UserGUI class serves as a centralised compartment for the storage and retrieval of references to other specialised GUI-related classes. The advantage of this design is that all the references are kept in the one place, meaning that individual classes do not have to keep a whole list of their own references.

        Detailed Design Descriptions:

        SRS References:

          6.2, 6.3

      4.2.2 ActionPane Class

        Description:

          The pane containing the action buttons allowing the user to interact with the underlying MultiMahjong game engine.

          The following diagram shows the layout of the ActionPane:

Figure 4.2.2.1 - Layout Of The ActionPane

        Responsibilities:

          There are seven action buttons in this pane that allow the user to make a move. In order from top to bottom, these buttons allow the user to "Declare Kong", "Pickup", "Discard", "Chow", "Pung", "Kong" and "Mahjong"

        Detailed Design Descriptions:

        SRS References:

          4.3.2, 4.3.4, 4.3.5, 4.3.6, 4.3.15, 6.3.4.6, 6.3.4.7

      4.2.3 StatusPane Class

        Description:

          A pane containing a single text area, showing the status of the game.

          The following diagram shows the layout of the ActionPane:

Figure 4.2.3.1 - Layout Of The StatusPane

        Responsibilities:

          This text area displays two lines of text, and is scrollable. The most recent status message is displayed first, and the user may then scroll downwards to display older messages. Status messages are numbered in increasing order.

        Detailed Design Descriptions:

        SRS References:

          4.3.2, 4.3.13

      4.2.4 TabbedPane Class

        Description:

          A tabbed pane that contains three tabs - a "Scores" tab, a "Discards" tab, and an "Options" tab.

          The following diagram shows the different layouts of the TabbedPane:


    

Figure 4.2.4.1 - Layouts Of The TabbedPane

        Responsibilities:

          The "Scores" tab contains four rows, one for each player. Each row shows, from left to right, the player's icon, name and score.

          The "Discards" tab contains a scrollpane which manages a scrollable client. The scrollable client displays dead tiles in the order in which they were discarded.

          The "Options" tab contains a check box that would allow the user to toggle sound effects on and off is they were present in the game. It also contains a "Leave Game" button, which will display a leave game dialog if pressed.

        Detailed Design Descriptions:

        SRS References:

          4.3.12, 4.4.2, 6.3.5, 6.3.8

      4.2.5 PlayArea Class

        Description:

          The main playing area of the game that contains the graphical representation of the current state of the game.

          The following diagram shows the layout of the PlayArea:

Figure 4.2.5.1 - Layout Of The PlayArea (Click to enlarge)

        Responsibilities:

          To display to the user the Wall, the last discard, as well as the declared sets, concealed tiles and drawn tile for each of the four players. In addition, the wind, icon and name of each player will be displayed. A graphic will also be displayed next to the player's icon if the player is fishing for Mahjong. A wind-of-the-round indicator will be displayed next to the player who is East at the very start of the game.

        Detailed Design Descriptions:

        SRS References:

          4.3.2, 4.3.3, 4.3.7, 4.3.10, 6.2.1, 6.2.3, 6.3.4.1, 6.3.4.2, 6.3.4.3, 6.3.4.4, 6.3.4.5

      4.2.6 GameTypeSelector Class

        Description:

          Allows the user to start/join a game of MultiMahjong.

          The following diagram shows the layout of the GameTypeSelector:

Figure 4.2.6.1 - Layout Of The GameTypeSelector

        Responsibilities:

          A frame that allows the user to select the type of game to play and to enter their name and icon. In addition, if the user chooses to start a new game (single or multi player), they will also be allowed to set the score limit of the game. If the user chooses to begin or join a multi player game, they can specify which server the MMS program is running on.

          Choosing to create a new multi player game will create a MultiGameStarter and choosing to join a game will create a MultiGameJoiner. Both of these classes will get a Registrar passed to them so that they can communicate with the MMS.

        Detailed Design Descriptions:

        SRS References:

          4.2.1, 4.2.2, 4.2.3, 4.2.5, 4.2.7, 4.2.8, 6.3.6

      4.2.7 MultiGameStarter Class

        Description:

          An internal frame that forms a connection to the MultiMahjongServer and allows the user to monitor the players that have registered to join the current multi player game.

          The following diagram shows the layout of the MultiGameStarter:

Figure 4.2.7.1 - Layout Of The MultiGameStarter

        Responsibilities:

          The MultiGameStarter will be shown to the creator of the game, and will show the names and icons of all players that have registered to join the current multi player game.

          This frame will also provide a "Start Game" button which allows the game creator to start the game when there are at least 2 human players in the current game. The button will be disabled when the current game contains only 1 human player.

        Detailed Design Descriptions:

        SRS References:

          4.2.2.5

      4.2.8 MultiGameJoinerClass

        Description:

          An internal frame that forms a connection to the MultiMahjongServer and allows the user to monitor the list of games that are currently on the server.

          The following diagram shows the layout of the MultiGameJoiner:

Figure 4.2.8.1 - Layout Of The MultiGameJoiner

        Responsibilities:

          From this list, the user may select a game to join. The MultiGameJoiner will be shown to players who have requested to join an existing multi player game. It will show a list of all games running on the server. The name of the game creator, the limit, and the number of places remaining will be shown for each game.

        Detailed Design Descriptions:

        SRS References:

          4.2.6, 4.2.10, 6.3.7

      4.2.9 OnlineHelp Class

        Description:

          A Frame containing the online user manual.

        Responsibilities:

          It must display the user manual in HTML format when invoked.

        Detailed Design Descriptions:

        SRS References:

          4.3.13

      4.2.10 ExceptionHandler Class

        Description:

          Deals with all exceptions that are caught in the MMC.

        Responsibilities:

          This class must display a dialog box wwith an error message. It also provides a method for returning to the GameTypeSelector if the game must be interrupted and a method for quitting the program in the event of a really nasty glitch.

        Detailed Design Descriptions:

        SRS References:

          4.4.3, 5.2.1.1, 5.2.1.2, 5.2.2.1, 5.2.2.2

    4.3 Game Module

      See Section 3.3.2 for a description of the Game module.

      4.3.1 Game Class

        Description:

          The Game class has the responsibility of running and controlling a game of Mahjong. It does this by continuously running a loop that directs the play of each hand.

        Responsibilities:

          The Game class must know which Players are present on the MultiMahjongClient program that it is contained within. This is so at the beginning of each hand a Wall of tiles can be taken from the Referee and dealt to the appropriate Players. The Game is complete once four rounds have been played.

          One iteration of this class represents a player's entire turn. Each turn consists of two distinct stages. The first stage is where a Player is asked for a discard. The second stage is waiting for the current player to select a tile, and make their next move.

          In the first stage the Player can declare a Kong or add a tile to an existing exposed pung. If a Player is currently fishing and the later option is chosen then interaction with other MMC and the Referee will be needed. This will ensure that the tile can not be robbed. Each selected tile is therefore sent to the Referee in a Moves class to determine once a move is made. If however no one is fishing then the moves are collated and sent together with the discard to the Referee.

          If the player discarding is not present on the MMC then the Game will need to recognise this and wait until the discard is selected, when no Players are fishing. An alternative method will need to be run if a Player is fishing to retrieve declared and Pung to Kong moves from the Referee. Once a move is retrieved the Game will have the responsibility of extracting the contents from the Moves class and running the necessary changes to the player's Hand.

          In the second stage, ie after all player's present on the MMC (except for the player who discarded the last tile), will be asked to place selections for their next move, if it is possible. The Game will need to distinguish between which player's are asked to place a selection and then send these to the Referee. Once all players on the MMC have placed their selections the Game will wait on the Referee for the result to become available. The Game will then have the responsibility of running the selected move in the player's Hand.

          The game loop continues to run until a mahjong or exit flag is given. At the end of each hand(which is after a Player has gone mahjong) the game will need to invoke a method within the Payout class to display and update the scores.

        Detailed Design Descriptions:

          Game

          RetrieveMove - synchronises the interaction between Referee and the Game. When a discard tile is required to be received from another MMC, the Game waits in this class to receive the move.

          RetrieveRobKong - synchronises the interaction between Referee and the Game. When the selections for robbing the Kong have been sent to the Referee the result is sent to this class. The Game waits until notified that the result has been placed.

          RetrieveSelection - synchronises the interaction between Referee and the Game. Once all selections have been sent by the Game to the Referee it will call on this to wait for the selection determined to have the highest priority.

        SRS References:

          4.1.3, 4.2.3, 4.2.4, 4.3.1, 4.3.3, 4.3.4, 4.3.5, 4.3.6, 4.3.7, 4.3.8, 4.3.9, 4.4.1, 4.4.2, 4.4.3

      4.3.2 Player Class

        Description:

          This class forms the representation of a player in the game of Mahjong.

        Responsibilities:

          The main responsibility of the Player class will be to act as a bridge between the Game and Hand classes. Whenever a change needs to be made to the player's Hand the Game class will call the appropriate method in this class, which will in turn update the Hand. All changes to the player's attributes are then passed to the PlayArea class to update the screen.

        Detailed Design Descriptions:

        SRS References:

          4.2.2.1, 4.2.2.2

      4.3.3 Hand Class

        Description:

          The Hand class represents the hand of a Player (this includes both concealed and exposed tiles).

        Responsibilities:

          All processes that are necessary to maintain, observe and display the hand will be contained in this class. The Hand is re-initialised at the end of each round. After the Wall has been retrieved by the Game, tiles are drawn and inserted into the concealed hand.

        Detailed Design Descriptions:

        SRS References:

          4.3.1, 4.3.2, 4.3.4, 4.3.5, 4.3.6

      4.3.4 CombList Class

        Description:

          Searches through the concealed hand of a Player and extracts all possible combinations that the Hand can take.

        Responsibilities:

          Taking a Player's concealed hand, CombList will search across the hand until a tile has been found. Tiles are then both "grouped across" and "grouped up". Grouped across refers to collecting tiles with consecutive numbered faces. For example: bamboo 1, 2 and 3 form a group of tiles that have consecutive numbered faces. Group up refers to the collection of tiles with identical faces. For example: 3 identical tile faces of circles 1. Honour tiles are only grouped up.

          Tiles being grouped up are inserted at the one time, and tiles being grouped across are inserted individually. Therefore the Comb class is needed to be able to insert tiles into the next available space in an array.

          CombList also has the responsibility of checking for special Mahjong and Fishing hands. These special hands include the Wriggly Snake, Unique Wonder and the Gates of Heaven.

          Once a player has won with a Mahjong hand and if the hand doesn't form a special Mahjong, then the class will be called to convert the combinations into Sets that can be used by the Payout class. As a hand can take on several winning combinations, each will need to be checked for the highest possible score.

        Detailed Design Descriptions:

        SRS References:

          4.3.1, 4.3.7, 4.3.8

      4.3.5 Comb Class

        Description:

          The Comb class forms the storage for a single combination extracted from the hand.

        Responsibilities:

          As tiles are extracted from the hand, the class will insert the given tile into the next available position in the tile number and suit arrays. All inserting instructions will be made from the CombList class. Comb will be instructed with how many spaces to insert into and what to insert in it.

          During the game a combination will need to be checked for fishing or Mahjong. The Comb class makes these checks and returns appropriate flags for each situation.

          At the end of the round, the winning concealed hand will need to be converted into Set. This class will have the responsibility of running the conversion. The Sets are created and then returned to the Hand class for Payout.

        Detailed Design Descriptions:

        SRS References:

          4.3.1, 4.3.7, 4.3.8

      4.3.6 Payout Class

        Description:

          Calculates the Payout at the end of a hand. Calculates the score of a given hand.

        Responsibilities:

          At the end of a hand the Payout class is used to determine how much the winning player's hand scores, and how much all losing players must payout to the winner. It then displays this Payout and Scoring information to the user in a Window.

          It also calculates the score of a given hand, so the scores of different combinations of hands can be compared.

        Detailed Design Descriptions:

          Payout

          PayoutInfo - synchronises the interaction between the Game and PlayArea when the user must select to declare Kong, extend a Pung or discard.

          PayoutGUI - displays the payout information to the screen.

        SRS References:

          4.5.9, 6.3.5.4

      4.3.7 Human Class

        Description:

          The Human class represents the user on the MMC of the current game thread. All moves that require input from the user are made through this inherited class of the Player, and the requests are run in the UserGUI.

        Responsibilities:

          This class will perform two important input functions from the user. The first is to retrieve a discard tile. Once a move has been selected, the Tile is inserted into the Moves class and is passed to the Game to handle the action. The player is prompted for moves until a discard tile has been selected.

          The second important function is to search for possible moves with the last discarded tile. The player's Hand is searched for possible moves and if it is possible, Human will need to enable the corresponding button in the ActionPane. The checks that need to be made are draw tile, Chow (2 sides, 2 up, 2 down), Pung, Kong and if the Player is fishing, Mahjong. The user will then need to make their selection. This is retrieved and sent back to the Game.

        Detailed Design Descriptions:

          Human

          HumanSelection - synchronises the interaction between the Game and ActionPane when the user must make a selection on their next move.

          HumanDiscard - synchronises the interaction between the Game and PlayArea when the user must select to declare Kong, extend a Pung or discard.

        SRS References:

          4.3.1, 4.3.2, 4.3.3, 4.3.4

      4.3.8 Set Class

        Description:

          The representation of a set of tiles, ie Chow, Pung, Kong and Pair.

        Responsibilities:

          The Set class provides the storage for a single set. The set will contain a character representing the set type, the suit and tile number of the first tile in that set. It aids the Payout class in determining the score for a given hand of Sets.

        Detailed Design Descriptions:

        SRS References:

          6.3.5.4

    4.4 ComputerOpponent Module

      See Section 3.3.3 for a description of the ComputerOpponent module.

      4.4.1 ComputerOpponent Class

        Description:

          The ComputerOpponent class determines what moves computer opponents should make.

        Responsibilities:

          The ComputerOpponent class should determine what the most appropriate tile to discard is when it's their turn.

          When it's not the CO's turn it should decide whether to pickup a tile that has been discarded based on a system of ranking of moves.

          Where possible the CO should automatically Rob the Kong.

        Detailed Design Descriptions:

        SRS References:

          4.5.1, 4.5.2, 4.5.3, 4.5.4, 4.5.5, 4.5.6, 4.5.7, 4.5.10

    4.5 Shared Classes Module

      See Section 3.4 for a description of the Shared module.

      4.5.1 Referee Class

        Description:

          Referee is in charge of initialising the game and delivering the moves to each player.

        Responsibilities:

          The Game class has a reference to the Referee and it calls it to place the player's next move. The Referee also has references to all of the Observers, which in turn have references to the respective Game classes on each MMC.

        Detailed Design Descriptions:

          Referee

          RefereeIntf - an interface that is required by RMI to define the methods that can be called remotely

        SRS References:

          4.1.3, 4.1.4, 4.2.9, 4.3.3, 4.3.4, 4.3.5, 4.3.6, 4.4.3

      4.5.2 RemoteReferee Class

        Description:

          RemoteReferee extends Referee and provides extra functionality for adding players and starting the game remotely (ie from the MMC).

        Responsibilities:

          It contains a PlayersObserver that it receives when it is created and it contacts this class whenever a new player is added to the game.

        Detailed Design Descriptions:

        SRS References:

          4.1.3, 4.1.4, 4.2.9, 4.3.3, 4.3.4, 4.3.5, 4.3.6, 4.4.3

      4.5.3 Registrar Class

        Description:

          RegistrarImpl handles all requests by MMCs to create and join multi player games. This class communicates with the MMC using Java's Remote Method Invocation (RMI).

        Responsibilities:

          An MMC can make 5 different types of requests to this class:

          • Get the list of games playing on this MMS
          • Create a new multi player game to be played on this MMS
          • Join a multi player game on this MMS
          • Wait for the start of a game on this MMS
          • Start the playing of a game on this MMS

          When an MMC sends a request to get the list of current games, the RegistrarImpl gets all the games from the GamesList and returns them to the MMC.

          When an MMC sends a request to this class to create a new multi player game, the RegistrarImpl must instruct the GamesList to create a new RemoteReferee.

          When an MMC sends a request to join a particular game, the RegistrarImpl instructs the GamesList to add this MMC to that game.

          When an MMC sends a request to wait for the start of a game, the RegistrarImpl instructs the GamesList to go into a wait loop until another MMC starts the game.

          When an MMC sends a request to start a game, the RegistrarImpl instructs the GamesList to notfiy all the MMCs that are waiting and then the game can begin being played.

        Detailed Design Descriptions:

          RegistrarImpl

          Registrar - an interface that is required by RMI to define the methods that can be called remotely. RegistrarImpl implements this interface, hence the name RegistrarImpl.

        SRS References:

          4.1.2, 4.1.3, 4.2.3, 4.2.6, 4.2.8, 4.2.9, 5.5.2

      4.5.4 Observer Class

        Description:

          The Observer acts as a connection between the Referee and the Game classes whenever the Referee needs to send information to inform the Game of a change in the situation.

        Responsibilities:

          The Observer must place any player's moves into the Game whenever the Referee informs it that a new move is available

        Detailed Design Descriptions:

          Observer

          ObserverIntf - an interface that is required by RMI to define the methods that can be called remotely. RegistrarImpl implements this interface, hence the name RegistrarImpl.

        SRS References:

          4.1.3, 4.1.4, 4.2.9, 4.3.3, 4.3.4, 4.3.5, 4.3.6, 4.4.3

      4.5.5 PlayersObserver Class

        Description:

          PlayersObserver extends the Observer class and keeps the MultiGameStarter updated about any players that have joined the game that was created.

        Responsibilities:

          It is created by the MultiGameStarter and passed to the RemoteReferee when the MultiGameStarter creates the game. The RemoteReferee then uses this class to update the MultiGameStarter when changes to the list of players occur.

        Detailed Design Descriptions:

        SRS References:

          4.1.3, 4.1.4, 4.2.9, 4.3.3, 4.3.4, 4.3.5, 4.3.6, 4.4.3

      4.5.6 GamesObserver Class

        Description:

          GamesObserver extends the Observer class and keeps the MultiGameJoiner updated about any changes in the list of games on the MMS.

        Responsibilities:

          It is created by the MultiGameJoiner and passed to the GamesList when the MultiGameJoiner gets the list of games. The GamesList then uses this class to update the MultiGameJoiner when changes to the list of games occur.

          MiniGame is a minimal representation of a game used for transmitting between the MMC and MMS via RMI. It is just a data structure and as such, it just contains a constructor to initialise the data and public fields to store the data.

        Detailed Design Descriptions:

          GamesObserver

          MiniGame - a minimal representation of a game used for transmitting between the MMC and MMS via RMI.

        SRS References:

          4.1.3, 4.1.4, 4.2.9, 4.3.3, 4.3.4, 4.3.5, 4.3.6, 4.4.3

      4.5.7 Moves Class

        Description:

          The Moves class stores information on a move to be sent to theReferee.

        Responsibilities:

          The Move class is to be retrieved by other MMC to receive all the necessary information that will keep them up to date. The Moves class will contain the last discarded tile from the current player, a flag to signal for Mahjong and a list of Kongs that they may have declared.

        Detailed Design Descriptions:

        SRS References:

          None

      4.5.8 Tile Class

        Description:

          Representation of a Mahjong tile.

        Responsibilities:

          Just return information about itself when requested.

        Detailed Design Descriptions:

        SRS References:

          4.3.1

      4.5.9 Wall Class

        Description:

          A representation of the Wall in Mahjong.

        Responsibilities:

          Insert and retrieve tiles from itself in the correct order.

        Detailed Design Descriptions:

        SRS References:

          4.3.1

5. Use Cases

    After determining the modules and classes, we could then use these and apply them to the scenarios of desired behaviour from Step 2 (see Section 2.2) to create use cases, as specified in Step 6. This document does not list the scenarios of desired behaviour, as there would be too much repeated information between these and the use cases. Please see the design notebook for these scenarios of desired behaviour.

    This section gives a brief description of each use case and the SRS references it implements. Each use case consists of numbered steps that explain a possible scenario and how the responsibilities and relationships of the involved classes are used.

    5.1 Starting A New Single Player Game

      Description:

        When a user loads the MultiMahjong program, or Leaves a Game they had started, they are presented with a start game dialog box. This section describes how the MMC program is used to start a new single player game. This scenario begins from the execution of the application.

      SRS References:

        4.2.1, 4.2.4, 4.2.5, 6.2.1, 6.3.1, 6.3.2, 6.3.3, 6.3.6

    1. The user starts the MMC program. The main method in the MMC class instantiates the UserGUI class.
    2. The UserGUI object sets up the main application window and adds to it a specialised pane for managing internal frames.
    3. The Player and Preferences classes are instantiated with default values.
    4. The game type selector is presented to the user as an internal frame, centered in the main application window.
    5. Within the game type selector, the user selects "Start single player game" from the list of radio buttons. This enables the editable combo box, allowing the entry of the score limit.
    6. The user clicks on the drop-down combo box and selects an icon from the list. This causes a field in the Player object to be set.
    7. The user clicks on the one-line text field and enters their name. This causes a field in the Player object to be set.
    8. The user clicks on the editable combo box and selects (with the mouse) a recommended score limit. This causes a field in the Preferences object to be set.
    9. The user clicks on the [Next >>] button. The internal frame containing the game type selector is closed.
    10. Three (3) ComputerOpponent objects are created.
    11. The seating position of all the players is determined.
    12. A Referee object is created.
    13. The Game class is instantiated with information about the local referee, the players and their seating positions.
    14. The TabbedPane class is instantiated and creates a tabbed pane containing 3 tabs ("Scores", "Discards", and "Options"). The "Scores" tab will contain four rows, one for each player. Each row will show, from left to right, the player's icon, name and score. The "Discards" tab will contain a scrollable pane, which displays dead tiles in the order in which they were discarded. The "Options" tab will contain a check box for toggling sound effects on and off. It will also contain a "Leave Game" button.
    15. The ActionPane class is instantiated and creates 7 buttons ("Reveal Kong", "Pickup", "Discard", "Chow", "Pung", "Kong", and "Mahjong"), all of which are initially disabled.
    16. The WallPane class is instantiated. This pane is initially empty.
    17. UserPane, LeftPane, FarPane and RightPane are instantiated in turn. Each of these panes is initially empty except for the corresponding player's name and icon.
    18. The playing screen is added to the content pane of the main application window. This is an aggregation of the tabbed pane, action pane, status pane, wall pane, user pane, left pane, far pane, and the right pane.
    19. A method is invoked in the Game object, instructing it to start a new hand.

    5.2 Starting A New Multi Player Game

      Description:

        This section describes how the MultiMahjongClient program and MultiMahjongServer program interact in order for users to start a new multi player game. This scenario begins from the execution of the application.

      SRS References:

        4.1.1, 4.1.2, 4.1.3, 4.2.1, 4.2.2, 4.2.3, 6.1.1, 6.2.1, 6.3.2, 6.3.3, 6.3.6

    1. The Client (i.e. Solid Software) starts the MultiMahjongServer program on their computer via a command line prompt.
    2. The MMS class initialises the MultiMahjongServer and creates a Registrar to allow requests from MMCs to be made.
    3. The Registrar object, when created, creates a GamesList object to store all the games which are being played.
    4. The user starts the MultiMahjongClient program. The main method in the MMC class instantiates the UserGUI class.
    5. The UserGUI object sets up the main application window and adds to it a specialised pane for managing internal frames.
    6. The Player and Preferences classes are instantiated with default values.
    7. The game type selector is presented to the user as an internal frame, centered in the main application window.
    8. Within the game type selector, the user selects "Start multi player game" from the list of radio buttons. This enables the editable combo box, allowing the entry of the score limit.
    9. The user clicks on the drop-down combo box and selects an icon from the list. This causes a field in the Player object to be set.
    10. The user clicks on the one-line text field and enters their name. This causes a field in the Player object to be set.
    11. The user clicks on the editable combo box and selects (with the mouse) a recommended score limit. This causes a field in the Preferences object to be set.
    12. The user clicks on the [Next >>] button. The MultiGameStarter class is instantiated and the multi player game starter dialog is presented to the user as an internal frame, centred in the main application window. The internal frame containing the game type selector is closed.
    13. The multi player game starter dialog shows a "Connecting to server..." message as the MultiGameStarter attempts to create a reference to the RemoteReferee object on the server side.
    14. Once created, the RemoteReferee object randomises the tiles in the Wall and waits for the beginning of gameplay.
    15. The Registrar object tells the MultiGameStarter object that the game has been registered and is awaiting players to join. However, if too many games exist on the server the Registrar object will instruct the MultiGameStarter object to inform the user that too many games are being played on the server and that they should try to start a network game later or they can join another network game.
    16. The "Connecting to server..." message is replaced with a list of the names and icons of players who have joined the game thus far. Initially, of course, this will just consist of the name and icon of the game creator.
    17. A "Start Game" button is displayed below this list. This is initially disabled, since starting a multi player game with just one player is nonsensical.

    5.3 Joining An Existing Multi Player Game

      Description:

        This section describes how another user can join a game which has already been registered in the MultiMahjongServer program. This scenario follows on from the previous scenario (Section 5.2).

      SRS References:

        4.1.1, 4.1.2, 4.1.3, 4.2.1, 4.2.6, 4.2.7, 4.2.8, 6.1.1, 5.2.1.2, 6.2.1, 6.3.2, 6.3.3, 6.3.6, 6.3.7

    1. Another user, user2, starts the MultiMahjongClient program on a separate machine. The main method in the MMC class instantiates the UserGUI class.
    2. The UserGUI object sets up the main application window and adds to it a specialised pane for managing internal frames.
    3. The Player and Preferences classes are instantiated with default values.
    4. The game type selector is presented to the user as an internal frame, centered in the main application window.
    5. Within the game type selector, the user selects "Join multi player game" from the list of radio buttons. This disables the editable combo box, disallowing the entry of the score limit.
    6. The user clicks on the drop-down combo box and selects an icon from the list. This causes a field in the Player object to be set.
    7. The user clicks on the one-line text field and enters their name. This causes a field in the Player object to be set.
    8. The user clicks on the [Next >>] button. The MultiGameJoiner class is instantiated and the multi player game starter dialog is presented to the user as an internal frame, centred in the main application window. The internal frame containing the game type selector is closed.
    9. The multi player game joiner dialog shows a "Connecting to server..." message as the MultiGameJoiner uses RMI to inform the Registrar object in the MultiMahjongServer program that user2 wishes to join a multi player game.
    10. The Registrar objects calls the GamesList object to get the list of current games and returns this list to the MultiGameJoiner object.
    11. The "Connecting to server..." message is replaced with a list of currently available games.
    12. A "Join Game" button is displayed below this list. This is initially disabled, since it is not possible to join a game if one hasn't yet been specified.
    13. User2 finds a game which they want to join and clicks on that game to highlight it.
    14. User2 then clicks on the "Join Game" button. The MultiGameJoiner object then sends a message to the Registrar object, informing it of the game that user2 has joined.
    15. The Registrar object either sends back a failure message, or passes a reference to the RemoteReferee object back to the MultiGameJoiner object in user2's MultiMahjongClient program. Upon receiving this object, the MultiGameJoiner replaces the contents of the internal frame with a "Waiting for game to start..." message.
    16. The Registrar object informs the MultiGameStarter object in the original user's MultiMahjongClient program that an additional player has joined the game. This updates the list of players visible in the original user's MultiGameStarter and enables the "Start Game" button.

    5.4 Beginning Gameplay In A Multi Player Game

      Description:

        Once the user who opened a network game of MultiMahjong has had at least one other user join their game they can click a button to start the network game. This section describes how this occurs, and follows on from the previous scenario (Section 5.3).

      SRS References:

        4.1.1, 4.1.2, 4.1.3, 4.2.2, 4.2.3, 4.2.9, 6.1.1, 5.2.1.2, 6.2.1, 6.3.2, 6.3.3

    1. The original user clicks the now enabled "Start Game" button in the MultiGameStarter object, which in turn informs the Registrar object that the client has started the game.
    2. The Registrar object determines whether any client programs must host a ComputerOpponent. The Registrar then tells the MultiGameStarter/MultiGameJoiner of those programs they must contain a CO.
    3. The Registrar object tells the original user's MultiGameStarter object that the game has started and whether to create a ComputerOpponent.
    4. The Game class is instantiated with information about the remote referee, the players and their seating positions. The internal frame containing the MultiGameStarter is closed.
    5. The Registrar object tells user2's MultiGameJoiner object that the game has started and whether to create a ComputerOpponent.
    6. The Game class is instantiated with information about the remote referee, the players and their seating positions. The internal frame containing the MultiGameJoiner is closed.

      Then, on each MultiMahjongClient:

    7. The TabbedPane class is instantiated and creates a tabbed pane containing 3 tabs ("Scores", "Discards", and "Options"). The "Scores" tab will contain four rows, one for each player. Each row will show, from left to right, the player's icon, name and score. The "Discards" tab will contain a scrollable pane, which displays dead tiles in the order in which they were discarded. The "Options" tab will contain a check box for toggling sound effects on and off. It will also contain a "Leave Game" button.
    8. The ActionPane class is instantiated and creates 7 buttons ("Reveal Kong", "Pickup", "Discard", "Chow", "Pung", "Kong", and "Mahjong"), all of which are initially disabled.
    9. The WallPane class is instantiated. This pane is initially empty.
    10. UserPane, LeftPane, FarPane and RightPane are instantiated in turn. Each of these panes is initially empty except for the corresponding player's name and icon.
    11. The playing screen is added to the content pane of the main application window. This is an aggregation of the tabbed pane, action pane, status pane, wall pane, user pane, left pane, far pane, and the right pane.
    12. A method is invoked in the Game object, instructing it to start a new hand.

    5.5 Setting Up The Game (Single & Multi Player)

      Description:

        This section details how the MultiMahjongServer creates and sends game setup information to all client programs. These use cases are written for the MultiMahjongServer program because in single player mode a dummy server is used to handle the same tasks. This scenario follows on from the previous scenario (Section 5.4).

      SRS References:

        4.1.4

    1. When tile shuffling is complete and received from the Referee object, the Game object calls the UserGUI object so it updates The Wall, Wind Discs and Wind of the Round indicator on the screen.
    2. The Game object deals out each player's hand. As it does this, it updates the wall and each player's hand using the UserGUI object. At the end of this, the user can see the front of all their tiles, the back of everyone else's tiles, and the broken wall.

    5.6 Playing A Game (Single & Multi Player)

      Description:

        This section shows how a typical game of MultiMahjong is played. Again it is written for a multi player game where the MultiMahjongServer program is used, but in a single player game the tasks are handled internally by the client program using a dummy sever.

      SRS References:

        4.3.1, 4.3.2, 4.3.3, 4.3.4, 4.3.5, 4.3.6, 4.3.7, 4.3.8, 4.3.9, 4.4.1, 4.4.3, 4.5.1, 4.5.2, 4.5.3, 4.5.4, 4.5.5, 6.2.1, 6.3.8

      5.6.1 Starting the Game Loop

      1. The UserGUI calls for the Game to begin.
      2. The Game follows the scenario set out in section 5.5.
      3. Once the Game is set up the East player's Hand is checked for Mahjong. The East player is initially dealt 14 tiles and will therefore have a chance to Mahjong.
        3.1 A check for special Mahjong hands is made.
        3.2 A check for an ordinary Mahjong hand is made.
      4. All the other Players are dealt 13 tiles and will therefore only be able to be dealt a fishing hand. A check needs to be made for fishing before the Game starts. This will determine whether the Player has a standing hand.
        4.1 A check for special fishing hands is made.
        4.2 A check for an ordinary fishing hand is made.

        5.6.1.1 East Dealt a Mahjong Hand

        1. If either 3.1 or 3.2 of section 5.6.1 have occurred East has been dealt a Mahjong hand, and so the Game loop is not entered into. The hand has ended, and the scores and round of the Game are updated in the UserGUI class.
        2. A new Hand is created by the Game. All flags are reset, the Server reshuffles the Wall and new Hands are dealt to each Player.

        5.6.1.2 East not Dealt a Mahjong Hand and no Other Players are Fishing

        1. In this hand it is assumed that East has not been dealt a Mahjong hand and no other Players are fishing.
        2. The Game loop begins with a call to the East player to choose a discard if this Player is located on the current client thread.
        3. If East is not located on the current client thread then the Game loop will wait until the East Player has completed selecting all their moves and has chosen a discard tile.

        5.6.1.3 East not Dealt a Mahjong Hand and one Other Player is Fishing

        1. In this scenario it is assumed that 3.1 and 3.2 of section 5.6.1 are both false and that one of 4.1 or 4.2 are true. East is not dealt a Mahjong hand, however some other Players are fishing.
        2. The Game loop begins with a call to the East player to choose a discard if this player is located on the current client thread.
        3. If East is not located on the current client thread then the Game loop waits until the East player has selected a move.

      5.6.2 The Current Player Discarding a Tile with no Player Fishing

      1. The current Player has 14 tiles in their Hand and now must discard a tile. A signal is sent to the UserPane that the discard is required from the user, and the Game waits until the selection has been placed. All possible actions that the Player can make are indicated by the active buttons in the StatusPane of the screen.
        1.1 The StatusPane checks in the concealed Hand for any possible Kongs that will need to be eventually declared.
        1.2 The Declare Kong button will be activated on the display if this is the case.
        1.3 The StatusPane checks in both the exposed hand for Pungs and in the concealed hand for tiles that could possibly added.
        1.4 The Declare Kong button will be activated on the display if this is the case.
        1.5 The Discard button is automatically activated when ever the user must discard.
      2. The selected tile is checked for the possibility of Declaring Kong and extending the Pung into a Kong(Pung2Kong). If both are not possible with the selected tile, the button is deactivated.
      3. Every time the user selects another tile these checks are made, and the Declare Kong button is activated if the move is possible.

        5.6.2.1 East Discards the Tile

          This scenario follows from 5.6.1.2 and 5.6.2, and is when East decides only to discard a tile.

        1. The user selects a tile and presses the Discard button.
        2. Once the discard tile has been selected and the Discard button pressed the Game is notified of the event by the StatusPane. The selected tile is added to the Moves class and removed from the player's Hand.
        3. The current players Hand will now once again contain 13 tiles, and since the composition of the Hand has changed it will need to be checked for special or ordinary fishing hands.
        4. The Moves class is sent to Server so that it can be retrieved by other MMC.

        5.6.2.2 Player with Fishing Hand

          Following from the scenario in 5.6.2 and 5.6.2.1, the player's Hand is found to be fishing.

        1. The UserPane is updated to signal that the Player is fishing.
        2. The Moves class sent to server so that it can be retrieved by other MMC.

        5.6.2.3 Declaring a Kong

          This scenario follows 5.6.1.2 and 5.6.2, and is when the current Player declares a concealed Kong before making a discard.

        1. The player selects a tile and presses the Declare Kong button.
        2. Once the tile is selected and the Declared Kong button pressed, the Game is notified of the move. The tile is added to the Moves class. The selected tile is then used to search through the player's concealed Hand to reveal the Declared Kong. All four tiles are removed from the Hand and placed into the exposed Set.
        3. The UserPane is updated to reflect the changes to the player's Hand.
        4. The current player's Hand will now once again contain 13 tiles, and since the composition of the Hand has changed it will need to be checked for fishing.
          4.1 A check for special fishing hands is made.
          4.2 A check for an ordinary fishing hand is made.
        5. The Hand has been reduced back to 13 tiles without a discard being selected. A loose tile is therefore drawn from the honour Wall.
        6. The UserPane is updated to reflect the changes to the player's Hand.
        7. With 14 tiles now in their Hand, current player could have Mahjong. If item 5 was found to be true then the following checks will be made:
          7.1 A check for special Mahjong hands is made.
          7.2 A check for an ordinary Mahjong hand is made.
        8. Scenario 5.6.2 is again followed.
        9. The user selects a tile and presses the Discard button.
        10. Once the discard tile has been selected and the Discard button pressed, the Game is notified of the event by the StatusPane. The selected tile is added to the Moves class and removed from the player's Hand.
        11. The current player's Hand will now once again contain 13 tiles, and since the composition of the Hand has changed it will need to be checked for fishing.
          11.1 A check for special fishing hands is made
          11.2 A check for an ordinary fishing hand is made.
        12. The Moves class sent to Server so that it can be retrieved by other MMC.

        5.6.2.4 Fishing After Declaring a Kong

          This scenario forms an alternative to 5.6.2.3 from item 5, and assumes that the Player is fishing after Declaring the Kong.

        1. The UserPane is updated to signal that the Player is fishing.
        2. Continues from 5.6.2.3 item 5.

        5.6.2.5 Can Declare Another Concealed Kong

          This scenario forms an alternative to 5.6.2.3 from item 11, and assumes that the Player can Declare another concealed Kong.

        1. Scenario 5.6.2 is again followed.
        2. Scenario 5.6.2.3 is again followed.

        5.6.2.6 Extending an Exposed Pung after Declaring a Kong

          This scenario forms an alternative to 5.6.2.3 from item 11, and assumes that the Player can extend an exposed Pung with a tile in the concealed hand after Declaring the Kong.

        1. Scenario 5.6.2 is again followed.
        2. The player selects a tile and presses the Declare Kong button to Pung2Kong.
        3. Once the Pung2Kong tile has been selected, the Game is notified of the move by the StatusPane. The selected tile is added to the Moves class and run in the player's Hand. The selection is used to search and remove the tile from the concealed hand and the exposed Set is changed to a Kong.
        4. The UserPane is updated to reflect the changes to the player's Hand.
        5. The current player's Hand will now once again contain 13 tiles, and since the composition of the Hand has changed it will need to be checked for fishing.
          5.1 A check for special fishing hands is made.
          5.2 A check for an ordinary fishing hand is made.
        6. The Hand has been reduced back to 13 tiles without a discard being selected. A loose tile is therefore drawn from the honour Wall.
        7. The UserPane is updated to reflect the changes to the player's Hand.
        8. With the 14 tiles now in their Hand the current player could have Mahjong. If item 1 of 5.6.2.4 was found to be true then the following checks will be made:
          8.1 A check for special Mahjong hands is made.
          8.2 A check for an ordinary Mahjong hand is made.
        9. Scenario 5.6.2 is again followed.
        10. The player selects a tile and presses the discard button.
        11. Once the discard tile has been selected, the Game is notified of the move by the StatusPane. The selected tile is added to the Moves class and removed from the player's Hand.
        12. The current player's Hand will now once again contain 13 tiles, and since the composition of the Hand has changed it will need to be checked for fishing.
          13.1 A check for special fishing hands is made.
          13.2 A check for an ordinary fishing hand is made.
        13. The Moves class sent to server so that it can be retrieved by other MMC.

        5.6.2.7 Can Declare Another Concealed Kong

          This scenario forms an alternative to 5.6.2.3 from item 5, and assumes that the user is fishing after the Declaring the Kong and can Mahjong after drawing the loose tile.

        1. The UserPane is updated to signal that the user is fishing.
        2. The Hand has been reduced back to 13 tiles without a discard being selected. A loose tile is therefore drawn from the honour Wall.
        3. The UserPane is updated to reflect the changes to the user's Hand.
        4. With the 14 tiles now in their Hand, the current player could have Mahjong. If item 1 was found to be true then the following checks will be made:
          4.1 A check for special Mahjong hands is made.
          4.2 A check for an ordinary Mahjong hand is made.
        5. A check for Mahjong is found to be true in either 4.1 or 4.2. The Game loop is then exited, a pay out to each of the Players made and the Game is then re-initialised.

        5.6.2.8 Declaring a Concealed Kong before Discard Selected

          This scenario follows 5.6.2, and involves the user Declaring a Kong in the Hand before the discard tile is selected when another is fishing.

        1. The user selects a tile and presses the Declare Kong button.
        2. Once the tile is selected and the Declared Kong button pressed, the Game is notified of the move. The tile is added to the Moves class. The selected tile is then used to search through the user's concealed Hand to reveal the Declared Kong. All four tiles are removed from the hand and placed into the exposed set.
        3. The UserPane is updated to reflect the changes to the user's Hand.
        4. The Moves class sent to Server so that it can be retrieved by other MMC.
        5. The current player's Hand will now once again contain 13 tiles, and since the composition of the Hand has changed it will need to be checked for fishing.
          5.1 A check for special fishing hands is made.
          5.2 A check for an ordinary fishing hand is made.
        6. The scenario can continue with items 5-12 of section 5.6.2.3. It must be noted that the Moves class sent after the discard is selected, will only contain the discard tile.

        5.6.2.9 Fishing after Extending Pung

          This scenario forms an alternative to 5.6.2.8 from item 6, and assumes that the user is fishing after extending the Pung.

        1. The UserPane is updated to signal that the user is fishing.
        2. Continues from items 5-12 in section 5.6.2.3.

        5.6.2.10 Can Declare Kong after Exposing Pung

          This scenario forms an alternative to 5.6.2.8 from item 6, and assumes that the user can Declare a Kong after exposing the Pung.

        1. Scenario 5.6.2 is again followed.
        2. Scenario 5.6.2.3 is followed to Declare the Kong.

        5.6.2.11 Fishing after Extending Exposed Pung and Can Mahjong off Discard

          This scenario forms an alternative to 5.6.2.8 from item 6, and assumes that the user is fishing after extending the exposed Pung to a Kong and can Mahjong after drawing the loose tile.

        1. The UserPane is updated to signal that the user is fishing.
        2. The Hand has been reduced back to 13 tiles without a discard being selected. A loose tile is therefore drawn from the honour Wall.
        3. The UserPane is updated to reflect the changes to the user's Hand.
        4. With the 14 tiles now in their Hand, the current player could have Mahjong. If item 5 of section 5.6.2.8 was found to be true then the following checks will be made:
          4.1 A check for special Mahjong hands is made.
          4.2 A check for an ordinary Mahjong hand is made.
        5. A check for Mahjong is found to be true in either 12.1 or 12.2. The Game loop is then exited, a pay out to each of the Players made and the Game is then re-initialised.

      5.6.3 Adding a tile to the exposed Pung and robbing the Kong.

        5.6.3.1 No Players Fishing, Player has Exposed Pung and Concealed Tile to add to Pung

          This scenario follows 5.6.1.2 and 5.6.2, and assumes that no Players are fishing. The current player has an exposed Pung and a tile in their concealed hand to add to the Pung.

        1. Follow all items in scenario 5.6.2.6. Alternatives to 5.6.3.1 will include similar alterations that were produced for Declaring the Kong. These include Mahjong off a loose tile, fishing and updating the display, and Declaring a Kong after extending the Pung.

        5.6.3.2 User has Exposed Pung, but can't Rob the Kong

          The current player has an exposed Pung and a tile in their concealed Hand to add to the Pung. A Player is fishing but can't rob the Kong. This scenario follows 5.6.2.

        1. The user selects a tile and presses the extend Pung button.
        2. Once the extend Pung button has been selected, the Game is notified of the move by the StatusPane. The tile is added to the Moves class.
        3. The Moves class sent to server so that it can be retrieved by other MMC.
        4. For each player that exist in the client thread the Hand is checked for Mahjong with the extend Pung tile. This will determine whether they can rob the Kong.
          4.1 A check for special Mahjong hands is made.
          4.2 A check for an ordinary Mahjong hand is made.
        5. All Players that exist in this client thread are prompted to select rob the Kong if they are able to do so.
        6. The selections are sent to the Server, and once all have been placed (other than the current player) a result is made available. The result is retrieved from the Server.
        7. Assuming that the tile has not been robbed then the selected tile will be removed from the concealed hand and added to the exposed Pung. The exposed Pung will now form a Kong.
        8. The current player's Hand will now once again contain 13 tiles, and since the composition of the Hand has changed it will need to be checked for fishing.
          8.1 A check for special fishing hands is made.
          8.2 A check for an ordinary fishing hand is made.
        9. The scenario can continue with 5.6.2.3 items 7-12. It must be noted that the Moves class sent after the discard is select will only contain this discard tile.

        5.6.3.3 Fishing after Extending the Pung

          This is an alternative to 5.6.3.2 from item 9, and involves a user obtaining a fishing hand after extending the Pung.

        1. The UserPane is updated to signal that the user is fishing.
        2. The scenario can continue with 5.6.2.3 items 7-12. It must be noted that the Moves class sent after the discard is select, will only contain the discard tile.

        5.6.3.4 Can Mahjong after Extending the Pung

          This is an alternative to 5.6.3.2 from item 9, and involves a user obtaining a fishing hand after extending the Pung and can Mahjong off the drawn loose tile.

        1. The UserPane is updated to signal that the user is fishing.
        2. The Hand has been reduced back to 13 tiles without a discard being selected. A loose tile is therefore drawn from the honour Wall.
        3. The UserPane is updated to reflect the changes to the user's Hand.
        4. With the 14 tiles now in their Hand, the current player could have Mahjong. If item 5 of section 5.6.3.2 was found to be true then the following checks will be made:
          4.1 A check for special Mahjong hands is made.
          4.2 A check for an ordinary Mahjong hand is made.
        5. The user's Hand has found to be Mahjong, and so scores are displayed.
        6. A new Game is re-initialised. All flags are reset, the Server reshuffles the Wall and new Hands are dealt to each Player.
        7. A new Game is started.

      5.6.4 Adding a Tile to the Exposed Pung and Robbing the Kong

        This scenario follows 5.6.2. Player has an exposed Pung and a tile in their concealed hand to add to the Pung. A Player is fishing and can rob the Kong.

        1. Follow items 2 to 6 in section 5.6.3.2.
        2. Assuming that the tile has been robbed, then the selected tile is inserted into the Hand of the robbing player. All flags associated with robbing the Kong are set.
        3. The player's Hand has found to be Mahjong, and so scores are displayed.
        4. A new Game is re-initialised. All flags are reset, the Server reshuffles the Wall and new Hands are dealt to each Player.
        5. A new Game is started.

      5.6.5 Selections

        5.6.5.1 Placing Selections

          The user selects their next move

        1. Assuming that user is not the current player, then the Game will make checks on the player's Hand for possible moves.
        2. Checks for Pickup, Chow, Pung, Kong and Mahjong(if the Player is fishing) are made.
        3. If any of the above moves are possible then the Game will activate corresponding button in the ActionPane.
        4. If a move is possible the Game waits until a selection is made.
        5. Otherwise a NoMove selection is sent directly to the Server.

        5.6.5.2 Multiple Chows

          The user selects Chow as their next move.

        1. If the Game detects multiple Chows the ActionPane will be notified which are possible.
        2. The user selects the Chow button in the ActionPane.
        3. A dialog box will appear on the screen with the possible selections made available.
        4. The user selects a one of the Chow moves.

        5.6.5.3 Running Selections

          Result is Either a Single Chow, Pung or Kong.

        1. The selection of the last Player in the client's Game thread is sent, and a result is waited upon the Server.
        2. All Players have placed their selections from all MMC and therefore a result is available. All MMC are notified that it is available.
        3. The Player determined to have the move with the highest priority and their selection are retrieved.
        4. The selection is run with the last discarded tile.
        5. The UserPane is updated to reflect the changes to the player's Hand.

      5.6.6 Waiting on a Discard- No Players Fishing

        5.6.6.1 No Players Fishing, Current Player Declares Kong/Extends Pung/Discards

          Current player chooses to Declare Kong or extend Pung and discard. No players are fishing.

        1. If a the current player is not in this client's Game thread, then it will wait on the Server until the discard tile has been made available.
        2. A signal is sent from the Server that the discard has been placed.
        3. A Moves class is retrieved from the Server.
        4. All concealed Kongs and extend Pung selection tiles are extracted from the Moves class, one at a time.
        5. After each tile is extracted the relevant move is run on the current player's Hand.
        6. The UserPane is updated to reflect the changes to the player's Hand.
        7. The current player's Hand will now once again contain 13 tiles, and since the composition of the Hand has changed it will need to be checked for fishing.
          7.1 A check for special fishing hands is made.
          7.2 A check for an ordinary fishing hand is made.
        8. The Hand has been reduced back to 13 tiles without a discard being selected. A loose tile is therefore drawn from the honour Wall.
        9. The UserPane is updated to reflect the changes to the hands.
        10. With the 14 tiles now in their Hand, the current player could have Mahjong. If item 7 was found to be true then the following checks will be made:
          10.1 A check for special Mahjong hands is made.
          10.2 A check for an ordinary Mahjong hand is made.
        11. Items 6 to 10 are repeated for every Kong tile that is extracted.
        12. The discard tile is extracted from the Moves class and the tile is then removed from the player's Hand.
        13. The current player's Hand will now once again contain 13 tiles, and since the composition of the Hand has changed it will need to be checked for fishing.
          13.1 A check for special fishing hands is made.
          13.2 A check for an ordinary fishing hand is made.
        14. The UserPane is updated to reflect the changes to the player's Hand.

        5.6.6.2 Fishing After Declared Kong and then has Mahjong from a Loose Tile

          This is an alternative scenario to 5.6.6.1 from item 11, and assumes that the current player's Hand is fishing after Declaring a Kong and then has a Mahjong hand as a result of drawing a loose tile.

        1. The player's Hand has found to be Mahjong, and so scores are displayed.
        2. A new Game is re-initialised. All flags are reset, the Server reshuffles the Wall and new Hands are dealt to each Player.
        3. A new Game is started.

      5.6.7 Waiting on a Discard- a Player is Fishing

        • If the current player is not in this client's Game thread then it will wait on the Server until the next move has been selected. This includes the discard.
        • A signal is sent from the Server that the move has been placed.
        • A Moves class is retrieved from the Server.

        5.6.7.1 Player Declares Kong and Discards

          This scenario follows from 5.6.7, and assumes current player chooses to Declare Kong and discard.

        1. The concealed Kong tile is extracted from the Moves class, and is run directly on the current player's Hand.
        2. The UserPane is updated to reflect the changes to the hands.
        3. The current player's Hand will now once again contain 13 tiles, and since the composition of the Hand has changed it will need to be checked for fishing.
          3.1 A check for special fishing hands is made.
          3.2 A check for an ordinary fishing hand is made.
        4. The Hand has been reduced back to 13 tiles without a discard being selected. A loose tile is therefore drawn from the honour Wall.
        5. The UserPane is updated to reflect the changes to the player's Hand.
        6. With the 14 tiles now in their Hand, the current player could have Mahjong. If item 5 was found to be true then the following checks will be made:
          6.1 A check for special Mahjong hands is made.
          6.2 A check for an ordinary Mahjong hand is made.
        7. The scenario continues with section 5.6.7.
        8. A signal is received from the Server to indicate that the last selected move was the discard and that the last retrieved class contains this tile.
        9. The discard tile is extracted from the Moves class and the tile is then removed from the player's Hand.
        10. The current player's Hand will now once again contain 13 tiles, and since the composition of the Hand has changed it will need to be checked for fishing.
          10.1 A check for special fishing hands is made.
          10.2 A check for an ordinary fishing hand is made.
        11. The UserPane is updated to reflect the changes to the player's Hand.

        5.6.7.2 Player Extends Pung

          This scenario follows from 5.6.7, and assumes that the current player decides to extend a Pung.

        1. The extend Pung tile is extracted from the Moves class.
        2. For each Player that exist in the client thread the Hand is checked for Mahjong with the extend Pung tile. This will determine whether they can rob the Kong.
          2.1 A check for special Mahjong hands is made.
          2.2 A check for an ordinary Mahjong hand is made.
        3. All Players that exist in this client thread are prompted to select rob the Kong if they are able to do so.
        4. The selections are sent to the Server, and once all have been placed (other than the current player) a result is made available. The result is retrieved from the Server.
        5. Assuming that the tile has not been robbed then the selected tile will be removed from the concealed hand and added to the exposed Pung. The exposed Pung will now form a Kong.
        6. The current player's Hand will now once again contain 13 tiles, and since the composition of the Hand has changed it will need to be checked for fishing.
          6.1 A check for special fishing hands is made.
          6.2 A check for an ordinary fishing hand is made.
        7. The Hand has been reduced back to 13 tiles without a discard being selected. A loose tile is therefore drawn from the honour Wall.
        8. The UserPane is updated to reflect the changes to the player's Hand.
        9. With the 14 tiles now in their Hand, the current player could have Mahjong. If item 4 was found to be true then the following checks will be made:
          9.1 A check for special Mahjong hands is made.
          9.2 A check for an ordinary Mahjong hand is made.
        10. The Game goes back on to the Server to wait for instructions on the next move.

        5.6.7.3 Player Robs the Kong

          This is an alternative scenario to 5.6.7.2 from item 5, and assumes that the Kong has been robbed.

        1. Assuming that the tile has been robbed then the selected tile is inserted into the Hand of the robbing player. All flags associated with robbing the Kong are set.
        2. The player's Hand has found to be Mahjong, and so scores are displayed.
        3. A new Game is re-initialised. All flags are reset, the Server reshuffles the Wall and new Hands are dealt to each Player.
        4. A new Game is started.

    5.7 Leaving A Game (Single & Multi Player)

      Description:

        This section details how a user can leave a game they have started.

      SRS References:

        4.4.1, 4.4.2, 6.2.1

    1. The user clicks on the OptionTab and clicks the Leave Game button.
    2. The UserGUI class presents the user with a dialog box asking them if they are sure they want to stop the current game.
    3. The user clicks on Cancel and they continue playing the game.
    4. The user again clicks the Leave Game button, but this time chooses Yes to leave the game.
    5. The UserGUI class presents the user with the start new game dialog.

    5.8 Exiting The MultiMahjong Program

      Description:

        This section describes how a user can quit the MultiMahjongClient program.

      SRS References:

        4.2.1, 6.2.1

    1. The user clicks Quit MultiMahjong button in the game dialog.
    2. The Game class exits the program.

             

6. Scenario Diagrams

    This section implements Step 8 (see Section 2.2) of our design process. It evolves the use cases from Section 5 and uses the methods of the classes from Step 7 to create scenario diagrams. As this document has been designed to print on A4 page the scenario diagrams may be difficult to see clearly. If you click on the diagram a new window will be brought up in your browser which contains the full size image.

    These scenario diagrams consist of the method calls to classes that will occur during the given scenario. For a description of each method, please see the detailed design of the specific class in Section 4.

    6.1 UserGUI Module

      6.1.1 Starting a New Single Player Game

      Once the MultiMahjongClient program has been loaded the GameTypeSelector is displayed. The user enters his/her info and leaves the radio button for a single player game selcted. The user then clicks on the Next >> button. The Next >> button invokes the startGame method in UserGUI (note that there are 2 versions of this overloaded method). The startGame method, knowing that it is in single player mode, creates 3 COs, instantiates the local referee (it's in a separate thread, so start() has to be called), and instantiates a Game object. After that it brings up the playing screen.

      6.1.2 Starting a New Multi Player Game

      The first part with the GameTypeSelector is a repeat of the single player game. Upon clicking Next >>, the MultiGameStarter is instantiated and displayed on the desktop. The constructor of the MultiGameStarter class calls the registerGame method in the Registrar and supplies 3 arguments to it - a reference to the MultiGameStarter itself, the Player info, and the game preferences. Note that registerGame will eventually return a RemoteReferee to the MultiGameStarter.

      registerGame in turn calls createGame in GamesList (which also returns a RemoteReferee), which in turn instantiates a RemoteReferee. The getRemoteReferee method gives the reference of the RemoteReferee back to the GamesList, so that it can be returned to the Registrar and then the MultiGameStarter.

      Now that the Registrar has a reference to the MultiGameStarter, it can call updatePlayList whenever a new player joins the game. The creator of the game can press the "start game" button in the MultiGameStarter to begin the game, via a beginGame method call to the Registrar.

      On the client side the MultiGameStarter calls startGame in the UserGUI. This is the second version of this overloaded method. The RemoteReferee is passed to the UserGUI. COs are created if necessary, the Game is instantiated and the playing screen created.

      6.1.3 Joining an Existing Multi Player Game

      Once again, the first part is a repeat of the single player game. Upon clicking Next >>, the MultiGameJoiner is instantiated and displayed on the desktop. The constructor of the MultiGameJoiner class calls the registerClient method in the Registrar and gives it a references to the MultiGameJoiner itself. The Registrar can now call updateGamesList to update the list of avaliable games for the user.

      The user selects a game and clicks on "Join Game". This invokes the joinGame method in the Registrar. This method takes 3 arguments - a gamesList, a gameID and a player info. The first 2 arguments are necessary to identify which game to join - a gameID by itself is insufficient, as the server side gamesList may have changed in the mean time. Note that the joinGame method will eventually return a RemoteReferee.

      The Registrar passes on the join request and adds the player to the correct RemoteReferee via the GamesList. Once again, getRemoteReferee is invoked so that joinGame can return the RemoteReferee to the MultiGameJoiner. When the creator of the game clicks on "Start Game", the Registrar will invoke the beginGame method in MultiGameJoiner, passing with it a list of the players in the game and the userID. After this the scenario is similar to starting a new multi player game.

      6.1.4 Creating the Playing Screen

      The UserGUI instantiates each of the four major screen areas, then calls the start method to run the Game thread. This is important because the playing screen must be up and running before the Game is started. The Game then updates the wind of each of the players (the round wind indicator is incorporated within these 4 function calls), and initialises the graphical representation of the wall.

    6.2 Game Module

7. Traceability

    The following table shows all the requirements from the SRS and their corresponding references in this document, the SDD. All Level 1 requirements have been implemented in design. Level 2 and Level 3 requirements were not vital to the product, and as such not all of these requirements have been implemented.

    As the design does not take into account user documentation, Section 7 of the SRS (Document/Training Requirements), it is not included in this table.

      SRS SDD
      The MultiMahjongServer
      4.1.1 4.1.1
      4.1.2 4.1.1, 4.1.2
      4.1.3 4.1.1, 4.1.2, 4.1.5
      4.1.4 4.1.4, 4.1.5
      4.1.5 Not Implemented
      4.1.6 Not Implemented
      4.1.7 Not Implemented
      4.1.8 Not Implemented
      4.1.9 Not Implemented
      4.1.10 Not Implemented
      Beginning the Game
      4.2.1 4.2.1, 4.2.6, 4.2.12
      4.2.2 4.3.2, 4.2.6, 4.2.7, 4.2.12, 4.2.13
      4.2.3 4.1.2, 4.1.3, 4.2.6, 4.3.1
      4.2.4 4.4.1
      4.2.5 4.2.6, 4.2.12
      4.2.6 4.1.2, 4.1.3, 4.2.8
      4.2.7 4.2.6, 4.2.12, 4.2.14
      4.2.8 4.1.2, 4.1.3, 4.2.6
      4.2.9 4.1.2, 4.1.3, 4.1.4, 4.1.5
      4.2.10 4.2.8
      4.2.11 Not Implemented
      4.2.12 Not Implemented
      4.2.13 Not Implemented
      4.2.14 Not Implemented
      Playing the Game
      4.3.1 4.3.3, 4.3.4, 4.3.5
      4.3.2 4.2.2, 4.2.3, 4.2.5, 4.3.3
      4.3.3 4.1.4, 4.1.5, 4.2.5, 4.3.1
      4.3.4 4.1.4, 4.1.5, 4.2.2, 4.2.3, 4.3.3
      4.3.5 4.1.4, 4.1.5, 4.2.2, 4.2.3, 4.3.3
      4.3.6 4.1.5, 4.2.2, 4.2.3, 4.3.1, 4.3.3
      4.3.7 4.2.5, 4.3.1, 4.3.4, 4.3.5
      4.3.8 4.3.1, 4.3.4, 4.3.5
      4.3.9 4.3.1
      4.3.10 4.2.5
      4.3.11 Not Implemented
      4.3.12 4.2.4
      4.3.13 4.2.3, 4.2.9
      4.3.14 Not Implemented
      4.3.15 4.2.2
      4.3.16 Not Implemented
      4.3.17 Not Implemented
      4.3.18 Not Implemented
      4.3.19 Not Implemented
      Ending the Game
      4.4.1 4.3.1
      4.4.2 4.2.4, 4.3.1
      4.4.3 4.1.5, 4.2.10, 4.3.1
      4.4.4 Not Implemented
      4.4.5 Not Implemented
      Computer Opponent
      4.5.1 4.4.1
      4.5.2 4.4.1
      4.5.3 4.4.1
      4.5.4 4.4.1
      4.5.5 4.4.1
      4.5.6 4.4.1
      4.5.7 4.4.1
      4.5.8 Not Implemented
      4.5.9 Not Implemented
      4.5.10 4.4.1
      4.5.11 Not Implemented
      4.5.12 Not Implemented
      Nature of Users
      5.1.1 4.2.1
      5.1.2 4.1.1
      Error Handling
      5.2.1 4.2.10, 4.2.11
      5.2.2 4.2.11
      Implementation Constraints
      5.5.2 4.1.1, 4.1.2, 4.1.3
      User Interface - MultiMahjongServer
      6.1.1 4.1.1
      6.1.2 Not Implemented
      User Interface - MultiMahjongClient
      6.2.1 4.2.1, 4.2.5
      6.2.2 Not Implemented
      6.2.3 4.2.5
      Graphical User Interface - MultiMahjongClient
      6.3 4.2.1
      6.3.4.1 4.2.5, 4.2.6, 4.2.7
      6.3.4.2 4.2.5
      6.3.4.3 4.2.5, 4.2.6, 4.2.8, 4.2.9, 4.2.10
      6.3.4.4 4.2.5, 4.2.6, 4.2.7, 4.2.8, 4.2.9, 4.2.10
      6.3.4.5 4.2.5
      6.3.4.6 4.2.2, 4.2.3, 4.2.6
      6.3.4.7 4.2.2, 4.2.3
      6.3.5 4.2.4, 4.2.8, 4.3.5, 4.3.7
      6.3.6 4.2.12, 4.2.13
      6.3.7 4.2.14
      6.3.8 4.2.4, 4.2.5
      6.3.9 Not Implemented
      6.3.10 Not Implemented
      6.3.11 Not Implemented

8. Glossary

    Chow  A set of 3 sequentially numbered tiles from a given suit.
    Concealed Set  A Kong, Pung or Chow that has been formed entirely by picking up from The Wall.
    CO Computer Opponent. The entity that calculates and executes the computer's moves.
    Dead Tiles  All the Tiles which have already been discarded.
    Dead Wall  The Tiles at the end of The Wall which are used to replenish the extra tile used in getting a Kong.
    Dialogue Box  A small window that expects input data from the user. Usually contains text and buttons.
    Discard  The tile a player chooses to discard at the end of their turn.
    Dragon Tiles  Dragon Tiles include Red, Green and White Dragon Tiles. There are four of each of these kinds of Dragon Tiles.
    Draw  A draw occurs when 3 players go Mahjong at the same time or all the tiles up to the dead wall have been drawn without any player going Mahjong.
    Exposed Set  When a discard is picked up in order to form a Kong, Pung or Chow. This set of tiles must be shown to all players for the rest of the hand.
    Fishing  A player is "fishing for Mahjong" when they need only one tile to go Mahjong. All other players in the game must be alerted that the player is fishing.
    Game  A game ends when 4 rounds have been played.
    Hand  The tiles each player has. A winning hand is when a player goes Mahjong by forming an ordinary or special hand. If a winning hand is achieved then all winds rotate anti-clockwise. Once the player who was the Wind of the Round at the start of the round is again that wind then the round is completed. A hand has to be replayed if there is a draw.
    Honour Tiles  These are special tiles in Mahjong. They can be Dragon Tiles or Wind Tiles.
    HTML  HyperText Mark-up Language. The language used to compose and format most of the content found on the World Wide Web.
    Kong  A set of 4 identical tiles.
    Limit  The highest amount that can be scored for a winning hand.
    Mahjong  A 4 player game which is thought to have originated in China around 500 BC. Also the term given to a winning hand.
    MMC MultiMahjongClient. The program which a user uses to play a game of MultiMahjong (either locally or over a network).
    MMS MultiMahjongServer. The server which enables multiple MMCs to play a game of MultiMahjong over a network.
    Ordinary Hand  A hand containing any four sets of Kongs, Pungs and Chows, and a pair.
    OS  Operating System, the software that controls the execution of all applications and system software programs.
    Pair  2 of the same tile.
    Pung  A set of 3 identical tiles.
    Revealed Kong  When a player reveals a concealed Kong. They have to do this otherwise they would be a tile short of being able to go Mahjong.
    RMI Remote Method Invocation. An API that is part of Java 2 (JDK 1.2). It allows for methods to be called from a client to a server via TCP/IP.
    Round  When the player who was the Wind of the Round originally is that wind again then a round is over and the Wind of the Round changes.
    Server  A central computer in a LAN/WAN that allows connections.
    Special Hand  When a player forms an exact arrangement of designated tiles. To see what constitutes special hands are possible refer to a Mahjong rule book.
    Suit Tiles  Three kinds of suits exist in Mahjong. These suits are Bamboos, Characters and Circles. Each suit has tiles consecutively numbered from 1 to 9. There are 4 of each of these numbered tiles in a suit.
    Swing  An API that is part of Java 2 (JDK 1.2). It provides support for non-OS dependent GUI building.
    TCP/IP  Transmission Control Protocol/Internet Protocol. A set of communications protocols developed by the Department of Defence to link dissimilar computers across many kinds of networks.
    The Wall  A 4 sided arrangement of tiles, 17 tiles long and 2 tiles high in the Chinese game of Mahjong, from which each hand is played.
    Tiles  What is used to play a game of Mahjong, just like cards in Gin. Tiles are either Suit Tiles or Honour Tiles.
    UML  Unified Modelling Lanaguage. A standard for Object Oriented design.
    Wind  The position which each player is sitting in. Winds include: East, South, West and North.
    Wind of the Round  The wind whose round it currently is. This is important for scoring and determines when a game finishes. The first round is East Wind's round, the second round is South Wind's round, the third round is West Wind's round and the last round is North Wind's round.
    Wind Tiles  Wind Tiles include East, South, West and North Wind Tiles. There are four of each of these kinds of Wind Tiles.

Other Documentation