Hotspots: Admin Pages | Turn-in Site |
Current Links: Case Final Project Summer 2007
Spring 2003 M5: Monitor/Track stock activity from Web
Goal:
To learn basic networking in squeak. To add design complexity through networking and display of dynamic information. To use XML to save and restore application data.
Requirements:
Up till now, the information about stock prices was supplied by the user. This is not really realistic. Stock prices are volatile and change frequently throughout the day. We would like to capture the information at the end of each day and record the price for historical purposes. Many web sites provide stock information and even historical past performance. Your task for this milestone is to connect to the web server of your choice, and gather the necessary information.
Your application should provide the following capabilities:
- A graphic representation of historical performance.
- The ability to create a "watch" account. This account tracks the stock performance. If the stock price reaches a specific threshold selected by the user, a buy order for the previously determined amount is executed. The watch account becomes a part of the user's portfolio.
- The ability to update all stock prices in a portfolio based upon the current market prices. This update should only be done once per day or upon user request. Obviously stock prices change by the minute and we do not expect you to change all your portfolio prices every minute.
Two web sites which can give you extensive financial information are: http://finance.yahoo.com and http://table.finance.yahoo.com.
There are many others. Any is acceptable. Recognize you cannot get access to real-time non-delayed ticker information. We understand this. You are allowed to use the delayed information coming from free web sites.
Look at last semesters class for example code of how they connected to internet sites and obtained genealogy data.
The yahoo site will also provide precomputed graphs of performance. You are required to get the raw information and compute your own graphs to get full credit. Take a look at their site to get a feel for the types of graphs we are talking about.
Having a financial management system is not much use if the user has to reenter the data everytime they start the application up. A standard option is to make your classes persistent through some mechanism. Many options exist to accomplish this requirement- interface to relational databases, true object persistence through use of an object-oriented database system or even simple flat files. We will use the latter.
Your system must save its information in an XML file and then restore that information for a particular user. You may define your own XML schema to accomplish this. There are several smalltalk (squeak) libraries that allow you to easily parse and handle XML IO. For instance look at YAXO (available through SqueakMap).
Take a look at the Factory design pattern. Instead of object creation, think about what would a serialization factory look like. Think about what would happen to the application if we suddenly said that XML was out, we want a database instead. A good design would allow different serialization strategies to be "dropped in" if necessary.
You also need to worry about different users of the system and keeping their data separate. You need to ensure that if Bob saves his financial data, that only Bob can read it into your application. You do NOT need to ensure that no other application can read it. So there is no requirement for sophisticated encryption mechanisms of the file. It doesn't matter that anyone can bring the saved XML file into a text processor and read it. We just want you to design a way so that this financial application protects data across users while within the application.
Turn-in your code using the Spring 2003 Turnin Information with the code 'M5'. Turn in your design in-class.
Grading:
- 10% Good Scenarios: Accounts for all major functions in assignment, touches on every class.
- 10% Good CRC card analysis: Reasonable names, understandable and clearly defined responsibilities, good exploration of other class names
- 10% Good UML class diagram and class descriptions:
- Correct usage of notation in diagram (3%)
- Detailed and understandable class descriptions and names (7%) (Note: see http://coweb.cc.gatech.edu/cs2340/2522 for example on a general format for class descriptions)
- 10% Quality of the design
- 10% Well-documented and good style source code
- 50 % Working system:
- 10% All of the previous functionality from M4 works.
- 10% Application connects to the appropriate stock feed and displays historical performance.
- 5% Application correctly creates and handles watch accounts.
- 5% Stock prices are dynamically updated correctly.
- 5% SUnit tests well designed, error/exception handling
- 15% XML load/save works correctly
Note: If the TAs can't figure out how to do these things, they don't have to give you the points. The UI must be usable.
Links to this Page