CS494, Homework 2
Stock Portfolio Monitor using the Observer Design Pattern

Due date: at class., Tuesday, April 8th.

This assignment is pledged. You may work in teams of three or smaller.

1. Overview

You are to design the first version of an application that lets a user keep track of the values of stocks and portfolios of stocks that the user owns. Your system interacts with a Ticker, which is a source of stock price data that is external to your system. (Your system will have a proxy object from which objects you design will retrieve stock price data. You'll be given its specifications.)

The user will be able to look at several possible views that the system can display:

Portfolio View:
This will display the name of the portfolio, and a list of stock holdings. Each holding displays the stock's ticker symbol, the quantity owned, the original purchase price, the current price, the total value of the holding in that stock, and finally the gain or loss since purchase. The portfolio name is given by the user when the portfolio is created. An operation for adding a stock-purchase to the portfolio will exist in which the user supplies the ticker symbol, the quantity, and the purchase price. The current price at any given moment is obtained from the Ticker, and the other values can be thus calculated.

Watch List View:
The system supports one Watch List, which is simply a list of stocks that the user is interested in following (but may not own). The Watch List View displays these stocks by showing their ticker symbol and current price (from the Ticker).

Stock View:
The system allows the user to display a detailed view of a single stock. This view displays the stock's name and ticker symbol, the current price, and the high and low price. (To keep things simple for now, these last two will be the highest and lowest price ever seen.)

2. What You'll Do (General Statement)

The goal of the assignment is to use UML class diagrams and sequence diagrams to create a design for a fairly simple first iteration of such a system. Another goal is to learn the Observer pattern and see it in use.

It is not the goal of this assignment to learn the details of a GUI library like Java's Swing or C++'s MFC. Thus your design may not be complete enough to create a running application, but you should be able to add a user-interface layer on top of the classes we create here to actually make this run. (This might be a later Java assignment.)

Thus for this homework you'll create UML diagrams and answer some questions that will help you create good diagrams.

3. Requirements Information:

A analysis level class diagram might look like this:

Some use cases:

1. User adds stock to portfolio.
   The user adds a new stock holding to his portfolio by interacting with the Portfolio View. The user provides the ticker symbol, the number of shares, and the purchase price. The View initiates actions that leads a new stock entry being displayed in the view.
2. User adds stock to WatchList.
   The user provides the ticker symbol to the WatchList view's add feature, and the WatchList now includes that stock. The view updates and now displays that stock's symbol and current price along with the others in the WatchList.
3. User views stock info.
   The user enters a ticker symbol, and the Stock View for that stock is displayed. (Assume the user can remove this view by closing the window containing the Stock View or something.)
4. Ticker has updated stock prices.
   At some kind of interval the Ticker has new stock prices that may affect some Views. All affected views update themselves and re-display the new stock price info.
5. There are also use cases for creating new portfolios and watch lists, and possibly others.

Preliminary Design:

Assume there is a main window or GUI menu system from which a user can:

1. Create a new Portfolio and its view, or reopen a view for a Portfolio that was created before and has been closed.
2. Create a Stock View for a given stock;
3. Create a Watch List and its view, or reopen the view for the WatchList that was created before and has been closed.

This object and these operations are not shown in the diagram that follows. What this does show is a partial, incomplete start to the design-level class diagram.

In this design, a StockManager object (a singleton) keeps a list (or map or whatever container class you wish) of all the Stocks that are currently present in any view the program has. The StockManager object periodically sends a query to the Ticker to retrieve the current value for each Stock it knows about.

Problem domain (PD) objects (e.g. WatchList) are linked one-to-one with a GUI object (e.g. WatchListView). For this exercise, this is mostly a way to decouple GUI-specific traits from the design exercise. But the system could really be built this way. Assume that the View object knows its PD partner and invokes operations in the PD object. For example, there may be an AddNewHolding() operation in Portfolio object that gets invoked by the PortfolioView object. The GUI and implementation details are in the View object, not in the PD object. If you need to draw a sequence diagram, the left-hand side would usually start with a view object invoking an operation in the PD object. Note: We will assume that all views are obervers of their partner PD objects; thus, each View class has an update() operation that may be called by the PD object when it believes its view needs updating.

4. What to Do (or, What To Turn In)

You will turn in a more detailed design-level class diagram. In addition, answer the following questions. Some involve creating other UML diagrams. Answering these questions may also help you create your class diagram too. Your class diagram should have the classes, operations and attributes to support your answers below.

1. What object has this responsibility? When a user interacts with a PortfolioView to add a stock to the Portfolio, a new Stock object may need creating. In a few sentences, give an overview of how you'd handle this.
2. After answering the previous question, draw a UML sequence diagram for the scenario where a user requests a stock to be added to the Portfolio, and the stock is not one of the ones managed in the system.
3. Do you think Stock objects should be Observers of the Stock Manager? Why or why not?
4. Do you think objects in the system that care about updates to Stock prices should observer Stock or the StockManager? Discuss your choice.
5. Should Portfolio or StockHolding be an observer waiting for stock price changes? One of these probably should be. Explain your choice.
6. Draw a UML sequence diagram for a scenario that implements the following situation. The price of a stock (e.g. IBM) changes. This stock is being shown in one Portfolio view (e.g.object PV1) and also in a Stock view (e.g. object IBMview). Both of these views are updated to reflect the change in stock price.
7. Give a list documenting all the Observer/Observed class pairs in your system. Also, describe your choice on how to implement the Observer design pattern. (See discussion below.) If your solution uses inheritance, list what classes inherit from which superclasses and do not show this inheritance in the class diagram. (You'll thank me since this will make your diagrams much easier to draw.) If your solution uses interfaces, list what classes implement which interfaces. You do not have to put the interface box in your class diagram. But each subclass or class that implements an interface must show all method signatures that come from its superclass or interface. (I am trying to make things easier here, but if you want to do "the right thing" and show interfaces and superclasses in your diagram, go ahead.)

In your design-level class diagram, show as many operations and attributes as you think are required. You must show all of these that are needed to understand your UML sequence diagrams drawn for Questions 1 and 6 above. Also, show the complete set of associations that you believe are necessary. You do not have to make any hard decisions about implementation of associations or container classes for this exercise; we'll just know they'll be there eventually because of the aggregation and association in the diagram.

Where you need to use the Observer design pattern in your design, here are some things to do in your class diagram. First, let's not have a Multicaster object in the system. Instead, we'll assume each Observable contains the operations needed. Second, you must choose between the Java-style implementation of this design pattern, or the version proposed by Coad (and documented in the lecture slides). Note that your choice will affect what you show in Question 6 above.

See the note in Question 7 above about not showing inheritance or interfaces in your class. I hope this makes things easier for you. If not, let me know and we can negotiate!