Permalink
Browse files

Merge branch 'master' of github.com:pitfail/pitfail-reports

  • Loading branch information...
2 parents 8698344 + f3304e8 commit 68b4287ba707fca187a122631b769d6e19bb9c61 @jmesmon jmesmon committed Dec 14, 2011
View
147 report3/architecture.rst
@@ -287,153 +287,6 @@ as new notifications with a unique ID to the Notification Manager. The Notificat
then displays the stock update message as a New Notification on Android Status Bar. The user
can clear the Notifications whenever he wants.
-Operations via FaceBook Interface
----------------------------------
-
-Facebook interface currently supports 4 operations:
-
-1. Buy Stocks.
-2. Sell stocks.
-3. View Portfolio.
-4. View Leaderboard.
-
-If a player wants to access PitFail via Facebook, he or she can post the
-request on PitFail's wall in the following format:
-
-Username: Operation(Buy/Sell):[volume]:[Ticker]
-
-Arguments in square brackets are optional. For example, View portfolio and view
-leaderboard operations do not take volume and ticker as arguments.
-
-The request posted on the wall needs to be processed. To process this request :
-
-1.This request should be listened to and FB app should be notified of the wall post
-2.The wall post should be read and parsed.
-3.The request should invoke appropriate module from server to get the operation done
-4.The player should be notified of the status of the request (successful/failed)
-
-The operations takes place partly at Facebook client side and partly at server side.
-
-Here is a description in detail:
-
-FaceBook Client:
-................
-
-Facebook client includes mainly two operations:
-
-1. FBListener -- FBListener listens to our facebook page pitfail and notifies
- the app controller of any incoming request (a wall post) to be processed.
-2. ParseMessage -- ParseMessage parses user's wall post to multiple token ,
- checks if the message follows the required syntax and decides if the message
- is good enough to be processed. Figure :ref:`parseMessage`.
-
-.. figure:: figures/FB/parseMessage
- :width: 90%
-
- :label:`parseMessage`
-
-FBListener listens to the wall post of our account and notifies pitFail FB app
-of any new wall post. We use RestFB APIs that access Facebook account of
-PitFail using the unique access token provided by FaceBook. API
-fetchConnection(User) reads the new wall post and passes it to ParseMessage
-module. ParseMessage processes the wall post, extracts the information required
-to process the request. It also checks for the right number of arguments and
-the data type (e.g. Volume has to be a number, a request to view portfolio does
-not take more than two arguments).
-
-If the message is good enough to be processed (no errors), client controller
-calls appropriate functions from the server, otherwise the player is notified
-of the error by commenting on player's wall post.
-
-Server Operations:
-..................
-
-Now once the message is retrieved and parsed at the client side, the server
-functions are invoked with the parsed tokens as arguments.
-
-Before processing any request, we always check if the username that is
-requesting this operation is valid or not. Therefore before invoking any other
-method client invokes EnsureUser method to enusure the authenticity of the
-user.
-
-Ensure User:
-````````````
-
-Facebook interface of PitFail does not (for now) support registration. The
-player has to be already registered to the system to play the game via FB
-interface. Figure :ref:`ensureUser`
-
-.. figure:: figures/FB/ensureUser
- :width: 90%
-
- :label:`ensureUser`
-
-ensureUser ensures the existence of a user before the user's request tries to
-access portfolio. If the user exists, the request is processed further
-otherwise the player is notified of the error occurred by posting a comment on
-his wall post.
-
-Once the user is checked for his/her authenticity, we can proceed further with
-the actual operation requested by the user. Below are the operations user can
-execute.
-
-Buy Stock:
-``````````
-
-for all the operations below, once the ensureUser
-confirms the authenticity of the user, FaceBook client invokes a Java servlet
-on Jetty server. The main task handled by this java servlet is to accept
-arguments from Facebook client and invoke appropriate scala mothods to perform
-task requested by facebook client Here the servlet is: FBBuyServlet(Username).
-Figure :ref:`fbbuy`
-
-.. figure:: figures/FB/buy
- :width: 90%
-
- :label:`fbbuy`
-
-Sell Stock:
-```````````
-
-In sell stock , FBSellServlet() is the Java servlet that accepts arguments from
-Facebook client and invokes scala method to sell stocks. Figure :ref:`fbsell`
-
-.. figure:: figures/FB/sell
- :width: 90%
-
- :label:`fbsell`
-
-View Portfolio:
-```````````````
-
-Before processing any request , we make sure (by invoking ensureUser) that the
-username exists. Therefore there is no failure flow (alternate flow) for
-portfolio view. We will invoke this funtion only if the ensureUser confirms
-that the user exists. Figure :ref:`fbport`
-
-.. figure:: figures/FB/port
- :width: 90%
-
- :label:`fbport`
-
-Once client receives response (portfolio for the username) from server, client
-prettifies the response make it look better as FaceBook wall post.
-
-View Leaderboard:
-`````````````````
-
-Apart from the leagues created by different users, we have a global league.
-Players playing via facebook can view the leaders of global league by using
-operation - view leaderboard.
-
-Here too, we dont have a alternate (failure) flow, as this method will be
-invoked only once ensureUser confirms that the username exists. :ref:`fbleader`
-
-.. figure:: figures/FB/leader
- :width: 90%
-
- :label:`fbleader`
-
Interacting with a Trading Simulation over Twitter
==================================================
View
BIN report3/figures/pipeline.dia
Binary file not shown.
View
BIN report3/figures/textpipeline.dia
Binary file not shown.
View
116 report3/glossry.rst
@@ -1,116 +0,0 @@
-
-Here we attempt to clarify possibly ambiguous words as they are used in
-PitFail. We are not defining these words in general; just what they mean in
-this document.
-
-Ask Price
-
- The price at which a trader is willing to sell a stock. [Ask]_
-
-Asset
-
- Either a stock or the buyer end of a derivative contract.
-
-Bid Price
-
- The price a trader is willing to pay for a stock. PitFail has its own
- opinion (independent of Yahoo Finance) of what the bid price of a stock is,
- because PitFail players can trade with one another [Bid]_.
-
-Client
-
- A system that is not running on PitFail's server. An example is a
- webbrowser, or the Android phone.
-
-Company
-
- A synonym for Portfolio.
-
-Consistency
-
- Obeying all explicit or implied contracts (e.g., types describe a form of
- consistency).
-
-Controller
-
- The part of MVC that operates on the Model but is not represented by a
- domain concept.
-
-Form
-
- The main mode of interacting with the website frontent. User enters values
- and submits them.
-
-Last Traded Price
-
- The price which Yahoo Finance considers to be the last traded price of a
- stock.
-
-Leaderboard
-
- A list of the highest ranked portfolios in a League.
-
-League
-
- A group of portfolios that compete against each other. `Users, Portfolios,
- and Leagues`_
-
-Liability
-
- The seller end of a derivative contract.
-
-Limit Order
-
- An order to buy or sell a stock at any available price within some bound [Limit]_.
-
-Model
-
- The part of MVC that maintains the state of the system. The Model is where
- concepts from the Domain Model are realized as code.
-
-Player
-
- A human being interacting with PitFail.
-
-PitFail
-
- The entire trading simulation, including the backend, the various clients,
- and the players playing it.
-
-Portfolio
-
- A portfolio in pitfail is the primary concept in trading; the one that
- makes trades, owns stocks, etc. See `Users, Portfolios, and Leagues`_.
-
-Price
-
- Dollars per share.
-
-Scale
-
- A unitless number.
-
-Side-effect
-
- A result of invoking a function that is hidden by the function's signature. [SideEffects]_
-
-Stock
-
- PitFail recognizes as a stock anything that Yahoo Finance is willing to
- assign a price to.
-
-Team
-
- A synonym for Portfolio.
-
-User
-
- A user is a single account in the PitFail system. A single user typically
- corresponds to 1 player. See `Users, Portfolios, and Leagues`_.
-
-View
-
- The part of MVC that is visible to the user. The View may include HTML
- files, presentation-specific code, protocols for communicating with the
- user (e.g. HTTP), stylesheets.
-
View
43 report3/report3.rst
@@ -44,41 +44,13 @@
Individual Contributions
########################
-//TODO
-.. raw:: latex
-
- \begin{center}
- \small
-
-.. csv-table::
- :header: "Responsibility", "Michal Koval", "Cody Schafer", "Owen Healy", "Brian Good-acre", "Roma Mehta", "Sonu Iqbal", "Avanti Kulkarni"
- :widths: 15, 6, 6, 6, 6, 6, 6, 6
-
- Customer Reqs. (6), , , , , , , 100%
- Glossary of Terms (4), %, 10%, 10%, 10%, 10%, 10%, 10%
- Functional Reqs., , , , , , ,
- ? Stakeholders (2), , 100%, , , , ,
- ? Actors (2), , 100%, , , , ,
- ? Goals (4), %, 50%, , , , ,
- ? Casual UC (5), , 100%, , , , ,
- ? Dressed UC (11), %, 20%, , 40%, , ,
- ? UC Diagram (4), , 100%, , , , ,
- ? UC Tracability, %, , , , ,
- Seq. Diagrams (9), , , , , , 100%,
- Nonfunc. Reqs. (6), , , , , , 100%,
- Domain Analysis, , , , , , ,
- ? Concepts (12), , , 100%, , , ,
- ? Associations (4), , , 100%, , , ,
- ? Attributes (3), , , 100%, , , ,
- Contracts (6), , , , , 100%, ,
- User Interface (8), %, , , , , ,
- Plan of Work (3), , , , 100%, , ,
- References (1), 14%, 14%, 14%, 14%, 14%, 15%, 14%
+All team members contributed in ways which are too layered and interlinked to
+quantify.
.. raw:: latex
- \end{center}
+ \pagebreak
Summary of Changes
##################
@@ -153,11 +125,12 @@ Effort Estimation using Use Case Points
Class Diagram and Interface Specification
#########################################
-..TODO
-Object Constraint Language (OCL) Contracts
-##########################################
-..TODO
+.. include:: uml-comments.rst
+
+.. raw:: latex
+
+ \includepdf[fitpaper=true]{figures/class-diagrams/diagrams.pdf}
History of Work & Current Status of Implemenation
#################################################
View
184 report3/signatures.rst
@@ -0,0 +1,184 @@
+
+Shares (model package)
+- Attributes
+ - +shares: BigDecimal
+ - +<<operator>> -: Dollars
+ - +<<operator>> ###: String
+- Methods
+ - +<<constructor>>(BigDecimal)
+ - +<<constructor>>(String>
+ - /compare(Shares): Int
+ - +<<operator>> +(Shares): Shares
+ - +<<operator>> -(Shares): Shares
+ - +<<operator>> *(Price): Dollars
+ - +<<operator>> *(Scale): Shares
+
+Price (model package)
+- Attributes
+ - +price: BigDecimal
+ - +<<operator>> $: String
+- Methods
+ - +<<constructor>>(BigDecimal)
+ - +<<constructor>>(String)
+ - /compare(Price): Int
+ - +<<operator>> +(Price): Price
+ - +<<operator>> -(Price): Price
+ - +<<operator>> *(Shares): Dollars
+ - +<<operator>> *(Scale): Price
+
+Dollars (model package)
+- Attributes
+ - +dollars: BigDecimal
+ - +<<operator>> -: Dollars
+ - +<<operator>> $: String
+- Methods
+ - +<<constructor>>(BigDecimal)
+ - +<<constructor>>(String)
+ - +/compare(Dollars): Int
+ - +<<operator>> +(Dollars): Dollars
+ - +<<operator>> -(Dollars): Dollars
+ - +<<operator>> *(Scale): Dollars
+ - +<<operator>> -/-(Price): Shares
+ - +<<operator>> /-/(Price): Shares
+
+Scale (model package)
+- Attributes
+ - +price: BigDecimal
+ - +<<operator>> -: Scale
+ - +<<operator>> %: String
+- Methods
+ - +<<constructor>>(BigDecimal)
+ - +<<constructor>>(String)
+ - /compare(Scale): Int
+ - +<<operator>> +(Scale): Scale
+ - +<<operator>> -(Scale): Scale
+ - +<<operator>> *(Price): Price
+ - +<<operator>> *(Shares): Shares
+ - +<<operator>> *(Scale): Scale
+
+Stock (model.schema package)
+- Attributes
+ - +symbol: String
+ - +toString: String
+
+Quote (model.schema package)
+- Attributes
+ - +stock: Stock
+ - +exchange: String
+ - +price: Price
+ - +updateTime: ateTime
+ - +info: QuoteInfo
+ - +toString: String
+- Methods
+ - /equals(Quote): Boolean
+
+QuoteInfo (model.schema package)
+- Attributes
+ - +percentChange: Option[BigDecimal]
+ - +openPrice: Option[BigDecimal]
+ - +lowPrice: Option[BigDecimal]
+ - +highPrice: Option[BigDecimal]
+ - +dividendShare: Option[BigDecimal]
+- Methods
+ - /equals(Quote): Boolean
+
+StockDatabase (stockdata package)
+- Methods
+ - +getQuote(Stock): Quote
+ - +getQuotes(Seq[Stock]): Seq[Quote]
+
+YahooYQLStockDatabase (stockdata package)
+- Attributes
+ - -queryService: HttpQueryService
+- Methods
+ - +<<constructor>>(HttpQueryService)
+ - +getQuote(Stock): Quote
+ - +getQuotes(Seq[Stock]): Seq[Quote]
+
+YahooCSVStockDatabase (stockdata package)
+- Attributes
+ - -queryService: HttpQueryService
+- Methods
+ - +<<constructor>>(HttpQueryService)
+ - +getQuote(Stock): Quote
+ - +getQuotes(Seq[Stock]): Seq[Quote]
+
+CachingStockDatabase (stockdata package)
+- Attributes
+ - -database: StockDatabase
+ - -cache: Map[Stock, Quote]
+- Methods
+ - +<<constructor>>(StockDatabase)
+ - +getQuote(Stock): Quote
+ - +getQuotes(Seq[Stock]): Seq[Quote]
+
+FailoverStockDatabase (stockdata package)
+- Attributes
+ - databases: Seq[StockDatabase]
+- Methods
+ - +<<constructor>>(Seq[StockDatabase])
+ - +getQuote(Stock): Quote
+ - +getQuotes(Seq[Stock]): Seq[Quote]
+
+HomeScreen (android package)
+ - Attributes
+ - -activity: Activity
+ - -spinner: Spinner
+ - -indexOfUserNameForSpinner: Int
+ - -search: Button
+ - -sell: Button
+ - -team: Button
+ - -leaderboard: Button
+ - -cashText: TextView
+ - -ticker: AutoCompleteTextView
+ - -companies: String[*] {unique}
+ - Methods
+ - +onCreate(Bundle): Unit
+ - +onClick(View): Unit
+ - +afterTextChanged(Editable): Unit
+ - +beforeTextChanged(CharSequence, Int, Int, Int): Unit
+ - +onTextChanged(CharSequence, Int, Int, Int): Unit
+
+BuyDetail (android package)
+ - Attributes
+ - -tickerName: TextView
+ - -buy: Button
+ - -activity: Activity
+ - -tickerString: String
+ - -valueString: ArrayList<String>
+ - Methods
+ - +onCreate(Bundle): Unit
+ - +ImageOperations(String, String): Drawable
+ - +fetch(String): Object
+
+PortfolioDetail (android package)
+ - Attributes
+ - -cashText: TextView
+ - -portfolioHeader: TextView
+ - -selectedPortfolio: String
+ - Methods
+ - onCreate(Bundle): Unit
+
+NewTeam (android package)
+ - Attributes
+ - -portfolio: EditText
+ - -invite: EditText
+ - -inviteButton: Button
+ - -activity: Activity
+ - Methods
+ - +onCreate(Bundle): Unit
+ - +onClick(View): Unit
+
+LeaderBoard (android package)
+ - Methods
+ - onCreate(Bundle): Unit
+
+PollingService (android package)
+ - Attributes
+ - TAG: String { readonly }
+ - timer: Timer
+ - update_id: Int
+ - Methods
+ - onBind(Intent): IBinder
+ - onCreate(): Unit
+ - onDestroy(): Unit
View
5 report3/status.rst
@@ -1,9 +1,4 @@
-Gantt Chart
-============
-
-include pdf for the *Plan of Work*
-
Comparison to Planned Milestones
================================
View
1 report3/stylesheet.tex
@@ -3,6 +3,7 @@
\usepackage{graphicx}
\usepackage{fullpage}
\usepackage{setspace}
+\usepackage{pdfpages}
\usepackage[utf8]{inputenc}
% Without these, fonts in PDF's generated by MiKTeX (windoes)
View
90 report3/uml-comments.rst
@@ -0,0 +1,90 @@
+
+Comments on the UML
+===================
+
+stockdata
+---------
+
+It might be surprising that the classes ``FailoverStockDB``,
+``YahooYQLStockDB``, ``YahooCSVStockDB``, and ``CachingStockDB`` do not have
+any associations with each other. The reason is that, for benefits of
+testability, the ``stockdata`` classes are design with dependency injection.
+This allows each one to be tested individually without requiring any of the
+others.
+
+When the classes are actually used, they are built into a pipeline, for
+example (Figure :ref:`pipeline`):
+
+.. figure:: figures/pipeline
+ :width: 90%
+
+ :label:`pipeline` The pipeline architecture of the stock querying classes.
+
+
+model.schema
+------------
+
+These closely resemble the concepts in the Domain Model (See `Domain Model`_).
+The biggest omission is that some of the Domain Concepts do not appear in actual
+code:
+
+1. The "execution" of a trade was represented as a concept, but does not appear
+ in the code as a class.
+
+2. Likewise the "cancellation" of a trade.
+
+3. A DividendEvent appeared as a concept but is merely procedural in the code.
+
+Also not that some of the arrows in the UML diagram are encapsulated in
+association classes (See Figure :ref:`association`).
+
+texttrading
+-----------
+
+The texttrading code should also be viewed as a pipeline (Figure :ref:`textpipeline`):
+
+.. figure:: figures/textpipeline
+ :width: 90%
+
+ :label:`textpipeline` The pipeline architecture of texttrading.
+
+website.control
+---------------
+
+This is the stateful part of the website: storing the current user, and the
+portfolio they are currently working with.
+
+website.view
+------------
+
+Not all the classes are shown here; however, all of them follow the same
+structure as the ones shown. A website view class has:
+
+1. Some HTML in the form of Scala inline XML.
+
+2. Some calls into the model to retrieve data.
+
+3. Places in the HTML where data is inserted.
+
+4. Some callbacks for user-input events (submitting a form).
+
+5. Some calls into the model to perform the requested action.
+
+The view is intended to be as thin a layer as possible on top of the real
+logic in the model.
+
+Android view
+------------
+
+The Android is another View in the MVC architecture; the classes shown:
+
+2. Make calls into the model (via servlets) to retrieve data.
+
+1. Take user input (via the Android UI).
+
+3. Make calls into the model to perform the user's actions.
+
+The only real difference between the design of the android and website
+frontends is that the Android UI has no choice but to run on a separate
+machine, and so it must retrieve data and perform actions over HTTP.
+

0 comments on commit 68b4287

Please sign in to comment.