Laboratory in Software Engineering
Fall 2002
Problem Set 5: Foliotracker Part 1
Due: Tuesday, October 22, 2002 at 2: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 stock portfolios. The first problem set is to be completed and handed in for grading before you start the second.

Foliotracker can be used to manage and maintain multiple stock portfolios. A portfolio is a collection of stock holdings, and can 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. It does not support trading of stocks; we shall assume that the user enters information about trades that have been executed.

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. Decoupling the system into two parts separated by a well-defined API allows for different types of front-end clients to access your system and use its functionality. For the first exercise, 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 QuoteServermodule 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 (and it should automatically be in your classpath).

Problem Set 5

Your first task is to determine what functionality Foliotracker should support. At the minimum, it should allow the user to track multiple portfolios, to reference stocks by ticker symbols, and to:

Create a portfolio identified by a unique name
For each stock in the portfolio, increase or decrease the number of shares to represent buying and selling
Create, add and remove portfolios
Get the total value of a portfolio
Get the price per share and the total value of your holdings of a particular stock
Store data persistently on disk

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 (the 'basis') to compute gains and losses
Keeping track of high and low prices within a specified period
Notifying the user when a stock's value moves outside certain user-defined bounds

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 issues 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 think carefully about whether the API will properly support the functionality your GUI will require.

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 portfolio valuations can be trusted.

You should hand in the following artifacts:

(a) Overview (10 pts) A terse and precise description of what the application's purpose is, and what functions and scenarios it supports.

(b) Specifications (20 pts) Specifications of the API itself and any classes or interfaces it exposes to a client of the API. These specifications should be sufficient for an implementor to develop a front-end, such as a GUI, without looking at the implementation of the API.

(b) Problem Object Model (15 pts) 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) A module dependency diagram of the entire backend. To explain any special techniques, design patterns, 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. Classes should be documented with specifications, rep invariants and abstraction functions. You should use good engineering judgment in determining what level of detail and precision is appropriate.

(e) Testing (20 pts) A terse but convincing overview of your testing strategy, what kind of testing you performed, and what test cases you used. Include test code and outputs. Your test cases should be implemented with JUnit so repeated, automatic testing is possible.

Errata

None so far.

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 .