Why port

Case Study Porting the Trading Game from Custom Application to a .LRN Package

Background - Trading Game

Many years ago, members in the technology department at MITs Sloan School of Business created a custom application, the Trading Game, to support finance classes. This game simulated trading in the stock and bond markets to support concepts taught in the classes. Teams of students would enter trades. The teaching assistant would control the trading play and execute each round. The system would maintain each teams portfolio.

The system was built as a small exploratory project using Oracle for the database and Cold Fusion for the front end.

Background - .LRN

.LRN is open source software supporting learning and research communities. .LRN capabilities today include course management, online communities, learning management, and content management applications. In addition, .LRN provides a powerful framework and tools for quickly innovating on these applications and building customized solutions. .LRN is currently used at Sloan School of Business to manage their courses.

Why port?

The Trading Game was a success and several classes use it each year. For the fall semester, the system was ported from the proprietary system to .LRN for the following reasons:

- The Trading Game is one of the few legacy systems using Cold Fusion.

- Only 1 person in the department had coding knowledge of the trading game, and that person had moved onto a different role.

- .LRN is the central platform for Sloan. Therefore, it carefully watched, backed up and maintained. The Trading Game, as a one-off application in its technology, did not get this attention.

- Students had a class area in .LRN for each one of their classes. The Trade Game required users to visit and log into separate system. Integrating these systems would be a hassle.

- The Trading Game required manual setup of users and teams.

- The Trading Game required either a separate instance or the database to be wiped of data each time a class wanted to use it.

- Different classes wanted to use the Trading Game in different ways, but the system didnt have the capability for configuration without changing code.

Steps

1. Datamodel

Since both systems use Oracle, porting the data model was fairly straightforward. Some of the primary and foreign keys where modified to reference standard .LRN tables, such as users and groups.

2. Application Pages

As cold fusion scripts were ported, we used .LRNs templating system to separate the logic from the presentation, therefore simplifying the code.

Like the datamodel, the SQL query logic remained very similar, with a few changes to use the .LRN user and groups system. Some of the pl/sql procedures were simplified to queries of the format insert into foo (var1,var2) select var1, var2 from bar, but this improvement distinct from the port.

In the code fusion script below, you will notice the following:

a) The database queries and the HTML are in the same file. This makes it hard for non-programmers to edit the page layout and can be confusing.

b) There is check for Session.PersonID at the top of the script. This is user management and has to be included on every separate script.

COLD FUSION SECURITIES LISTING

</cfif>

SELECT * FROM TTRADE_JCM.SECURITY

ORDER BY TYPE,LIST_ORDER

</cfquery>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

<html>

<title>

Edit Securities

</title>

</head>

<h2 class="header">Edit a Security</h2>

<TR>

<th> <font color="#ffffff">Symbol</font>

</th>

</th>

</th>

<th> <font color="#ffffff">Spread</font>

</th>

<th> <font color="#ffffff">Coupon</font>

</th>

<th> <font color="#ffffff">Maturity</font>

</th>

<th> <font color="#ffffff">Order displayed</font>

</th>

</TR>

<TD>

<a href="editsecurityform.cfm?SECID=#SECID#&type=#TYPE#">#SECID#</a>

</TD>

<td>

#NAME#

</td>

<TD>

#TYPE#

</TD>

<TD>

#SPREAD#

</TD>

#COUPON#

</td></cfif>

#DateFormat(MATURITY,'dd/mmm/yyyy')#

</td></cfif>

<td>

#LIST_ORDER#

</td>

</TR>

</cfoutput>

<TR>

</TD>

</TR>

</TABLE>

</body>

</html>

The above cold fusion file was ported to the .LRN logic and presentation scripts below.

In the .LRN logic script below, you will notice

a) There is no HTML. This script simply gets the correct data from the database

b) The ad_page_contract procedure serves the following purposes:

- Records information such as the script author. This information is used for automated documentation

- Adds a CVS (version control) stamp so you can tell exactly when the script was last mofiedi and by whom.

- Defines any variables that should be present in the URL and their type. In this case, this script will not use any URL variables.

c) There is a variable defined called package_id. This is part of the package management system, which allows many instances of the package to be running concurrently on the same system, each with isolated data and user management. This capability is not present in the cold fusion Trading Game.

d) There is no check for the logged in user. The .LRN framework automatically checks the user, their role, and their permission. Only administrators can get into the administration pages. Only students in the proper class can get into the trading game for that class.

.LRN SECURITIES LISTINGS - LOGIC

ad_page_contract {

Lists all the securities.

@author teadams@alum.mit.edu

@date 2004-09-15

@cvs-id $Id: securities.tcl,v 1.1 2004/09/27 13:42:28 teadams Exp $

} {

}

set package_id [ad_conn package_id]

set title "Edit Securities - package id $package_id"

db_multirow securities securities {

select ttrade_security.*, to_char(maturity, 'MM/DD/YYYY') as maturity_date, ttrade_price.close from ttrade_se curity, ttrade_price where ttrade_security.security_id = ttrade_price.security_id(+) and ttrade_price.round =0 and ttrade_security.package_id = :package_id order by list_order

}

ad_return_template

The .LRN presentation script below shows the presentation of this page. This page does not have any database queries.

.LRN SECURITIES - PRESENTATION

<a href=index>Trading Game Administration</a>

<h2 class="header">Securities</h2>

<p>

<TR>

<th><font color="#ffffff">Symbol</font></th>

<th><font color="#ffffff">Starting Price</font></th>

<th><font color="#ffffff">Spread</font></th>

<th><font color="#ffffff">Coupon</font></th>

<th><font color="#ffffff">Maturity</font></th>

<th><font color="#ffffff">Order displayed</font></th>

</TR>

</if>

<else>

</else>

<td>  <a href=security-edit?security_id=@securities.security_id@>@securities.secid@</a></td>

<td>  @securities.name@</td>

<td>  @securities.type@</td>

<td>  @securities.close@</td>

<td>  @securities.spread@</td>

<td>  @securities.coupon@  </td>

<td>  @securities.maturity_date@  </td>

<td>  @securities.list_order@</td>

</tr>

</multiple>

</table>

<p>

<a href=security-edit>Add a security</a>

The port also made use of .LRNs form management system, a framework that provides form validation and management and adding and editing the basic fields. This simplified the code by reducing the number of files and consolidated the logic of form generation and submission into one script. It also provided validation of the user input. That is, if a user typed in data that was out of range, the system would ask the user change it before the data was processed. This functionality wasnt throughout the cold fusion application because it required extra code for every form.

3. Libraries

A few of the commonly-used pieces of code were abstracted into their own procedures for code simplification, stability, and reuse. The library was not present in the cold fusion application.

Time Frame

The system took about a week to do the initial port, and then a week to test, work with the TA and add a few more features.

Benefits Summary

Name	Summary
Consistency	The trading game is now running off the standard Sloan platform, reducing maintenance costs. The user interface is standard.
One user login	Users only have to log in to .LRN and not two separate systems. The separate application does not have to be filled with users by hand.
Multiple instances	The trading game can run for many classes without resetting the data or setting up a whole new copy of the application.
Documentation	With .LRNs automated documentation, they system is not documented.
Framework for upgrading	.LRNs package management framework will allow upgrades via the user administration pages.
Unit test framework	Unit test for the application can be added and run through .LRNs unit test framework.
User role management	The trading game now has clearly defined users and administrators. The standard class administration pages allow the professor or teaching assistant to control who these are.
Team Management	The cold fusion trading game required teams to be predetermined and entered by hand. The .LRN system uses built-in community management features. The professor or teaching assistant can manage the teams via the web.
User validation	Forms consistently check user input and give standard errors message to the user via .LRN form management.
Large pool of developers	There are hundreds of developers trained on the base technology.
Configuration	Each instance of the trading game can have separate configuration options. These options are controlled via a web page.
Internationalization	The interface can be translated and run in multiple languages using .LRNs internationalization framework.

Case Study  Porting the Trading Game from Custom Application to a .LRN Package

Background - Trading Game

Background - .LRN

Why port?

Steps

Time Frame

Benefits Summary

Case Study Porting the Trading Game from Custom Application to a .LRN Package