Casino Blackjack (Group 53)

Software Architecture Document

Version 2.0

Revision History

Date	Version	Description	Author
18/04/03	v1	Created	Paul Stasuik
25/04/03	v1	Revised	Paul Stasuik
26/04/03	v1	Last updated	Paul Stasuik
27/04/03	v1	Reviewed and updated	Jon Roberts
27/04/03	v1	Converted to HTML, rushed to make UML diagrams and added sad_screenshots.htm.	Andrew Noske
First submission
20/05/03	v2	Minor changes.	Andrew Noske
27/05/03	v2	More changes and marked all changes with {v2} tags.	Andrew Noske
Second submission

Table of Contents

1. Introduction
- 1.1 Purpose
- 1.2 Scope
- 1.3 Definitions, Acronyms and Abbreviations
- 1.4 References
- 1.5 Overview
2. Architectural Representation
3. Architectural Goals and Constraints
4. Use-Case View
5. Logical View
6. Process View
7. Deployment View
8. Implementation View
- 8.1 Overview
- 8.2 Layers
9. Data View (optional)
10. Size and Performance
11. Quality

Software Architecture Document

1. Introduction

1.1 Purpose

This document is to be used as a guideline to deliver “Casino Blackjack version 1.01”, an online blackjack game with chat abilities.
This SAD should be read in conjunction with the Online Blackjack SRS version 1.01.

1.2 Scope

This document was created as a starting point for the design and implementation of “Casino Blackjack version 1.01”. It also provides an outline of benchmarks and miniature milestones to use when monitoring the project’s development.

1.3 Definitions, Acronyms and Abbreviations

See the project SRS and Glossary.
Changes since v1 of the sad have been marked as "{v2}".

1.4 References

Title	Report number	Date	Publishing organization	Sources references obtained
Pure Java2	null	1999	SAMS	sockets, jdbc
Core Java V1 Fundamentals	null	2001	Sun Microsystems Press	coding
Core Java V2	null	2000	Sun Microsystems Press	coding
Jupiters Blackjack manual	null	1998	Jupiters Ltd.	blackjack rules
Group 53 Blackjack web site	null	2003	Group 53	http://www.unitednh.com/~cp3110/cp3110_v1/a1/srs_v1.htm
Group 53 Blackjack web site	null	1998	Group 53	http://www.unitednh.com/~cp3110/cp3110_v1
Mastering XML	null	1998	Sybex	understand XML
MySql	null	null	null	http://www.mysql.com
Java 1.4:	null	null	null	java.sun.com

1.5 Overview

N/A.

2. Architectural Representation

N/A.

3. Architectural Goals and Constraints

NOT REQUIRED.

4. Use-Case View

NOT REQUIRED.

5. Logical View

5.1 Overview

The logical view of this program is comprised of 4 layers:

Presentation Layer

Supports user (client) interactions with the program via GUIs.
Consists of the following subsystems:
- User Log-in view
- Game State view
  - Table view
  - Each clients’ table view
  - Server view

Application Layer

Supports processing that is specific to this program, such as:
- Table view
- Shoe view
- Shuffle view
- Card view
- Hand view
- Client-Server communication view
- Chat room facilities
- Game states
Consists of the following subsystems:
- Rules view
- Player view
- Dealer view

Domain Layer

Images View:
- Images needed on the client side to display locally on machine
Consists of the following subsystems:
- Card View
- Table View

Data Management Layer

Supports user data storage and retrieval, as well as the application internal data storage using MySQL database.
Consists of the following subsystems:
- User file
- {v2} Configuration
- Java interface

6. Process View

The system is a client-server program. Which supports multithreading allowing clients to remotely log on from different terminals to interact in an online blackjack environment is used to support the SRS version 1 functionality.
At current the game state database supports command line input and retrieve and in future versions of the prototype design will support GUI java interfaces which will be required to support the SRS version 2 and higher.

7. Deployment View

The program could be deployed on any computer platform that supports java 1.4.
The program is distributed as a java executable jar-file. In that format the program could be executed from a web site if a user's browser has java 1.4 run-time environment installed. The program will use a read-me file in-order to show the end user where changes to the code need to be made for the images to be properly displayed (this should be fixed in version 1.02 and higher by supplying relative path names for the images).
The server needs to be run on a machine which supports MySQL, and needs to have some database administration performed prior to running.
{v2} By default, the program will have a valid host URL so it can connect to a dedicated server, however this default URL can be changed by the user.

8. Implementation View

8.1 Overview

Presentation Layer

Supports user (client) interactions with the program via GUIs. See screenshots from game.
Consists of the following subsystems:
- User Log-in view
- Game State view
  - Table view
  - Each clients’ table view
  - Server view

Application Layer

Supports processing that is specific to this program, such as:
- Table view
- Shoe view
- Shuffle view
- Card view
- Hand view
- Client-Server communication view
- Chat room facilities
- Game states
Consists of the following subsystems:
- Rules view
- Player view
- Dealer view

Domain Layer

Images View:
- Images needed on the client side to display locally on machine
Consists of the following subsystems:
- Card View
- Table View

Data Management Layer

Supports user data storage and retrieval, as well as the application internal data storage using MySQL database.
Consists of the following subsystems:
- User file
- {v2} Configuration
- Java interface

8.2 Layers

NOTE: To better illustrate layers and to fit everything on screen, all class structures (methods) are illustrated below, and only class names are used when showing relationships/dependencies.

8.2.1 Presentation Layer

Client-side panel set:

8.2.2 Application Layer

8.2.3 Domain Layer

8.2.4 Data Management Layer

Complete UML diagram:

NOTE: All UML above is subject to minor changes.

9. Data View (optional)

{v2} To see the type of information which should be maintained between client and server see information flow. It subdivides information into three types of data:
- {v2} Common info - static information the client and server must be programmed with in order to understand the phases and option withing the game.
- {v2} Table info - is send to client only once for each table and never changes (eg: minBet & maxBet for that table)
- {v2} Gamestate info - this information must be sent or updated after every transaction (i.e.: after every bet, hit etc.) so that all client see the same table the server has maintained.
{v2} This is further better understood by looking at the transaction concepts.