VaultnGus' AOOD Project 1998
Project
History
A
work in progress...
This project is a reverse engineering of a project originally compelted for the Object-Oriented Design class from 1997 (taught by Mira Mezini). The original code was written in Java, but the main bulk of the work was spent writing code for traversing amongst various objects. It was also a great amount of trouble any time we wanted to modify the class dictionary even for minor changes. It would seem then that Demeter/Java could help considerably in development of proper class dictionaries and code.
The project itself was intended to be a prototype for an online stock broker. The main objects included a Broker, which had Accounts for Players and a StockMarket that contained different types of Investments
Other features included:
Future developments would include actually having real, dynamically updated stock market data (ours was only static) possibly even downloaded from a Market information service. Also we only included one type of Investment - generic stocks.
For those who are interested, the code for the original OOD project can be found in here
One interesting comparison between the original class dictionary and the one for this project - since it is so much easier to design class dictionaries using Demeter/Java it is also much easier to tinker around with the class dictionaries to find the optimal solutions to problems. In the original we had varying class structures during development but due to the large time required to change each class and method by hand for every minor modification, major modifications to the class dictionary were near impossible. For instance Usernames and Passwords are loaded into Vectors here before logging on to avoid writing all of the traversal functions.
For the Demeter/Java project the class dictionary has gone thorough many modifications which have had nary an effect on the coding procedure. It has allowed me to make a much more robust and efficient class structure.
This project is to be done in several phases, each phase adding a new component to the overall program. The goal is to first work on parsing in all the needed information correctly - the List of Investments in the Market, the List of Accounts and the Lsit of Operations. Next is to implement the logon procedure. Third is to dynamically instantiate new Accounts and store them in the List of Accounts and have them saved to a file after exiting the program. This goes for the Market as well. Finally all of the individual operations must be implemented one at a time starting first with the reports and then the Buy and Sell commands.
Phase 001:
Started out with a basic Broker object containing a list of Accounts, which in turn had a UserName, a Password, an amount of Cash and an optional Portfolio. The .beh file contains a DisplayVisitor that traverses all objects to test the validity of our class dictionary and that the input parses correctly.
Broker.cd Broker.beh Broker.input
Phase 002:
Added Market and Investment classes as well as Operations. 1st attempt at inputting UserName and Password unsuccessful...
Broker.cd Broker.beh Broker.input
Phase 003:
Market now parses correctly.
Broker.cd Broker.beh Broker.input
Phase 004:
BrokerSim is now the controlling object containing a MarketList (List of Investment objects), an AccountList (List of Account objects) and an OperationList (List of Operation objects), all of which parse in correctly from Broker.input.
Note: A lot of the Operation class structure borrows heavily from the LibrarySystem example from the Demeter/Java LabGuide.
Broker.cd Broker.beh Broker.input
Phase 005:
Added logging on to the system. Function checkUsername uses a CheckUsernameVisitor with a traversal to all Accounts in teh AccountList to search for the username. If that Username is found, then that Account is returned. The Password is then verified.
Broker.cd Broker.beh Broker.input
Phase 006:
After logging in all possible operations are listed. This is done with the show_Operations() function which uses a DisplayOpVisitor that traverses all Operations in the BrokerSim's OperationList and display's them
Broker.cd Broker.beh Broker.input
Phase 007:
Two Additions - First if the user inputs a Username that is not in the original AccountList, then there is the option to create a new Account. A Password is then created for this Account and it is stoked with $10000 Cash and an empty Portfolio (to contain Investments).
Second the user is now prompted to input an operation and the function find_Operation traverses through the List of possible Operations using a FindOpVisitor containing the Operation's OpCode. If the OpCode is matched then that Operation object is returned, otherwise an Invalid object is returned.
Broker.cd Broker.beh Broker.input
Phase 008:
Broker.input now split into three separate files - Broker.mar (containing the MarketList data), Broker.acc (containing theAccountList data) and Broker.op (containing the OperationList data)
Since the simulation runs on an infinite loop logging in users, a way out was needed. Typing "exit" at the login prompt ends the simulation but all data changed or added during the course of the simulation is lost. Now on exiting the simulation write_file() is called for the AccountList and the MarketList. This function uses a FileVisitor to save all the relevent data using the grammar required by the parser.
An interesting note - since the FileVisitor requires a PrintWriter object to save data during the traversal, the parser automatically generates code that calls for a PrintWriter constructor containing no arguments. However there is no such constructor available in the API so errors were generated. Finally a workaround was discovered . By using "noparse" before the Visitor classes in the class dictionary, this tells the parser generator not to create code for parsing these classes, thereby solving the problem.
Phase 009:
Portfolio parsing and saving now implemented. New accounts now saved upon exiting.
Commands Quit, MarketReport and AccountReport implemented. Quit was a pain - I had to add a get_quit_opcode function like in the LibrarySystem to traverse through the list of operations to get the OpCode corresponding to the Quit Operation parsed in.
Invalid commands now handled correctly, although in a not very structure shy way. Upon parsing the OperationList on execution, Invalid MUST be the last Operation parsed in...
Broker.beh is starting to get big - maybe I should split it up into segments...
Phase 010
The Buy command has now been implemented. Plus the .beh file has been split into two parts. All functions dealing with operations performed by the Client are now in Operation.beh
Broker.cd Broker.beh Operation.beh
Phase 011
The Sell command has now been implemented (very similar in implementation to the Buy command so coding was very quick...) with one small problem. Since each account uses a List to store Investments in a Portfolio, when the client sells off all shares of an Investment, there is no command in the List interface to remove an element from the list. The Investment will remain in the Portfolio even though the client does not own any shares.
Possible solution : Instantiate a new Portfolio, copy all still existent Investments to the new Portfolio, and reset the Account Portfolio to point o this new one...
Broker.cd Broker.beh Operation.beh
Phase 012
Couldn't find any other viable solution to the removeElement problem from Phase 011, so the above solution was used. An interesting problem came to light. If a new Portfolio() is instantiated and then an element is added, a nullPointerException is thrown. After several hair tugging hours staring at the code I finally realized that a new List object must be parsed in on instantiation using the proper grammar
This properly instantiates the Portfolio object using List structure.
Broker.cd Broker.beh Operation.beh
Still to come:
Clean up the code a tad
If time allows create a graphic interface for this simulation