1 of 18

Chess Server Design

CS 240 – Advanced Software Construction

2 of 18

HTTP Request

Chess Client

Web

Chess Server

HTTP Response

3 of 18

Clients

Console

Client

Web Browser

(Test Page)

Test Driver

(JUnit tests)

Server

Web API

Web Site

4 of 18

Relevant Specifications

  • Study the “Phase 3: Chess Web API” specification
  • Study the “Phase 2: Chess Server Design” specification

5 of 18

Academic Integrity

  • In CS 240 we use a plagiarism detection system that will compare your code with every other student’s code who has ever done the Chess project
  • If you use AI to write your code, it is likely that your code will be flagged, because AI will mimic other student solutions it has seen
  • Please write your own code
  • When working with other people, you may work together at the “whiteboard”, but not at the “keyboard”

6 of 18

7 of 18

Software Design Principles

  • Single Responsibility Principle (SRP)
    • Every class represents one well-defined concept, all its functionality relates to that one concept (i.e., it is “cohesive”), and it has a good name that describes what it represents (should be a noun)
    • Every method/function does one well-defined task, and has a good name that describes what it does (usually a verb or verb phrase)
  • Avoid Code Duplication
    • Put code that’s needed in multiple places in a method/function of base class
  • Encapsulation / Information Hiding
    • Classes and methods/functions should hide their internal implementation details.
    • Class members should be private when possible (i.e., limit visibility)
    • Names should not unnecessarily reveal implementation details
      • StudentLinkedList vs. ClassRoll

8 of 18

9 of 18

Chess Server Data

User

User

User

User

Auth

Token

Auth

Token

Auth

Token

Game

Game

Game

Game

Chess Game

Chess Board

Chess Piece

Chess Move

+

10 of 18

Model

User

AuthToken

Game

11 of 18

Data Access

UserDao

AuthTokenDao

GameDao

Model

User

AuthToken

Game

12 of 18

Model

Data Access

Request/

Result

RegisterRequest

RegisterResult

LoginRequest

LoginResult

UserDao

AuthTokenDao

GameDao

User

AuthToken

Game

RegisterResult register(RegisterRequest r)

Clear Service

LoginResult login(LoginRequest r)

ClearResult clear()

Game Service

JoinResult join(JoinRequest r)

User Service

LogoutResult logout(LogoutRequest r)

CreateResult create(CreateRequest r)

Service Classes

ListResult list(ListRequest r)

13 of 18

Model Classes

Data Access Classes

Request/

Result Classes

RegisterRequest

RegisterResult

LoginRequest

LoginResult

UserDao

AuthTokenDao

GameDao

User

AuthToken

Game

Register Handler

Login Handler

Join Handler

Clear Handler

Server

Main Server Class

HTTP Handler Classes

RegisterResult register(RegisterRequest r)

Clear Service

LoginResult login(LoginRequest r)

ClearResult clear()

Game Service

JoinResult join(JoinRequest r)

User Service

LogoutResult logout(LogoutRequest r)

CreateResult create(CreateRequest r)

Service Classes

Logout Handler

Create Handler

ListResult list(ListRequest r)

List Handler

14 of 18

15 of 18

Frequently Asked Questions

  • Why not put service methods on the handler class?
    • Single responsibility principle
  • Why do the DAO classes depend on the Model classes?
    • Model objects are parameters and return values for DAO methods
  • Why not have one handler class, one service class, one DAO class?
    • Single responsibility principle
    • Those classes would get too big and cluttered
  • Does it make sense to create base classes for: Handlers, Services, Requests, Responses, DAOs
    • Yes, to avoid code duplication
  • Web API functions return different JSON objects for success and failure. How do you do that?
    • GSON doesn't serialize null fields
  • Does the Clear function need a request class?
    • No
    • But all the other functions do

16 of 18

17 of 18

Chess Server Design Assignment

(Phase 2)

18 of 18

Citations

Diagrams created by Ken Rodham