Computer Science Assignment 2 CC

lasonia73

archive5.zip

Home >Computer Science homework help >Computer Science Assignment 2 CC

Project6-Train-SDS.doc

Software Design Specification

for

Simple Train Simulator

Version 3.0

Prepared by Leva Kurginyan;

Modified by Dr Rand Mcfadden

<05/09/2015>

Table of Contents

11. Introduction

1.1 Purpose 1

1.2 Intended Audience and Reading Suggestions 1

1.3 Product Scope 1

1.4 Overview 1

2. Design Considerations 2

2.1 Assumptions and Dependencies 2

2.2 General Constraints 2

2.3 Development Methods 2

3. System Architecture 2

3.1 High level Overview of System Architecture (class diagram) 2

4. Human Interface Design 4

4.1 Interface description. 4

4.2 Screenshots of Interface 4

4.2.1 Prompt for stops and loop if incorrect 4

4.2.2 Prompt for pathname and loop if not exist 5

4.2.3 Check input data and loop if incorrect 5

4.2.4 Display output as simulation runs 5

5. Detailed System Design 6

5.1 Simulator Class 6

5.2 Train class 8

5.3 Customer class 10

Revision History

Name	Date	Reason For Changes	Version
Leva Kurginyan	07/22/14	Instructor’s feedback updated to Elevator Simulation	1.1
Renata Rand Mcfadden	07/24/14	Modified for Train Simulation	2.0
Renata Rand McFadden	05/09/2015	Modified for TDD Project	3.0

1. Introduction

1.1 Purpose

This is the Software Design Specification for the simple Train Simulator. This document will define the design of the simulator, by breaking down the project into components to describe in detail what the purpose of each component is and how it will be implemented. It will contain specific information about the expected input, output, and functionality. Also it will explain system constraints, assumptions, dependencies and interface.

1.2 Intended Audience and Reading Suggestions

This Software Design Specification is intended for:

· Development team who will develop the first version of the system.

· Developers who can review project’s capabilities and more easily understand where their efforts should be targeted to improve or add more features to it.

· Product testers can use this document as a base for their testing strategy. Also it might be used as a tool for verification and validation of the final product.

1.3 Product Scope

Simple Train Simulator system will be a simple train simulation, implemented with object-oriented approach using Java. It will simulate a train traveling to multiple stops (in a loop starting at stop 1 to stop N) with customers entering and exiting the train. The train will not stop if there are no customers waiting to enter or exit the train at that stop.

User of the program will need to input how many stops the train will have and the absolute path of text file with all customer data. While the simulation is running, it will display data to the console with train stops and customers entering and leaving the train. At the end of the simulation, the program will display how many stops it made to service all customers.

1.4 Overview

The remainder of this document includes 4 chapters.

· The second one introduces system constraints and assumptions about the product.

· The third chapter gives high level overview of system architecture.

· The fourth chapter provides the description of the system interface.

· The final fifth chapter provides detailed system design inclooding main data structures, atributes, and metodes used in each class.

2. Design Considerations

2.1 Assumptions and Dependencies

None.

2.2 General Constraints

Implementation environment

Project must be written in Java using Object Orientated approach.

Hardware

None.

2.3 Development Methods

Simple Train Simulator must be implemented using Object Orientated approach.

3. System Architecture

3.1 High level Overview of System Architecture (class diagram)

The three main components of Simple Train Simulator are: Simulator class, Train class and Customer class. Simulator is responsible for prompting and parsing user input data and running simulation. It creates an instance of Train class and N number (depending on data file) of instances of Customer class. It then runs the Train methods for the simulation.

Simulator – prompts user for number of stops and the input file with customer data. Parses the file and created a list of customers using Customer class. Creates an instance of Train and runs its methods for the simulation.

Customer – stores the four values parsed from file (id, arrival, enter, exit) for the customer. Sets up constants and status variable to determine status where CUST_NOT_PROCESSED means the customer has not been processed yet; CUST_ENTERED means_ the customer is on the train; and CUST_EXITED means the customer was processed and left the train.

Train - stores the number of stops train will have and the customer list. It also has an attribute for storing how many stops the train made as it processed the customers. The Simulator will create an instance of Train and set these values using the constructor. The simulate() method runs the strategy printing the appropriate output. The displayStops method prints the message with the number of stops the train made to process all customers and how long it took.

4. Human Interface Design

4.1 Interface description.

1. Simple Train Simulator will have text based user interface with textual output and textual prompts where user needs to type in a response.

2. When program starts, user gets prompted for number of stops the train has on its route: “ Enter number of stops the train has on its route (must be greater than 1): ”.

3. On invalid input, user will get error message “ Invalid input, try again. " and will be prompted to enter the number of stops again.

4. On correct input user gets prompted for customer data file name: “ Enter absolute path for data file or for default (C:/train/customer-data.txt) press Enter: ”.

5. If file does not exist, user will get error message “ File not found, try again. " and will be prompted to input the file path again.

6. If file has non-integer as one of the first four values, user will get error message “ Each line must have four integers. Try again.” and will be prompted to input the file path again.

7. If any of the data in the customer file is not valid, user will get error message “ Data in input file is not correct. Try again.” Then user will be prompted to enter another file path.

8. After user inputs all necessary correct information simulation begins.

9. During simulation information about each step of simulation (current time, current stop, customers entering train and customers leaving train) is printed out for user.

10. When simulation is done information about number of stops that were made and how long it took is printed out. The display will be “ Train made x stops and it took y time units to process all customers ” with x and y the actual values from the simulation

11. Program terminates.

4.2 Screenshots of Interface

4.2.1 Prompt for stops and loop if incorrect

Enter number of stops the train has on its route (must be greater than 1): 0

Invalid input, try again

Enter number of stops the train has on its route (must be greater than 1):

Enter number of stops the train has on its route (must be greater than 1): n

Invalid input, try again

Enter number of stops the train has on its route (must be greater than 1):

4.2.2 Prompt for pathname and loop if not exist

Enter absolute path for data file or for default (C:/train/customer-data.txt) press Enter:

blah

File not found, try again.

Enter absolute path for data file or for default (C:/train/customer-data.txt) press Enter:

4.2.3 Check input data and loop if incorrect

# id numbers are duplicate in input file (same for other constraints)

Enter absolute path for data file or for default (C:/train/customer-data.txt) press Enter:

C:/train/customer-bad-id.txt

Data in input file is not correct. Try again.

Enter absolute path for data file or for default (C:/train/customer-data.txt) press Enter:

# non-integer in the input file

Enter absolute path for data file or for default (C:/train/customer-data.txt) press Enter:

C:/train/customer-bad-arrival2.txt

Each line must have four integers. Try again.

Enter absolute path for data file or for default (C:/train/customer-data.txt) press Enter:

4.2.4 Display output as simulation runs

For input file (C:\train\customer-data.txt) with contents:

10 1 1 5

11 1 2 5

12 3 3 1

13 10 4 6

Output is:

Enter number of stops the train has on its route (must be greater than 1): 7

Enter absolute path for data file or for default (C:/train/customer-data.txt) press Enter:

Current Time=1 Current Stop=1

Customer enters train: id=10

Current Time=2 Current Stop=2

Customer enters train: id=11

Current Time=3 Current Stop=3

Customer enters train: id=12

Current Time=5 Current Stop=5

Customer exits train: id=10

Customer exits train: id=11

Current Time=8 Current Stop=1

Customer exits train: id=12

Current Time=11 Current Stop=4

Customer enters train: id=13

Current Time=13 Current Stop=6

Customer exits train: id=13

Train made 7 stops and it took 13 time units to process all customers

5. Detailed System Design

5.1 Simulator Class

This class is responsible for:

· Prompting user for all necessary inputs

· Reading data file and parsing it

· Checking for invalid input

· Creating and storing instances of Customer class into ArrayList

· Creating an instance of Train class

· Running simulation by calling Train’s simulate method

Attributes None

Methods

Method	Description
main()	Runs the program
void run(int, ArrayList<Customer>)
int getStopsFromUser()	Prompts user for number of stops, checks for invalid data and re-prompts, returns the valid value of stops
File getInputFile()	Prompts user for input file and checks that file exists. Loops prompting until user gives path for existing file.
ArrayList<Customer> checkFile(int stops, File)	Parses and checks for invalid data. If file has anything invalid, it returns null list. If file has valid values, creates instances of Customer and creates an ArrayList of type Customer and returns the list

Uses/Interactions

Creates instance of Train class.

Creates instances of Customer class - as many as necessary based on data file.

Simulator class is not used by any other class

Constraints

· Number of stops for the train must be entered as numeric (integer) value and greater than 1.

· Data file, which is specified by user, must exists and have correct data for each customer.

· Customer data constraints:

· Each customer must have a unique id, greater than 1, and it must be an integer

· The arrival time at the train must be greater than 0 and must be an integer. It represents the time the customer arrives at the train.

· The enter stop value must be greater than 0 and an integer. It has to be less than or equal to the highest stop the train has. It representing the stop number of the train where customer wants to enter the train. Stops start at 1 and go up to the N stops that user specified.

· The exit stop value must be greater than 0 and integer. It has to be less than or equal to the highest stop the train has. It representing the stop number of the train that customer wants to exit the train.

· Customer cannot enter and exit the train at the same stop.

Resources

The only resource that is used by this class is data file specified by user.

Processing

getStopsFromUser(): int

1. Prompts user to enter number of stops.

2. Checks input (must be integer > 1) and gives error message if it is not. Loops until correct value is entered.

3. Returns the obtained value to caller

getInputFile(): File

1. Loop until the path given is for file that exists

a. Prompts user for the input file path

b. If no file is given (user presses enter) then use the default path name (C:/train/customer-data.txt)

c. Use given path to create File instance

d. Checks if file exists.

e. If file does not exist gives an error message and loop until correct path is entered.

2. Return File instance

checkFile(int stops, File file): ArrayList<Customer>

1. Creates empty list (ArrayList<Customer> list)

2. In while loop

a) Reads file line by line

b) Parses the four integer values per line

c) Checks data that it meets the above constraints. If data is incorrect, stops parsing, gives error message, and returns null

d) Creates instance of customer class (using data from single line from data file)

e) Stores instance of customer into list.

f) Exits loop when no more lines to read.

3. Returns list

run(int stops, ArrayList<Customer> custList):

1. Create an instance of Train and pass through constructor stops and custList

2. Call Train’s simulate method

3. Call Train’s displayStops method

main() method:

1. Creates an instance of Simulation class

2. Creates custList of type ArrayList<Customer> and assigns null

3. Calls Simulator’s getStopsFromUser() method and saves the return value in variable (stops)

4. Loops as long as custList is null

a. Calls Simulator’s getInputFile() method. Save the returned File instance

b. Call Simulator’s checkFile() method passing it stops and instance of File. Save returned value in custList

5. Call Simulator’s run method passing it the stops and custList

5.2 Train class

This class is responsible for:

· Picking up customers

· Dropping off customer

· Moving train (one stop at a time)

· Calculating number of stops and the time it took for train to process all customers made and to print out results.

Class Attributes

Attribute	Description
stops : int	Used to store the number of stops train has on its route.
madeStops: int	Used to store number of stops the train made to process all customers.
currTime: int	Used to store the time for the train made to process all customers.
custList : arrayList<Customer>	Used to store list of customers to process in the simulation.

Methods

Method	Description
Train(int, ArrayList<Customer>)	Constructor to pass values of stops and customer list from Simulator and to initialize Train’s attributes
simulate()	Runs the train and processes customers entering and exiting the train. Train starts at stop 1 and travels to stop N. The route is a loop so then the train goes to stop 1 again and it keeps running until there are no more customers to process.
displayStops()	Displays the message of how many stops the train made and how long it took to process all customers

Uses/Interactions

The only class that uses “Train” class is the “Simulator” class. Train uses Customer class as it processes the list

Constraints

Preconditions – all necessary values are passed to instance of Train class by Simulator class (stops, custList).

Processing

· Train() constructor:

· All attributes are initialized

· simulate() method:

· Train starts running at current time = 1 and current stop =1.

· Make loopAgain = true (Boolean to control the loop)

· Loop until no more customers to process

· Loop for each customer in the list

· Check if there is any customers to process (status does not equal Customer CUST_EXITED). If yes then make loopAgain set to true so that when finishes processing this iteration, goes through loop again

· Print message with current time and current stop only if there is customer to enter or exit the train

· If customer not processed yet and his arrival time is less than or equal to current time and his enter stop is same as current stop, have customer enter the train (customer’s status gets set to Customer.CUST_ENTERED). Print message about customer entering train.

· If customer is in train already (status== Customer.CUST_ENTERED) and exit stop is equal to current stop, have customer exit the train (status gets set to Customer.CUST_EXITED). Print message about customer exiting train.

· If a customer entered or exited train, then increment by 1 the madeStop and update currTime

· Increment local variable keeping track of time and local variable to keep track of current stop

· If current stop == last stop (N), assign 1 to current stop for the train to loop

· displayStops() method:

· Print message “Train made X stops and it took Y time units to process all customers” using value of madeStops for X and value of currTime for Y.

5.3 Customer class

This class is responsible for storing and returning (when it is requested) customer information such as customer id, arrival time, enter stop, exit stop, and customer’s status.

Constants

Constant	Description
CUST_NOT_PROCESSED: static final int	Assigned value of 0 and means customer has not been processed yet
CUST_ENTERED: static final int	Assigned value of 1 and means customer entered the train
CUST_EXITED: static final int	Assigned value of 2 and means customer exited the train and is done processing

Attributes

Attribute	Description
id : int	Used to store customer’s ID
arrival : int	Used to store customer’s arrival time at the train
enter : int	Used to store the stop that customer will enter train
exit : int	Used to store the stop that customer will exit train
status : int	Used to track customer’s status using the constants

Methods

Method	Description
Customer(int Custid, int arrivalTime, int enterStop, int exitStop)	Constructor method to set attributes passed from Simulator It also sets status attribute to CUST_NOT_PROCESSED
void setStatus(int status)	Used to set customer’s status to the value passed by caller.
int getStatus()	Returns customer’s current status
int getId()	Returns customer’s ID
int getArrival()	Returns customer’s arrival time
int getEnter()	Returns entered stop
int getExit()	Returns exit stop

Uses/Interactions

Customer class is used by Simulator and Train classes.

This class does not use any other classes.

Constraints

All constraints are already described under Simulator class

Processing

· All attributes are initialized by constructor method.

· When getId() method is called it returns value of id attribute.

· When getArrival () method is called it returns value of arrival attribute

· When getEnter () method is called it returns value of enter attribute

· When getExit () method is called it returns value of exit attribute

· When getStatus () method is called it returns value of status attribute

· When setStatus(status) method is called it sets passed parameter value as a value of “status” attribute.

Copyright © 1994-1997 by Bradford D. Appleton. Permission is hereby granted to make and distribute verbatim copies of this document provided the copyright notice and this permission notice are preserved on all copies.(SDS sections)

Modified by Dr Renata Rand McFadden

Project4-Instructions.docx

Project 4

Design and Implement Software System

Mission:

Your manager told you that the customer changed their mind and now they want you to design and implement a simulated hand game based on the “Rock, Paper, Scissors, Saw” game using Object Oriented approach and Java or Python. The function requirements documented in SRS-RPSS-Game-OO.docx are the same but the design is different. You must use Object Oriented approach and Java or Python for this stand-alone PC program.

If using Java ensure you are using Java version 16.0.2, if using Python use Python version 3.9.

NOTE: Given the simplicity of this exercise you do not need to import any non-standard libraries or utilities. I can’t stress this enough, DO NOT use any non-standard packages or utilities/libraries.

Objective:

The goal of this project is to use basic requirements to practice creating a design (solution to the problem) and then implement that design. As part of the project you are to design interfaces and other aspects of the game, practice modularity and object oriented approach to implementation, and practice for the implementation to be exhibiting good practice techniques and meet both the requirements and the design.

Design Approach:

You are free to design the look and feel of the game as you want as long as you meet all the basic requirements given in SRS-RPSS-Game.docx. You must design and implement the game as it is described in those requirements and NOT as the original game is played or some other rules you might know. Note that the requirements document has been updated in section 2.2 to indicate what classes you must implement.

I will not be grading on creating a fancy design. I will be looking for correct Object-Oriented approach with realistic interfaces and reasonable class/method structure for the system. You want your design to be as complete and detailed as you can. Everything the customer has provided in the requirements document must make it into the correct sections of the design document.

You do not however have to make it GUI based. Text based interfaces are perfectly fine. I am not testing you on programming skills but rather that you can design a system to meet the requirements and then code to meet that design. Obviously you must have the basic programming skills in order to write the code but you do not have to make it fancy.

Implementation Approach:

As far as your code, it obviously must work and work correctly to meet all the requirements above and the game itself and the design you create. In addition, you need to make sure to use the good coding guidelines (e.g. layout, modularity, comments, etc.) that you have been reading about and the object oriented approach.

You will get partial credit when you have some mistakes in the code or it does not meet specification exactly HOWEVER, there are a few criteria that you must meet or you will not get any credit for the implementation. They include:

1. Your game must be Object Oriented – if you submit a program written as procedural or a single class, you will get 0 points for the implementation.

2. Your program must consist of the four classes indicated in the design section of the requirement specification document in section 2.2 and they must be implemented as described.

3. Your game must work with two human users and your program will be the last player as described in the requirements specification document. The player’s names have to be obtained and used throughout the program. If your design and/or implementation do not support this, you will receive 0 points for the implementation.

4. The design and implementation must include the menu as described in the requirements specification called from GameDriver::main(). No credit will be awarded if the design or implementation does not include the menu.

5. Your program must execute in order to get any points for it. If your program cannot be executed because of syntax and logic errors, no points will be awarded.

Your specification document at minimum must include (use the provided template):

· Introduction section (purpose, intended audience, product scope, references, system overview showing the basic flow and high level view of the functionality of the system)

· Design considerations section (assumptions, dependencies, constraints, and development approach)

· System Architecture - High-level view of your system’s architecture –chart showing high level objects and the interactions between them, specifically class diagram for OO structure (classes, attributes, and methods)

· Detailed design: For each class from the high-level view, give additional information: a short description of what it does and what other classes it interacts with. Each attribute should have a data type and what information it will store. Each method should have a description what it will be used for and what other methods it will interact with. If there is an algorithm related to a method (e.g. game flow) it should be described in English (not code or pseudo code).

· Human Interface Design section – the input/output described or shown as diagrams of all screens whether GUI or text-driven

Resources to help with project:

Project4-MSIT660-GradingCriteria.docx – criteria and points how the project will be graded

OOExampleSpecification.docx – a simple specification document that includes requirements and design to show you how the design is done for a problem OOExample.zip - code implementation of the OOExample so you can see how design maps to actual code

Code examples:

The self-assessment document you received the first week contains many examples of the Java or Python syntax you may find useful. They are there to help you with your design and coding for this project. You can use the design approaches and code in the examples I provide, modifying them for your particular design and game. You can also design and code your own way. I only provide these to help those new or struggling but if you know or like a different way, you are welcome to do it another way as long as you meet the instructions and guidelines I provide here.

Deliverables:

You must use the provided template (project4-specification-template.doc) for your design specification document. Your specification document must be in Microsoft .doc or .docx format named Your-name-Project4-Specification.docx and the working source code for the game. You can submit the source code as zip with all the Java or Python files in it.

Plagiarism reminder:

Make sure you write your own code. If you copy a solution from someplace and then modify it, you are plagiarizing and using someone else's work as your own. You are not submitting your original work. That is different from looking up how to do something in Java or Python, whether input/output, a loop, a menu, or a function in a tutorial example or an example I give you and then using that syntax as a model to write your own code and solution. Or looking up some other program, unrelated to RPS, whether in a textbook or online to again, give you an idea how to code something that you designed but do not know the Java or Python syntax for. If you found a RPS solution and copied from it, whether you modified it or not, you are plagiarizing. The exception is any examples I give you in this course. You can use as you wish in your design and programs.

References

http://en.wikipedia.org/wiki/Rock_paper_scissors

project4-specification-template.doc

Software Design Specification

for

<Project>

Version 1.0

Prepared by <author>

<organization>

<date created>

Table of Contents

iiTable of Contents

Revision History ii

1. Introduction 1

1.1 Purpose 1

1.2 Document Conventions 1

1.3 Intended Audience and Reading Suggestions 1

1.4 Product Scope 1

1.5 References 1

1.6 System Overview 1

2. Design Considerations 2

2.1 Assumptions and Dependencies 2

2.2 General Constraints 2

2.3 Goals and Guidelines 2

2.4 Development Methods 3

3. System Architecture 3

3.1 Architectural Strategies 3

3.2 High Level Overview of System Architecture 3

4. Human Interface Design 4

4.1 Screen Images 4

4.2 Screen Objects and Actions 4

5. Detailed System Design 4

5.1 Class 1 Name 4

5.2 Class 2 Name 5

5.3 Class 3 Name 6

Appendix A: Glossary 6

Revision History

Name	Date	Reason For Changes	Version

1. Introduction

1.1 Purpose

<Identify the product whose software design are specified in this document, including the revision or release number. Describe the scope of the product that is covered by this specification.>

1.2 Document Conventions

1.3 Intended Audience and Reading Suggestions

1.4 Product Scope

<Provide a short description of the software being specified and its purpose, including relevant benefits, objectives, and goals. Relate the software to corporate goals or business strategies.>

1.5 References

1.6 System Overview

2. Design Considerations

< This section describes many of the issues which need to be addressed or resolved before attempting to devise a complete design solution.>

2.1 Assumptions and Dependencies

< Describe any assumptions or dependencies regarding the software and its use. These may concern such issues as:

· Related software or hardware

· Operating systems

· End-user characteristics

· Possible and/or probable changes in functionality>

2.2 General Constraints

< Describe any global limitations or constraints that have a significant impact on the design of the system's software (and describe the associated impact). Such constraints may be imposed by any of the following (the list is not exhaustive):

· Hardware or software environment

· End-user environment

· Availability or volatility of resources

· Standards compliance

· Interoperability requirements

· Interface/protocol requirements

· Data repository and distribution requirements

· Security requirements (or other such regulations)

· Memory and other capacity limitations

· Performance requirements

· Network communications

· Verification and validation requirements (testing)

· Other means of addressing quality goals

· Other requirements described in the requirements specification>

2.3 Goals and Guidelines

< Describe any goals, guidelines, principles, or priorities which dominate or embody the design of the system's software. Such goals might be:

· The KISS principle ("Keep it simple stupid!")

· Emphasis on speed versus memory use

· Working, looking, or "feeling" like an existing product

For each such goal or guideline, unless it is implicitly obvious, describe the reason for its desirability. Feel free to state and describe each goal in its own sub-subsection if you wish.>

2.4 Development Methods

< Briefly describe the method or approach used for this software design (ex. OO or procedural approach). If one or more formal/published methods were adopted or adapted, then include a reference to a more detailed description of these methods. If several methods were seriously considered, then each such method should be mentioned, along with a brief explanation of why all or part of it was used or not used.>

3. System Architecture

3.1 Architectural Strategies

< Describe any design decisions and/or strategies that affect the overall organization of the system and its higher-level structures. These strategies should provide insight into the key abstractions and mechanisms used in the system architecture. Describe the reasoning employed for each decision and/or strategy (possibly referring to previously stated design goals and principles) and how any design goals or priorities were balanced or traded-off. Such decisions might concern (but are not limited to) things like the following:

· Use of a particular type of product (programming language, database, library, etc. ...)

· Reuse of existing software components to implement various parts/features of the system

· Future plans for extending or enhancing the software

· User interface paradigms (or system input and output models)

· Hardware and/or software interface paradigms

· Error detection and recovery

· Memory management policies

· External databases and/or data storage management and persistence

· Distributed data or control over a network

· Generalized approaches to control

· Concurrency and synchronization

· Communication mechanisms

· Management of other resources

Make sure that when describing a design decision that you also discuss any other significant alternatives that were considered, and your reasons for rejecting them (as well as your reasons for accepting the alternative you finally chose). Sometimes it may be most effective to employ the "pattern format" for describing a strategy.>

3.2 High Level Overview of System Architecture

< In this sub-section develop a modular program structure and explain the relationships between the modules to achieve the complete functionality of the system. Specifically provide a class diagram with classes, attributes, methods, and relationships between classes. Describe the diagram as required. >

4. Human Interface Design

<In this section, describe the characteristics of each interface between the software product and the users. In other words the input and output details that user will see and interact with>

4.1 Screen Images

< Display screenshots showing the interface from the user’s perspective. These can be hand drawn, power point charts, or you can use an automated drawing tool. Just make them as accurate as possible. Make sure to show all possible screens and exact messages that will be displayed to the user>

4.2 Screen Objects and Actions

< Provide a discussion of screen objects (buttons, text boxes, labels, pull downs, etc.) and actions associated with the objects you identified in the screen images in section 4.1. and any additional details to explain the interfaces show in the screenshots>

5. Detailed System Design

< Most components described in the System Architecture section will require a more detailed discussion. Other lower-level components and subcomponents may need to be described as well. Each subsection of this section will refer to or contain a detailed description of a system software component. The discussion provided for each component should cover the following software component attributes>

5.1 Class 1 Name

< Describe at high level all the primary responsibilities and/or behavior of this class. What does this class accomplish? What roles does it play? What kinds of services does it provide to its clients?>

5.1.1 Attributes

<List all the major attributes of the class with description of what they are used for and what values they will store>

5.1.2 Methods

<List all the major methods of the class with description of what they are used for, what attributes they may use or define, what other methods they may call>

5.1.3 Uses/Interactions

5.1.4 Constraints

< Any relevant assumptions, limitations, or constraints for this class. This should include constraints on timing, storage, or component state, and might include rules for interacting with this class (encompassing preconditions, postconditions, invariants, other constraints on input or output values and local or global values, data formats and data access, synchronization, exceptions, etc.).>

5.1.5 Resources

< A description of any and all resources that are managed, affected, or needed by this entity. Resources are entities external to the design such as memory, processors, printers, databases, or a software library. This should include a discussion of any possible race conditions and/or deadlock situations, and how they might be resolved.>

5.1.6 Processing

< A description of precisely how this components goes about performing the duties necessary to fulfill its responsibilities. This should encompass a description of any algorithms used; changes of state; relevant time or space complexity; concurrency; methods of creation, initialization, and cleanup; and handling of exceptional conditions.>

5.2 Class 2 Name

5.2.1 Attributes

<List all the major attributes of the class with description of what they are used for and what values they will store>

5.2.2 Methods

<List all the major methods of the class with description of what they are used for, what attributes they may use or define, what other methods they may call>

5.2.3 Uses/Interactions

5.2.4 Constraints

5.2.5 Resources

5.2.6 Processing

5.3 Class 3 Name

…

Appendix A: Glossary

<Define all the terms necessary to properly interpret the specification, including acronyms and abbreviations.>

Modified by Dr Renata Rand McFadden

SRS-RPSS-OO-Game.doc

Simplified Software Requirements Specification

Rock, Paper, Scissors, Saw Game

Revision History

Date	Description	Author	Comments
<7/11/2014>	<Version 1>	<Dr Renata Rand Mcfadden>	<First Revision>
<4/10/2015>	<Version 2>	<Dr Renata Rand Mcfadden>	<6-player version>
<7/03/2015>	<Version 3>	<Dr Renata Rand Mcfadden>	<2-player version>
<10/18/2015>	<Version 4>	<Dr Renata Rand Mcfadden>	<OO version>

Table of Contents

iRevision History

1. Introduction 1

1.1 Purpose 1

1.2 Scope 1

2. General Description 1

2. 1 Product Functions/Requirements Flow 1

2.1.1 Initial screen 1

2.1.1.1 Description 1

2.1.1.2 Stimulus/Response Sequences 1

2.1.1.3 Functional Requirements 2

2.1.2 Menu 2

2.1.2.1 Description 2

2.1.2.2 Stimulus/Response Sequences 2

2.1.2.3 Functional Requirements 2

2.1.3 Statistics 3

2.1.3.1 Description 3

2.1.3.2 Stimulus/Response Sequences 3

2.1.3.3 Functional Requirements 3

2.1.4 Play game 3

2.1.4.1 Description 3

2.1.4.2 Stimulus/Response Sequences 3

2.1.4.3 Functional Requirements 3

2.1.5 Rules 4

2.1.5.1 Description 4

2.1.5.2 Stimulus/Response Sequences 4

2.1.5.3 Functional Requirements 4

2.2 Classes / Objects 5

1. Introduction

This project requires students to create a design for a “Rock, Paper, Scissors, and Saw” game and then implement it in Java. This Software Requirements Specification (SRS) document will outline all the features required of the system.

1.1 Purpose

The purpose of this simple SRS is to provide all the basic requirements necessary to complete Software Design Specification (SDS) for Project 4 and to implement the system.

1.2 Scope

The software to be created will be a stand-alone PC representation of the hand game called “ Rock, Paper, Scissors, and Saw”, implemented with OO approach using Java. It will have two human players and a computer acting as the third player.

2. General Description

When user(s) starts the program, he will be prompted for the names of the two human players. These values will be used for all prompts and statistics in the program.

Then there will be a menu with the following selections: “1. Play game”, “2. Show game rules”, “3. Show statistics”, and “4. Exit” in that order. Rules selection will provide rules of the game, statistics will show the accumulative wins, loses, and ties per each player (both rounds and games), and exit will close the program.

When play game is selected, each player will be able to select his weapon (rock, paper, scissors, or saw) and computer will make its choice. Each of the players will be playing against the computer. A game will consist of 3 rounds. After each round either a player or computer will be the winner of the round and after 3 rounds, again either computer or player will be the winner of the game. User(s) will be able to run multiple games and their wins/loses/ties will be displayed in the statistics option along with the overall human winner.

2. 1 Product Functions/Requirements Flow

Below are all the basic requirements the system must satisfy

2.1.1 Initial screen

2.1.1.1 Description

When program starts, it needs to prompt user for the names of the two human players.

2.1.1.2 Stimulus/Response Sequences

User starts the program, prompt is displayed and user has to respond before program goes on.

2.1.1.3 Functional Requirements

[R1.1] User must be prompted with the following message “What is the name of the first player?” and then after correct response is supplies, “What is the name of the second player?”

[R1.2] User must type a string no longer than 20 characters and no less than 5 characters. For invalid input, program must issue an error message and re-prompt.

[R1.3] Second player name must be different from first player. For invalid input, program must issue an error message and re-prompt for the second player’s name.

[R1.4] Program will use the saved input value for prompting players for their weapons, issue messages, and to display statistics for all players.

[R1.5] Once correct response is given, program will display the menu.

2.1.2 Menu

2.1.2.1 Description

Program needs to display a menu with 4 selections: “1. Play game”, “2. Show game rules”, “3. Show statistics”, and “4. Exit” in that order.

2.1.2.2 Stimulus/Response Sequences

User correctly provides players’ names, menu is displayed, and user may select one of the 4 options.

2.1.2.3 Functional Requirements

[R2.1] Menu must be displayed correctly with provided naming of menu choices and in correct order and user can select one of the options by typing the corresponding number and pressing return.

[R2.2] Show rules selection must display all the rules for the game (see Rules requirement below for details) and how users can win. User will be able to return to the menu.

[R2.3] Statistics selection will display the accumulative statistics per round and game for each player. User will be able to return to the menu.

[R2.4] Exit selection must end the program with a “Goodbye” message.

[R2.5] Play selection will allow the user to play the game. Once game is completed, user will be able to return to the menu.

[R2.6] If user makes an invalid menu selection, error message will be displayed and user will be prompted again.

2.1.3 Statistics

2.1.3.1 Description

Program needs to keep track of the statistics.

2.1.3.2 Stimulus/Response Sequences

User selects “3. Show statistics” from the menu

2.1.3.3 Functional Requirements

[R3.1] Statistics selection will display the number of rounds each player won, lost, or had a tie against the computer, each players stats on new line

[R3.2] Statistics selection will display the number of games each player won, lost, or had a tie against the computer, each players stats on new line (winner of the game is one who won most rounds out of the 3 rounds and lost the least rounds)

[R3.3] Stats for each player will have his name and rounds and games stats will be shown on same line

[R3.4] Statistics selection will display the overall human winner based on the most won games and lost least games against the computer compared to other human players. If both players had same number of wins and losses for games, a tie will be announced for the overall winner

[R3.5] The statistics are accumulative until users exit the program.

[R3.6] On start of the program, all statistics are 0.

2.1.4 Play game

2.1.4.1 Description

Players will be allowed to select their weapons and after 3 rounds, the winners will be shown.

2.1.4.2 Stimulus/Response Sequences

Play game is selected from the menu.

2.1.4.3 Functional Requirements

[R4.1] When game starts, each Player gets prompted for his selection of Rock, Paper, Scissors, and Saw. The prompt must use the player’s name.

[R4.2] Computer makes its random selection to be used against each player (same selection will be used against both human players)

[R4.3] For each player, program displays that player’s selection, computer’s selection and who won that round (computer or player)

[R4.4] Next round repeats the prompting and announcement of the round winners. This is repeated for a total of 3 rounds.

[R4.5] Once all 3 rounds are completed winners of the game are announced for each player. Just like rounds, each player is playing against the computer and so the winner of the game is either the player or the computer.

[R4.6] The winner of the game is one who won most rounds. The program must account for ties. For example, if a player won 2 rounds and lost 1 round, then he won the game against the computer. If the player won 1 round, lost 1 round, and tied 1 round then he tied the game against the computer.

[R4.7] After game winners are announced, user is able to go back to menu where they can again select one of the options.

[R4.8] Users can play as many games as they want

2.1.5 Rules

2.1.5.1 Description

Rules of the game will be displayed and used to determine the winner.

2.1.5.2 Stimulus/Response Sequences

User selects ”2. Show game rules” and is given the rules or program need to determine a winner.

2.1.5.3 Functional Requirements

[R5.1] Winner of the round will be determined as follow:

a. Rock breaks scissors and Saw therefore rock wins over scissors and saw. Rock loses against paper.

b. Scissors cut paper therefore scissors win over paper. Scissors lose against rock and Saw.

c. Paper covers rock therefore paper wins over rock. Paper loses against scissors and saw

d. Saw cuts through scissors and paper therefore saw wins over scissors and paper. Saw loses against rock.

e. If player and computer make the same selection, there is a tie

[R5.2] Winner of the game against the computer is one who won more rounds (must account for ties)

[R5.3] Overall human winner is based on the greater number of won games against the computer and least games lost (must account for tie between human players)

[R5.4] The above rules will be displayed to the user

2.2 Classes / Objects

2.2.1 The software must have four classes as follow:

1. Player – stores all information related to a single player (whether human or computer)

a. Must have an attribute of type Statistics to store statistics data for the player

b. Must have attribute to store player’s name

2. Statistics – stores and displays all stats information for a single player (rounds and games).

3. Game – contains all the logic to play a game consisting of 3 rounds

a) Must have a method to display rules for winning and basic instructions how game is played (based on the requirements given)

b) Must have all the logic for playing automatically 3 rounds and announce winners of each round and winners of each game (based on the requirements given)

4. GameDriver – includes main() method that creates instances of all the other classes, prompts the user and then calls Game’s class methods to run the game.

a. Must prompt user for names of human players

b. Must display the menu and allow users to select from the menu.

c. Must create instances of the Players and initialize them

d. Must store Players in a list or array

e. Must create an instance of Game and start the game when user selects that option

2.2.2 Each class must be in a separate file. Files have to be named same as the class name (e.g. Player.java).

Software Requirements Specification Page 3

Proj4-MSIT660-GradingCriteria.docx

Grading Criteria

Project 4: Software Design Specification and Implementation

OO approach using Java

1. (5 points) Project is using the provided template. It is easy to read and follow, and uses correct grammar, punctuation, etc.

2. (5 points) The specification document includes meaningful and correct background information based on the given scenario to include introduction section (purpose, intended audience, product scope, references, system overview showing the basic flow and high level view of the functionality of the system)

Design (x/45):

*If design does not meet essential requirements, 0 points will be awarded for design.

Essential design includes:

1. Design is object oriented and includes the 4 classes (Player, Statistics, Game, and GameDriver)

2. The design and implementation must include the menu as described in the requirements specification called from GameDriver::main().

3. The program is designed to prompt for two human player names and use them for prompts, messages, and statistics.

4. There will always be two human players and computer acting as third player.

5. Each player will play against computer and statistics will declare one of the human as winner against the other human

3. (15 points) The specification document and the design account for all provided requirements

4. (10 points) The specification document describes the complete user interface and the full flow of the program (screens, details of input/output, diagrams, how to exit). There should be details on what user would see, what he could do and once he did some action what the result would be (for every path in the program and error paths).

5. (5 points) The specification document includes appropriate high level architecture description and class diagram and it is clearly modular using Object-Oriented approach.

6. (15 points) The specification includes appropriate class breakdown to include attributes, method signature, method descriptions and functionality, and indication which calls which

Implementation (x/45): ** If program contains syntax error and does not run, 0 points will be awarded for implementation

*** If program does not meet essential functionality, 0 points will be awarded for implementation.

Essential functionality includes:

1. Program is implemented with 4 classes (Player, Statistics, Game, and GameDriver)

2. Players are stored in an array or list

3. Program is implemented using Object Oriented approach

4. Program prompts for the human player names (stores in in Player instance) and uses that value appropriately throughout the program

5. Program prompts and calculates winners based on the given rules and the 4 weapons: Rock, Paper, Scissors, Sew

7. (10 points) Code correctly implements the design’s user interface (look and feel; input and output).

8. (10 points) Code correctly implements all functionality from design document and meets the requirements and does not implement something not identified in design

9. (10 points) Implementation matches the system architecture (class diagram), all classes, attributes, methods, and structures defined in design.

10. (5 points) The implementation is using good practices for modularity, naming convention, comments, and layout of code. Classes and methods are clean (cohesive, loosely coupled, etc.) and pass/return appropriate values.

11. (10 points) Code is accounting for error paths and user doing something unexpected. There are no obvious defects.