Difference between revisions of "Software Architecture Document (Golf App)"

From Secure Computing Wiki
Jump to: navigation, search
(Created page with "== About this document== This document provides a basic architectural overview of the product, summarizing the key architectural issues and the solutions that have been decided ...")
 
 
(One intermediate revision by one other user not shown)
Line 7: Line 7:
 
=== Overview ===
 
=== Overview ===
  
Overview and development environment: The Laser Chess game will be built using the [http://www.eclipse.org Eclipse Editor] for the [http://www.android.com/market Android Market] since all users of Android Phones will be able to use the Android Market as it comes preinstalled on the devices that will run our game
+
Overview and development environment: The golf app will be built using the [http://www.eclipse.org Eclipse Editor] for the [http://www.android.com/market Android Market] since all users of Android Phones (and to a lesser degree tablets) will be able to use the Android Market as it comes preinstalled on the vast majority of the devices that will run our game.
 +
 
 +
As far as coding the application, we are currently evaluating several methods to share code but are leaning towards a solution using [[SVN]] on the same server that is hosting this wiki. Since none of the members of our group have worked with Android programming prior to the start of this class, we have also started sharing information [[Android_Development]].
  
 
==== Issues in core program that have been decided ====
 
==== Issues in core program that have been decided ====
Line 13: Line 15:
 
We have determined that:
 
We have determined that:
  
* the four different pieces will have the majority of information stored in a piece object that will be the parent object
+
* the app will have both pre-populated data and user-entered data on each hole
* the board will have the information for which pieces are on which squares and which square is which color
+
* there will be scoring functionality in the app
 +
* the date and personal scores will be included
  
  
 
==== To be considered ====
 
==== To be considered ====
  
Important aspects of the architecture include the ability to run 100k players at anytime peak load and the game must run with minimal bandwidth as per the [[Non-Functional Requirements]]. Solution will be worked in later iterations in the interests of getting a working product to market faster without this feature.
+
Important aspects of the architecture include the ability to balance showing both hole info and hole notes as well as score on a small screen, while allowing the user to enter both score and hole notes easily and intuitively as possible.
  
We also need to be able to have the AI be challenging enough to be something a human player will have trouble beating, but easy enough so that a human player can beat an AI player. Solution will be worked in later iterations in the interests of getting a working product to market faster without this feature.
+
We also need to be able to have a scalable solution so that we can add other features such as score sharing between devices (advanced feature that may be outside the scope of this class) and multiple golf courses (may be added during the iterations in the class). Some of the ideas so far are listed in the [[Feature Ideas (Golf App)]] document.
  
<span style="color:darkred">The pieces have some special move types, as defined in the [[Game Rules]] and [[Glossary]]. These need to be accounted for when coding each piece and the board needs to be able to handle more than one piece on a square at once.</span>
 
  
 
== Use-Case View ==
 
== Use-Case View ==
Line 29: Line 31:
 
see [[Use Cases (Golf App)]]
 
see [[Use Cases (Golf App)]]
  
{{AgileProcessforAndroidGameFooter}}
+
{{CapstoneFooter}}

Latest revision as of 15:08, 23 May 2011

About this document

This document provides a basic architectural overview of the product, summarizing the key architectural issues and the solutions that have been decided upon. In other words, it is intended to capture and convey the significant architectural decisions which have been made for this game. Logical, Deployment and Process Views may be added later.

Architectural Factors & Decisions

Overview

Overview and development environment: The golf app will be built using the Eclipse Editor for the Android Market since all users of Android Phones (and to a lesser degree tablets) will be able to use the Android Market as it comes preinstalled on the vast majority of the devices that will run our game.

As far as coding the application, we are currently evaluating several methods to share code but are leaning towards a solution using SVN on the same server that is hosting this wiki. Since none of the members of our group have worked with Android programming prior to the start of this class, we have also started sharing information Android_Development.

Issues in core program that have been decided

We have determined that:

  • the app will have both pre-populated data and user-entered data on each hole
  • there will be scoring functionality in the app
  • the date and personal scores will be included


To be considered

Important aspects of the architecture include the ability to balance showing both hole info and hole notes as well as score on a small screen, while allowing the user to enter both score and hole notes easily and intuitively as possible.

We also need to be able to have a scalable solution so that we can add other features such as score sharing between devices (advanced feature that may be outside the scope of this class) and multiple golf courses (may be added during the iterations in the class). Some of the ideas so far are listed in the Feature Ideas (Golf App) document.


Use-Case View

see Use Cases (Golf App)

Project Topics

Reference Material