Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
Spring 2003 M3: Design System
Goal:
Plan, Analyze and Design the Entire System
Team Forming:
For M1 and M2, we limited the scope of certain operations and made parts of the system somewhat artificial. For this milestone you will need to form a group of 3-4 students from within the class. This group will be responsible together for milestones 3 through 7. Your first task for M3 is to form your group, and create a team entry on the Swiki in the Spring 2003 Team Declaration Page. YOU CANNOT DO THIS PROJECT ALONE (or in a 2 person group)!! You may reuse any code that you wrote for M1 and M2 if you feel it is useful. The only restriction is that the M1/M2 code reused must have been written by one of the group members in your group.
Milestones to come:
Look across Milestones 4 through 7 which are your actual programming milestones. Along with the information in this milestone, you should then have enough information to design the entire system. Each milestone represents the LATEST time that functionality can be provided. At each milestone, we will only grade the functionality required to be present at that milestone. Basically you can view milestones as your latest acceptable delivery date.
Side note: You may, of course, create the desired functionality earlier if it will help your project succeed. For instance, load/save persistence of data is not required until M6, but you may decide to implement it somewhat earlier to make testing and development easier.
At each milestone we will quickly regression test your old code to ensure you have not broken anything. This is where SUnit can really help you. By having unit tests already coded, you just hit the run test button and verify that your test bar is still green. Whenever you find a "bug" in the system that was not caught by SUnit, you should add an SUnit test that would have caught it. That way, you can be sure that old bugs do not get reintroduced into your code base.
Note about CVS:
There is no requirement that your team has to use CVS or any other version control system. Configuration control systems do make code exchange and work easier. I do recommend you look at using CVS with the Squeak interface DVS as a good way to work with your team in controlling and exchanging code. Check the class lecture where the DVS tutorial link is provided.
Description:
The system description is much more open ended that M1 and M2. You may design your classes and messages however you desire to meet the basic requirements of the system. Just keep in mind good smalltalk style for message names and overall design principles. Your design is worth half your grade for the milestone, so don't hack and don't shortchange your analysis. If the requirements do not specifically state something, you are free to implement and design however you want. This is a design class, we want to see what you come up with!
Overall System Requirements:
The personal financial management program is an application designed to support an individual's investment and personal finance activities. Multiple users may be on the system, and personal data needs to be separated between users. Prior to use of the system an individual should be validated onto the system. Any standard validation mechanism (such as userid/password) may be used. (If you decide to use encryption check out the Cryptography package available through SqueakMap).
Each user of the system may have any number of portfolios. A portfolio is simply a collection of accounts or other portfolios that are grouped together for administrative purposes. For instance, a user may group all retirement investments into one portfolio and all non-retirement investments in another. A user might want all taxable investments in one portfolio and tax-free investments in another. The number and naming of portfolios should be user-selectable. The same information may be in multiple portfolios so that different partitions of investments can be compared.
Within each portfolio are the individual investments themselves. Investments are of many types:
- Cash Instruments: These are typical bank (checking and savings) and money market accounts that most everyone has. They allow a user to withdraw and deposit money. Some of these accounts pay interest on an annual, monthly or daily compounded rate. If an account pays interest, that interest is always credited back to the same account. Cash instruments provide the source for purchasing all other investment types. The balance in these accounts is reported in dollars (i.e. two decimal place significance). Balances of cash instruments cannot be less than zero.
- Equity Instruments: These are typically either Mutual Funds or Common Stocks.
- Mutual Funds represent indirect ownership in groups of companies where investors pool their resources to purchase large blocks of stocks. They are maintained in an account under the name of the fund family (i.e. Janus Twenty). The balance of a mutual fund account represents the number of shares currently held and should have 4 decimal place precision. Annually, mutual funds make capital gains and dividend distributions. These monies are either automatically reinvested (in which case they purchase additional shares at the then current share price) or the distribution is taken in cash. (In the real world, each of those items can be treated separately i.e. reinvest capital gains and take dividends in cash, but for this project you can treat them as one unit -either they are both reinvested or they are both taken in cash). If the distributions are taken in cash, they must be credited to an account which is a cash instrument. Shares are purchased via cash which buys the appropriate number of shares at the current market price. When shares are bought, the appropriate cash instrument should be debited. For tax purposes, a record of these transactions must be kept which includes the amount invested and the then current share price. If shares are sold (redeemed), the number of shares sold is multiplied by the then current share price and the appropriate cash instrument is credited. A transaction should be recorded with the redemption share price and amount sold, so that capital gains taxes can be computed. (The actual Capital Gains tax is not required to be computed for this project, just the information necessary to compute it has to be recorded.)
- Common Stocks represent direct ownership of companies through purchase of their shares. For this project, stocks can be assumed to be purchased through a brokerage firm. A user's stock portfolio with a brokerage firm may contain shares of stock of several different companies. A stock portfolio will also contain a special cash account called the trade account. This account receives all dividend distributions paid by a stock. It also receives the proceeds of any stock sales. Stocks may only be purchased from cash in the trade account. If insufficient funds are available in the trade account, money must be transferred from a cash instrument (via withdrawal from the cash instrument and deposit into the trade account.) until there are sufficient funds to buy the desired amount. The system should be able to report both the current value of the portfolio and the total amount of dollars invested. For instance if I buy $1000 of COKE, and the market drops, my current stock value may only be $800. (thus we are experiencing on paper a $200 loss) The system should be able to report: Total Investment: 1000 Current Market Value: 800. Like Mutual Funds, stock share balances are kept to 4 decimal place precision. Like mutual funds, we must keep a transaction history which shows the purchase amount and current share price for buy orders, and the sell amount and current share price for sell orders.
- Bonds: Bonds represent money you have lent to either a government or corporate entity. Bonds are purchased for a particular face amount and receive a stated rate of interest for a particular time period. At the end of the time period, the face amount of the bond is returned to the buyer. Interest on bonds compounds monthly. Interest payments must be made to a user-selected cash instrument. At maturity, the face value of the bond must be deposited in a cash instrument. The bond should then cease to exist (be deleted from all portfolios). Some bonds are taxable (the interest payments are taxable) and some are tax-exempt. We will ignore zero-coupon and government bonds which are bought at less than face value and then receive no interest payments, but rather you receive the full face value at maturity.
From this base data on portfolios, users would like to generate lots of information like: what is my net worth (sum of the current value of all items in my portfolios)? How much have I made (the amounts of all interest, dividends, capital gains, and adjusted current stock values)? User's also desire histories of transactions for each investment.
Be sure and look at additional information in milestones 4-7 for more specific requirements. You need to design SUnit tests to cover all the tests in your test plan at a minimum. This impacts your design somewhat. You may need to design slightly differently to make your program easily testable. Think about how you will test the classes you design.
NEW
Teams must turn in a detailed group plan THROUGH THE REST OF THE CLASS (i.e., through M7) . This should include:
- SCENARIOS that touch on EVERY CONCRETE CLASS IN YOUR SYSTEM.
- CRC card analysis for ENTIRE system (through M7).
- TEST PLAN that corresponds to the CRC card analysis, based on blackbox test criteria (i.e equivalence or boundary conditions).
- UML class diagram for the ENTIRE system with descriptions for each class. You may use any other UML diagrams in addition to a class diagram that you would like in order to describe your system.
- DESCRIPTION of what each team member is going to be responsible for (in a workspace)
- Internal group TIMELINE with dates and milestones (in a workspace)
Each team will submit a joint document with cover page. The cover page should show the team name, the team members by name and gt# and their grading TA. It should also have the date submitted and the Milestone number clearly shown.
Obviously, the design will change over the following weeks, but we want to see that you've thought through everything UP FRONT.
Note: If you would like to see good examples of project plans, check out the Cases page to see what other groups in past semesters have done.
Turnin your in your hardcopy designs in class.
Grading:
- 15% Good, believable scenarios that touch on every class in the system.
- 15% Good CRC Card Analysis: Reasonable names, understandable and clearly defined responsibilities, good exploration of other class names
- 10% Good test plan: equivalence classes clearly identified, test cases clearly defined.
- 20% Good UML class diagram and descriptions:
- Correct usage of notation (10%)
- Detailed and understandable descriptions and names (10%).
- 20% Quality of the design
- 10% Clear definition of team member responsibilities: Can you tell who will do which pieces of system (as defined in UML and descriptions)? Will you be able to figure out whose part failed if there's a failure?
- 10% Believable and detailed group timeline: Could someone figure out from this what they're supposed to be doing each week? Can a team member figure out what they're supposed to have done each week from this?
Links to this Page