Spider Solitaire

DEPARTMENT OF COMPUTER SCIENCE

 Spider Solitaire

_________________

External:

_________________

Name of Advisor
Advisor:

____________________

Head of the Department:

DECLERATION

A thesis submitted to Department of Computer Science,

-------------------------------------------------------------- in partial fulfillment of requirement
for the degree of Bachelor of Computer Sciences.

No part of the work referred in this thesis is/ will be submitted to this or any other
university for grant of any other Degree/Certificate.
 TABLE OF CONTENT

DECLERATION

INCEPTION
Software Requirement Specification
Introduction
Purpose
Scope
Overview
Card Layout
Specific Requirements
Functionality
Design Constraints
Design Constrains for Scores
Design Constrains for Moving cards
Interfaces
User Interfaces
Hardware Interfaces
Software Interfaces
Supporting Information
Definitions, Acronyms, and Abbreviations
References
Use Case Diagram
Elaboration

Object Diagram
Class Diagram
Interaction diagram
Sequence diagram
State Diagram
Transition
Package Diagram

Deployment Diagram
Appendix A
INCEPTION

Inception is the beginning of the project. This phase can take on any of a number of
different forms. It can be comprised of anything from an informal conversation over
coffee to a group of well-structured meetings with a large number of people.

The purpose of this phase is to work out the rough overview of the project. Martin Fowler
says, "Inception should be a few days’ work to consider if it is worth doing a few
months’ work of deeper investigation during elaboration."

The goals of inception should be to get a good idea of the business case for the project.
How much will this project improve the bottom line? Another goal is to get a feel for the
scope of the project. How much will this project cost?

At the end of the inception phase the project’s sponsor has committed to no more than
taking a serious look at the project.

Depending on the size of the project you may find yourself doing some degree of analysis
in an effort to get a sense of the scope of the project during this phase. Inception can be
anything from a brief conversation to a full-fledged feasibility analysis taking many
months of work.
 Software Requirement Specification
Introduction
The SRS document provides the complete requirements of the project Spider
Solitaire.
This document provides the design and the analyses phases of this game.

Purpose
The basic purpose of the project, SPIDER SOLITAIRE is to provide
entertainment to the user and help to increase the IQ level of the user. Introducing
the better interfaces and increases the difficulty levels of the game, so user enjoy
to play it.

Scope
• The project will only provide documentation of the design and analysis phase
of the Spider Solitaire.
• The SRS will only cover the easy phase of the game.
• Calculate the score
• No code will be delivered.
• No hardware will be delivered
• It is a single user application.

Overview
The history of a group of card games known as Solitaire dates back to the mid-
18th century. Internationally, the game of solitaire has many names. It is often
called "Patience," especially in Britain. In France, the game is sometimes called
"Success" (reussite). Other languages, such as Danish, Norwegian and Polish
often use the word "Kabal" or "Kabala" (secret knowledge) to describe these
games.
In the 1980s, personal computers made solitaire more popular than ever. Since
players don't need to shuffle and deal the cards for each and every hand, game
play has become more enjoyable. In addition, the ability to start a new game with
only the click of a mouse has brought forward the addictive quality of these
games.
Where Spider Solitaire is the enhanced version of Solitaire. Spider solitaire is a
card game that is the built in feature of Windows XP. The word Solitaire is of
French origin, and it means patience. The object of Spider Solitaire is to remove
all of the cards from the ten stacks at the top of the window in the fewest number
of moves.

To remove cards from the ten stacks at the top of the window, move the cards
from one column to another until you line up a suit of cards in order from king to
ace. When you line up a complete suit, those cards are removed.
Card Layout
The game is played with two packs of playing cards. After thoroughly shuffling both
decks together, 4 rows of 10 face down cards are dealt to form the tableau columns. 4
more cards are dealt face down to the 4 leftmost columns and then a face up card is dealt
to the end of each column. The remaining cards are placed face down to form the stock
Specific Requirements

Functionality
Our project will perform the following functions.
1. Open the default game every time the user play the game.
2. Increase or decrease the score according to the rules.
• Each time user move a card, one point will be decremented.
• Each time you click the Game menu, and then click Undo, one point will be
decremented.
3. Each time user line up an entire suit in order from king to ace, the suit is removed
from the playing area, 100 points will be added in the score.
4. Remove the pile that are in order
5. After the deal insert a new row

Design Constraints
Design Constrains for Scores

Users begin each game of Spider Solitaire with 500 points. User can increase or
decrease user score based on these rules:

• Each time user move a card, user lose one point.

• Each time user click the Game menu, and then click Undo, user lose one point.
• Each time user line up an entire suit in order from king to ace, the suit is removed
from the playing area, and user get 100 points

Design Constrains for Moving cards

1. To move a card, drag the card from one stack to another. User can move cards
according to these rules:
o User can move a card from the bottom of a stack to an empty stack.
o User can move a card from the bottom of a stack to a card with the next
highest value, regardless of suit or color.
o User can move a set of cards all of the same suit, and in order, as if they
were one card.
2. When user is ready to deal a new row of cards, click Deal, or click a stack of
cards in the lower-right corner of the window.

Each stack must contain at least one card before user deal a new row.
Interfaces
User Interfaces
As the game is single user application it has only one interface that displayed as
the game open/start.

Hardware Interfaces
• PC with minimum requirements 128 MB RAM
• Pentium III
• Maximum 20 GB Hard Disk
Software Interfaces
• Development tools
VB.net / Java /C#
• Documentation Tools
Microsoft Word 2003, Rational Rose 2002
• Operating system
Windows XP and Windows Vista
Supporting Information
Definitions, Acronyms, and Abbreviations
Drag: To move an item on screen by selecting the item and then pressing and
Holding down the mouse button while moving the mouse.
Suit: Cards can only be placed on a card of the same suit
Stock: A pile containing the remainder of the cards after all the rest of the piles
have been dealt. Cards are usually dealt from the stock in some way, such as to a
waste pile or to tableau piles.
Tableau: This consists of a number of piles of cards where cards can be moved
from one area to another, under varying rules. Some allow stacks of cards which
match the building requirements to be moved, others only allow the top card to be
moved, yet others allow any stack to be moved.

References
http://justsolitaire.com/history.php (history of spider solitaire)
http://www.solitairecity.com/Help/Spider.shtml (card layout)
http://www.jamesbooth.com/iterativeoop.htm
Data provide in the contents of built-in game.
 Use Case Diagram

A use case describes a sequence of actions that provide a measurable value to an actor. A
use case is drawn as a horizontal ellipse on a UML use case diagram

Type of Use case

1.By Importance
Primary use case - is a major process.
Secondary use case - is a minor process.
Optional use case - is a process that may not
be tackled.

2.By Functionality "

Administrative Use cases – “back up”, “start up”, and” shut down”
Routine Use Cases – “generate report”, ”log in”, “log out”
Core uses cases –“process rent ”, process returns””

3.By Level
Essential use case - is independent of user
interface.
Concrete use case or real Use cases- embeds UI
decisions.
 New Game
<<Included> Move Cards
> <<Included>
> <<Included>
> Deal a Row

<<Excluded> <<Excluded>
Game Exit
> >
<<Excluded>
> <<Excluded>
> Restart Game
Undo Card

Save Game
Show Available Move

<<Included>
>
User
Contents
<<Included>
Help
>

About Spider

<<Included>
>
increment in score

Scores <<Included>
>

decrement in score

USE CASE DIAGRAM

For detail description refer to Appendix A

Elaboration

At this point you only have a very general idea of what the project is to be. Perhaps you
can say;

"We will build a software application that will manage the activities of a bowling alley
including the scheduling of lanes and leagues, the printing of league schedules, the
scheduling of employees, the record keeping of cash collections, and the management of
maintenance."

Your requirements documentation may have a lot more text in it but it does not likely say
very much more at this point.

The questions to be answered in this phase are, What are you actually going to build?,
How are you going to build it?, and What technologies will you be using to build this?

The major focus during this phase should be on the risks that you will face. What are the
things that could derail your project and how are you going to handle those? You should
be identifying these risks according to how much of a potential problem they are. The
bigger the risk the more attention you should pay to it.

These risks can be categorized into the groups described in the previous section. In order
to find the risks you need to begin to do a detailed analysis and design of the complete
system. The first place to start is with the domain model for the system. Once you have
the domain model in place, then move onto to the use cases for the system, and finally
combine the domain model and the use cases into a design model.
 Object Diagram

Game

Help

Display

Deal

Scores
 Class Diagram

Game
<<Interface>> int deal count
Display int cardstoopen
deck deck
static int start[][]
pack pack
static int end[][]
history history
int equal
pile piles[]
final heap[ ] finals[ ]
void print board()
pile s elected
boolean changed
Score
int defualt score tableau()
dealpiles()
void calculate score() boolean nopileempty()
void setbonus() boolean all cards mat ch()
boolean getbonus() void select()
Deal void unselect ed()
pack source void move()
pile deatination[] Help void showmove()
int hp
deal()
char qurey[]
void execute()
bool checkstack()
show contents()
about spider()
 Interaction diagram
Interaction diagrams describe exemplary how groups of objects collaborate in some
behavior. An interaction diagram typically captures the behavior of a single use case.
Interaction diagrams do not capture the complete behavior, only typical scenarios.
The two types of interaction diagram are:
• Sequence Diagram
• Collaboration Diagram

Sequence diagram
Sequence diagrams emphasize the order or concurrency of the interactions. Sequences
diagram are based on success full scenarios

Scenario1: Move Card

display game move card

print board()
move ()
exit()

Description:
This scenario shows the flow of the movement of the cards how they move and user
can play the game.
Scenario2: Deal Row

Display Move cards Deal

print board()
move()

deal()

Description:
This scenario shows the flow of the deal a row when the user deal then ten different are
selected and display a new row on tableau.
Scenario3: Score

display Move cards score

print board() claculate()

exit()

Description:
This scenario shows the flow of the scores. When user make a move or check the
available move one point is subtracted from the scores and when user arrange all the 13
cards 100 points are added in the score.
 State Diagram
State diagrams are technique to describe the behavior. State can be achieved performing
multiple activities or processes. The following is the sate diagram of the spider solitaire.

Deal

Play Game Stack

Selection
Move
card Undo card
Insert row

Show hidden
Card

Help

Pass query
Quit

Show data

Description: These are the different sates of the project. The line shows the bi-
directional relation ship between the sate user can move between theses sates.
Transition

Transition is the final phase of the iterative development approach. Transition handles
those issues that were not addressed during construction. Perhaps there is some final
integration to be done after all subsystems are built. A good example of a problem that
would be addressed during transition is optimization for performance.

Optimization usually sacrifices clarity and ease of integration to increase performance.

This is not something that we want to do early in a project’s development, as it will
increase the difficulty in building the project. Instead we would leave optimization to the
transition phase when all of the subsystems have been built and tested. Optimization is
also an elusive goal. Often we, as developers, perceive a performance problem where
users will never notice it. We also will overlook a problem in performance that users will
readily recognize. If we start optimizing a system before the users can tell us where it is
slow we will be spending time and effort in the wrong places.

Transition can be thought of as that period of time between the release of the beta version
and the final version of the project. There will likely be "bug fixes", functional
enhancements, performance optimization, and other things done during this phase.
Sometimes we may discover an entirely new use case that needs to be built. The iterative
development approach allows us to easily process this new use case and then reenter the
transition phase.
 Package Diagram

spider solitare

Help
<<Interface>>
int hp
Display
char qurey[]
static int start[][]
static int end[][] show content s()
int equal about spider() Game
void print board() int deal count
deck
piles
Score
int defualt score t abelau()
Deal
pack source deal piles()
void calculate score() move()
pile deatination[] void setbonus() s how move()
boolean getbonus()
deal()
void execute()
bool checkstack()
 Deployment Diagram

Spider
Solitaire

PC
Appendix A