Saturday, May 23, 2009

The Summer Project 2009, Part 3: Data Design

For the first design pass, I want to simply get a basic representation of the required data and operations to see what they look like together. To start with, we'll need something to manage our accounts. For lack of a better term, call it a Portfolio. The Portfolio should allow us to add a new account and retrieve the existing accounts as a group or by name. We might as well keep the list of categories we are using here too, so we need a way of adding categories and retrieving them. That brings us to the accounts, which have a name and zero or more transactions. It should allow us to rename the account, add a transaction, and (eventually) retrieve transactions by any combination of date range and category. Which brings us to the slightly more complex transaction...

At first glance a transaction's data includes a date, a type (check, electronic transfer, charge, etc.), a number (optional), a payee, a category, a monetary total, and status for voided or reconciled. The tricky bit comes with the monetary total and category. They should probably be represented by one thing because we can't have a monetary amount without assigning it to a category. But it gets even more interesting if we allow split transactions, e.g. multiple category/amount pairs. I can't come up with anything clever to name the category/amount pair, so we'll just say Category/Value for now. Functionally, transactions should allow editing, voiding, and reconciling. Categories will start out as just a name and amounts as just a monetary value.

So the first draft of a simple functional specification broken down by class for the data types might look a little like this (plain font items are data, italics are functionality):

  • Accounts
  • Categories
  • Add account
  • Get all accounts
  • Get account by name
  • Add category
  • Get all categories
  • Name
  • Transactions
  • Rename
  • Add transaction
  • Get all transactions
  • Date
  • Type
  • Number
  • Payee
  • Status
  • Category/Value
  • Note
  • Edit
  • Mark void
  • Mark reconciled
  • Name
  • Rename
  • Category
  • Value
  • Edit
Obviously, this isn't any kind of formal specification, but it does give a nice concise summary of what the data will look like and be expected to do. And since we now have a spec in hand, it must be about time to start actually writing the program.

No comments: