Laboratory in Software Engineering
Spring 2002
Problem Set 5: Foliotracker Part 1
Due: Tuesday, March 19, 2002 at 4:00pm

Handout P5

Introduction
Problem Set 5
Errata
Q & A

We recommend that you read the entire problem set before you begin work.

Introduction

In the next two problem sets, you'll build Foliotracker, an application that enables a 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. The first problem set is to be completed and handed in for grading before you start the second.

In the first of the two problem sets, you'll decide on the basic functionality of your program, and specify an application programmer's interface (API) that allows a graphical user interface (GUI) to 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. For the first excercise, you won't actually write any of the code for the GUI; you should write a simple client application that tests your back-end API.

In the second problem set, you'll implement the functionality of the GUI itself. You should not need to make any changes to the API or its backend implementation.

The focus of the first problem set is the design and implementation of the back-end API. You 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.

The focus of the second problem set is the design and implementation of the front-end GUI. For this, you'll need to learn how to use Swing. As soon as you finish the first problem set, you may want to start early and go through the online Java Tutorial trail at http://java.sun.com/docs/books/tutorial/ , which includes a section on Swing and the Java Foundation Classes: you'll find it at http://java.sun.com/docs/books/tutorial/uiswing/ .

We have provided a QuoteServer module for your convenience. If you are curious, you can look at the source code: QuoteServer, WebsiteDataException, NoSuchTickerException. But you should be able to make use of it using the specification alone. You should not need to take any additional steps to use this module (it should automatically be in your classpath).

Problem Set 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 a portfolio identified by a unique name
A portfolio contains 0 or more stock positions
Each stock position contains at least ticker symbol and number of shares
For each position, the user must be able to increase or decrease the number of shares through buying or selling
Create multiple portfolios
Add and remove portfolios
Get the total value of a portfolio
Get the price per share and the total value of a particular position
Save information to disk so that you can retrieve the portifolios later

Here are some optional features you might consider including in your design:

Allowing the user to enter the price at which a stock was bought, to estimate gains and losses
Keeping track of high and low prices within a specified period

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

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

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 interface for the API.

Your task in this problem set is to design the API, the internal structure of your Foliotracker backend, and test the program. This program is difficult to test because the changing stock prices make it hard to do repeatable tests. So you will need to devise a reasonable testing strategy that gives you some confidence that the application works reliably, and that the stock prices and position and portfolio valuations can be trusted.

You should hand in the following artifacts:

(a) Overview/Specifications (30 pts)A terse and precise description of what the application's purpose is; what kinds of functionality it supports. In the next problem set, you have to implement a GUI so think about how your GUI might use your back-end. Also include the detailed specifications of classes and methods. Ideally, this section should completely specify the functionalities so that any user can implement a GUI front-end application just by reading your specifications.

(b) Problem Object Model (15 pts)[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) Module Dependency Diagram (15 pts)[One page] A module dependency diagram of the entire application. To explain any special techniques or abstractions you devised for decoupling or other purposes, add a short note.

(d) Code (20 pts) The code for the backend implementation of your API.

(e) Testing (20 pts)A terse but convincing overview your testing strategy, what kind of testing you performed, and what test cases you used. Include test code and outputs. All test cases must use Junit.

Errata

Sunday, March 17, 2002

There was a small bug in the provided QuoteServer (incorrect exception thrown by getNameFromTicker for unknown ticker symbols). It has been corrected. Most of you need not do anything, since ps5-lib.jar has been updated. But if you copied the QuoteServer source files to your account, please get the updated file.

Q & A

This section will list clarifications and answers to common questions about the problem sets. 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.

Back to the Problem Sets .
For problems or questions regarding this page, contact: 6.170-webmaster@mit.edu .