DUE: Week 6
We recommend that you read the entire problem set before you begin work.
Introduction
In the next two exercises, you'll build Foliotracker, an application program for tracking the value of a stock portfolio. The first exercise is to be completed and handed in for grading before you start the second.
In the first of the two exercises, you'll decide on the basic functionality of your program, design a graphical user interface (GUI) for it, and specify an application programmer's interface (API) through which the GUI will access the components of the code that obtain stock quotes, maintain a database of values, and so on. The benefit of decoupling this application into two parts (a front-end GUI and the back-end implementation) by creating a well-defined API is to allow for different types of front-end clients to access your system and use its functionality. You won't actually write any of the code that implements the API; instead you'll write a stub: a piece of code that can be used to test a client of the API, but which provides only very limited functionality. You may, for example, have the stub compute nothing and just look up values in a fixed table. This stub will allow you to assemble and test the GUI, and make sure that the functionality seems reasonable. In the second exercise, you'll implement the functionality of the API itself. You should not need to make any changes to the GUI or to the API.
The focus of the first exercise is design of the API and implementing the GUI. You'll need to learn how to use Swing. The online Java™ Tutorial trail, which is at The Java Tutorial , includes a section on Swing and the Java Foundation Classes; you'll find it at Creating a GUI with JFC/Swing.
The focus of the second exercise is design of the backend and its implementation. You shouldn't need to learn anything new, but will have an opportunity to refine your skills in designing with abstract data types, object models, etc. You don't need to implement the code for obtaining the stock quotes; we provide a class for you that has a simple method that takes a ticker symbol as a string and returns a price.
Exercise 5
Foliotracker enables the user to track the contents and value of multiple stock portfolios. A Foliotracker can be used to manage and maintain multiple stock portfolios where a portfolio is a collection of stock holdings. A portfolio could also contain meta-data about a person's transaction history, statistics, etc. Foliotracker discovers current stock values by querying a stock quote server across the World Wide Web. Your first task is to determine what functionality Foliotracker should support. At the minimum, it should be possible to:
- create multiple portfolios;
- see the positions (stock name, number of shares held, price per share, and value of the holding) in a portfolio;
- increase and decrease the number of shares of a stock;
- see the total value of a portfolio.
We have provided some screenshots of possible functionality.
Here are some possible features you might consider including in your design:
- saving portfolio information to disk;
- indicating whether price is going up or down, perhaps by coloring the text or using little coloured arrows;
- allowing the user to enter the price at which a stock was bought, to estimate gains and losses;
- keeping track of highs and lows;
- setting watches causing an action to occur when the stock goes up or down some amount;
- sorting positions by value, ticker symbol, etc.
You should choose a set of features that you plan to implement. We recommend that you order them according to difficulty and desirability, and think carefully about which you will jettison if things turn out harder than you thought.
More fundamentally, you will need to consider basic questions such as
- how portfolios will be identified (with names provided by the user?);
- when stock prices will be updated (periodically? by explicit command?);
- how to handle exceptional cases, such as ticker symbols that don't match stocks, or how to behave when the web site is not responding;
- whether multiple portfolios can be shown at once;
- whether multiple simultaneous views of the same portfolio are allowed.
These issues need to be addressed at the start; they'll be much harder to deal with if you postpone them.
In the design of the API, you will also need to resolve some basic issues. Two important ones are:
- whether the API will be passive, in the sense that the application simply treats it as a source of information, or whether it will be active, by having functionality to make periodic callbacks, for example;
- what types will be exposed at the interface.
Your API specification will be a complete description of the functionality of the program, ignoring only the question of how the program and user communicate via the GUI. You should use a Java™ Syllabus Calendar Lecture Notes Assignments Exams Required Readings Related Resources Labs Sections/Recitations Tools Projects interface for the API. Your GUI should be easy to use and attractive, and straightforward to build. You'll probably want to play around with Swing a bit to get a feel for how things are done and what's possible before you design it.
You should hand in the following artifacts:
(a) Overview [One page or less] A terse and precise description of what the application's purpose is; what kinds of functionality it supports; what your GUI looks like and how it is to be used. Think of this section as a compressed user manual: the kind of summary of an application often found on marketing flyers.
(b) Problem Object Model [One page] An object model that summarizes the abstract state of the application from the user's point of view. The objects here will be from the problem domain (such as stocks and prices), and not concrete objects from the code. Try and keep this as abstract as possible, avoiding any implementation details. To check that your model is complete, ask yourself whether the state contains sufficient information to produce the behaviors you have in mind. State informally any constraints that arise from the properties of the problem itself, but which cannot be shown graphically.
(c) Specification of API [Two pages or less] An overview of the API specifying the general high-level interaction with your system. Also, a detailed specification describing each method with the standard requires/ensures/modifies form.
(d) Screenshots of GUI A set of screenshots of your GUI showing how it is organized and what functions it offers.
(e) Code Your code will include the code of the GUI, the Java interface for the API, a stub class that implements the API interface, and any testing code you wrote. You should complete your code to the point that you can try out all the basic user interface interactions, display plausible looking results, and exercise the connection between the GUI and the API. The classes in your GUI do not need extensive specification, but they should be tastefully commented, and any obscure public methods should be carefully specified.
Errata
Q & A
This section will list clarifications and answers to common questions about the exercises. We'll try to keep it as up-to-date as possible, so this should be the first place to look (after carefully rereading the handout) when you have a problem.