Spider Solitaire

DEPARTMENT OF COMPUTER SCIENCE

Spider Solitaire

_________________

External:

_________________

Name of AdvisorAdvisor:

____________________

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

Phase 1: InceptionChp1: Software Requirement SpecificationChp2: Use Case Diagram

Phase 2: ElaborationChp1: Object DiagramChp2: Class DiagramChp3: Sequence diagramChp4: State Diagram

Phase 3:TransitionChp1: Package DiagramChp2: Deployment Diagram

Appendix AChp1: Use Case Specification

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 SpecificationIntroduction

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 stockSpecific 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 toolsVB.net / Java /C#

Documentation ToolsMicrosoft Word 2003, Rational Rose 2002

Operating systemWindows XP and Windows Vista

Supporting Information

Definitions, Acronyms, and Abbreviations

Drag: To move an item on screen by selecting the item and then pressing andHolding down the mouse button while moving the mouse.Suit: Cards can only be placed on a card of the same suitStock: 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 ImportancePrimary 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 LevelEssential use case - is independent of user interface. Concrete use case or real Use cases- embeds UI decisions.

USE CASE DIAGRAM For detail description refer to Appendix A

User

Game

New Game

Move Cards

Deal a Row

Exit

Restart GameUndo Card

Save Game

Show Available Move

HelpContents

About Spider

increment in score

Scores

decrement in score

<<Included>> <<Included>

>

<<Excluded>>

<<Excluded>>

<<Included>>

<<Included>>

<<Excluded>>

<<Excluded>>

<<Included>>

<<Included>>

<<Included>>

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

Display

Game

Help

Scores

Deal

Class Diagram

Deal

pack sourcepile deatination[]

deal()void execute()bool checkstack()

Help

int hpchar qurey[]

show contents()about spider()

Display

static int start[][]static int end[][]int equal

void print board()

<<Interface>>

Score

int defualt score

void calculate score()void setbonus()boolean getbonus()

Game

int deal countint cardstoopendeck deckpack packhistory historypile piles[]final heap[] finals[]pile selectedboolean changed

tableau()dealpiles()boolean nopileempty()boolean all cards match()void select()void unselected()void move()void showmove()

Interaction diagramInteraction 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 diagramSequence diagrams emphasize the order or concurrency of the interactions. Sequences diagram are based on success full scenarios

Scenario1: Move Card

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

gamedisplay move card

move ()print board()

exit()

Scenario2: Deal Row

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.

print board()

Move cardsDisplay Deal

move()

deal()

Scenario3: Score

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.

Move cardsdisplay score

exit()

print board() claculate()

State DiagramState 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.

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.

Stack Selection

Insert row

Deal

Help

Show data

Pass query

Play Game

Move card

Undo card

Show hidden Card

Quit

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

Help

int hpchar qurey[]

show contents()about spider()

Display

static int start[][]static int end[][]int equal

void print board()

<<Interface>>

Deal

pack sourcepile deatination[]

deal()void execute()bool checkstack()

Score

int defualt score

void calculate score()void setbonus()boolean getbonus()

Game

int deal countdeckpiles

tabelau()deal piles()move()show move()

spider solitare

Deployment Diagram

PC

Spider Solitaire

Appendix A