solitaire
Post on 19-Nov-2014
592 Views
Preview:
DESCRIPTION
TRANSCRIPT
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
top related