Skip to main content.

Overall Project Organization

We use the first 9 weeks of the term for design and construction of projects. Week 10 is reserved for final presentations. A more complete schedule is available.

We will begin with all teams working on a one or two common projects that will be due at the beginning of Week 5. That's a very tight schedule, and I will encourage you to scope it appropriately and approach it incrementally, to minimize the risk of not having something good to turn in at the deadline. Project scoping and risk control are core Software Engineering skills

You will have the option of switching to another project of your own choosing (with my approval) in week 5, but I encourage you to at least strongly consider making a second iteration of the same project. Familiarity from the first iteration usually allows the team to work more effectively and focus on all parts of the process.

2012 Project Choices

Stock Market Simulator and Fantasy League

Background

The availability of real-time data from stock exchanges around the world make it possible to simulate stock market transactions without investing real money. By providing a web-based service that allows users to make virtual stock trades, it is possible to simulate accurately the results of real stock market trades over time in a virtual brokerage account. Such features can be used for a variety of purposes including learning how stock markets work, evaluating investment strategies, or supporting competitive investment games.

The following defines some initial requirements for a stock market simulator. Teams will be expected to:

  1. Refine these requirements to define, in detail, the specific behavior of the system they plan to build (both functionality and qualitative behavior).
  2. Extend the requirements to provide some novel features.

Basic Requirements

The purpose of this project is to build a website that allows players to make virtual investments in real-world stocks. The stock trading aspect of the simulation should provide essentially the same features as an on-line broker (if, perhaps, more limited options). Each player will start with a virtual account and set of funds (play money). Players use their funds to virtually buy stocks. The system tracks stock prices on real-world exchanges and periodically updates the value of each player’s portfolio.

A player portfolio consists of a set of positions, the individual stocks owned by the player. The system should provide typical data on each stock position, including: company name, ticker symbol, the number of shares owned by this player, and date and price when purchased. Player should also be able to specify stocks to be tracked without owning any of those stocks.

The system should support typical kinds of buy and sell orders (e.g., limit orders, stop-loss orders, etc.) and adjust player’s portfolios in keeping with the results of their orders and stock price movements. The system should also (as brokers do) set a commission on trades to curtail unrealistic trading frequencies.

Investment Guru Game

Using the features described above, the system should support games in which players to compete against one another for investment results (similar to baseball fantasy leagues). For example, the players might all start with $10,000 in play money and have a fixed period in which to make trades. At the end of that time, the player with the best results (highest value portfolio) is the winner.

Dartboard

Experience shows that picking stocks completely at random often produces results as good or better than portfolios picked by experts. The original model for this was simply throwing a set of darts at the stock listings in the newspaper and investing in the stocks of whichever companies were hit. The system should support a portfolio using such a strategy and publish results for other players to compare to.

Creative Opportunities

It is possible to create a wide range of variations on the basic features described above. Teams selecting this project should present creative ideas and reach agreement with the instructor on which variations should be pursued. Examples of the kinds of features that might be added or changed include:

Resources

This project is based on one developed by Prof Ivan Marsic at Rutgers University and described in his on-line text Software Engineering (http://www.ece.rutgers.edu/~marsic/books/SE/). Portions of the text and website are referenced here. While these materials may be used as guidance, students must work to define their own version of this application.

Relevant description of the problem domain (i.e., stock trading) in section 1.3.2. An exerpt of the text containing that material may be downloaded in PDF here. A number of pointers to examples and other resources may be found on the Stock Market Investment Fantasy League page.

Teams will share information about specific technologies or APIs. While learning new technologies is often a benefit of this course, its focus is on project control and other aspects of Software Engineering.

 

 

Learning Assistant for Concurrent Programming

This project will provide students the opportunity to learn important aspects of the theory and methodology of concurrent programming. It is particularly recommended for graduate students or advanced undergraduates.

Background

The growing use of multi-core processors suggests that concurrent programming is likely to become the dominant paradigm. Currently, most student learn programming using a sequential model; i.e., using a single thread of control where statements are executed in sequence. This follows the model of execution on a single processor. In contrast, multi-core systems support two or more threads of control in hardware. Where programs can exploit more than one processor through multiple threads of control, there is the potential for huge improvements in execution speeds as well as the ability to run more sophisticated applications on conventional hardware (e.g., large simulations).

Concurrent programming denotes the discipline of writing programs that explicitly exploit multiple threads of control. Some modern programming languages, including Java, provide the constructs and libraries (e.g., threads) supporting concurrent programming. However, programmers must learn to use concurrent programming mechanisms correctly to write effective programs. While concurrent programming offers the opportunity to exploit multiple CPUs, it also introduces opportunities for error that do not arise in sequential programming. Problems such as deadlock, race conditions, or resource contention can arise where there are multiple threads of control. Thus students must learn additional techniques (e.g. synchornization) to write correct programs.

A key difficulty in writing and verifying concurrent programs is their inherent non-determinism. Different threads may execute at different speeds with the result that the same concurrent program may give different results from one execution to the next. This makes such programs difficult to test or debug.

Basic Requirements

An approach that addresses this problem is one in which developers model the program behavior first, and check the model for undesired behaviors like race conditions. By learning to use such models, students can learn the thechniques of concurrent programing and detect concurrency errors before creating code.

This project will focus on methods for teaching students to develop and test concurrent program models written in terms of a form of finite state automata known as a Labeled Transition System (LTS). Teams will be asked to develop a tool supporting the teaching of parallel programming techniques using LTS and an automated LTS Analyzer (LTSA) () developed by Jeff Magee and Jeff Kramer at the Imperial College, London.  Possible tools might integrate with the current LSTA implementation and examples or with the Eclipse plug-in currently in beta. 

Resources

See the resource page for the LTS Analyzer: http://www.doc.ic.ac.uk/ltsa/

The instructor will also provide material from the corresponding text (http://www.doc.ic.ac.uk/~jnm/book/)

Server Setup

Systems has requested that we try setting up our servers using existing accounts. This means that each team will need to choose one member to host the application in their "public.html" folder. This folder can be accessed over the web as "http://ix.cs.uoregon.edu/~[username]". In it, you can put web code, access MySQL, and so on.

For this to work properly in a team environment, you will want to set up a separate repository for code that is in progress. We can do this in the CIS 422 directory creating a group for each team. Then you would need have the owner copy the current code to the public.html directoy when needed. The best way to do this is, of course, by maintaining something like an SVN repository and downloading the code from the repository. That will allow full backups.

To Do: Each team must send me a list of tema member names with their CS User Names. We will use these to set up a group file space that you can share.