View this PageEdit this PageUploads to this PageVersions of this PageHomeRecent ChangesSearchHelp Guide

Home Inventory

GROUP MEMBERS

William Horn
Steve Leighton
Ron Terrien
Stephen (Seth) Davis


PROBLEM

In order to receive fair value consideration for losses of personal property, whether for tax or insurance purposes, it is necessary to have some proof of ownership and value. Warranty claims often require proof of purchase and model & serial number information. Many people have difficulty collecting, organizing, and retrieving this information when needed.


VISION

Our project entails developing a limited (due to time constraints) but interesting means to store, organize, and retrieve needed information about personal property. We hope to exploit the power of Smalltalk, Squeak, and patterns to build an application that is easy to use, flexible, and maintainable.


TARGET USERS

Any individual who wishes to enumerate and document their personal non-monetary assets for purposes of potential tax loss warranty, and/or insurance claims.

PROJECT DETAILS

Note: We are aware that this is not a unique application. A Google on Home Inventory will find lots and lots of apps out there: freeware, shareware, and retail. It’s obviously an area of interest, and it suggests that nobody has come up with an ultimate solution. It’ll give us plenty of sources for ideas and specific challenges to explore using best practice Smalltalk and design patterns.

The data should be organized in ways that allow the user to add new types of information to keep track of (items) and various details regarding each item (attributes). Since different people have different ways to organize information, there needs to be flexibility in terms of how people can describe their items. Some items will also have the potential to contain other items. Different types/categories of items will need to have different sets of common attributes. Examples of information in hierarchies are provided below. These examples are a minimal set of the flexibility that should be provided. Attributes are listed with a leading colon ':' with the attribute name, followed by its value. (This list is just to convey possible organizational styles and has nothing to do with possible data output formats.)

  • Main residence
    • Living Room
    • Home Office
      • Bookcase one
        • Shelf 1
          • Design Patterns: Elements of Reusable Object-Oriented Software
            • :Type of Item: Book
            • :ISBN=0-201-63361-2
            • :Replacement Cost=$47.04
            • :Replacement Cost Updated: 10-July-2005
            • :Replacement Cost Source: http://www.amazon.com/exec/obidos/tg/detail/-/0201633612
          • Smalltalk Best Practice Patterns
        • Shelf 2
      • Bookcase two
  • Vacation home
  • Loaned out

  • Books
    • Design Patterns: Elements of Reusable Object-Oriented Software
      • :ISBN=0-201-63361-2
      • :Replacement Cost=$47.04
      • :Replacement Cost Updated: 10-July-2005
      • :Replacement Cost Source: http://www.amazon.com/exec/obidos/tg/detail/-/0201633612
    • Smalltalk Best Practice Patterns
  • CDs
  • Cassette tapes
  • DVDs
  • VHS tapes
  • Furniture
  • Appliances
  • Electronics

The user should be able to specify whatever type of hierarchy they desire, and if they would like to use a simple form of categorization (like the second example above), the software should support that as well. One important concept is that different types of items might have different types of attributes. Books have ISBNs, computers have serial numbers, and jewelry might have a purchase invoice that is useful in conveying a sense of value. Books shouldn't be required to have serial numbers, just because other items have them.

SUPPORTED USE CASES/USER STORIES

This a list of uses we will aim to support with our project release. (Note: Add/Edit/Remove can probably be combined…)

Create New Personal Inventory (Priority:High)
User starts a new personal inventory

Load Inventory File (Priority:High)
User loads inventory data from a persistent store.

Save Inventory File (Priority:High)
User saves inventory data in a persistent store.

Create User Item Template (Priority: High)
User creates a named template for items which should, in the user’s view, always contain certain attribute data fields. (A user’s notion of a “CD” may include Artist/Year/Title, and Add Property and Edit Property should recommend that the user define this set of attributes for an item a user has identified as a “CD”.)

Add Property (Priority:High)
User adds new items to personal inventory, supplying appropriate categorization and attribute data.

Edit Property (Priority:High)
User modifies the record of an existing inventory item, placing it elsewhere in the hierarchy or adding/removing/modifying attribute data.

Remove Property (Priority:High)
Removes an item from inventory.

Generate Property List Report (Priority:High)
User generates (pretty-printing format?) nested report on personal inventory beginning at an arbitrary point in the user’s organizational hierarchy.

USE CASES / USER STORIES FOR VERSION 2 AND BEYOND!

Generate Some Other Type of Report (Priority:Med)
We should have more than one type of report. Maybe something time based, like…

Generate Property List Change Report (Priority:Low)
User generates (pretty-printing format?) a report detailing the expansion/contraction of their property over a window of time. (Yes, this would mean keeping history and distinguishing between permanent data-entry-error type deletion and I-sold-it-to-the-neighbor type deletion.)

Text (Delimited? XML?) Import (Priority:Med)
User imports inventory items from a plain text file of a known, easily parsed format.

Text (Delimited? XML?) Export (Priority:Low, to maximize our vendor lock-in)
User exports data to an easy-to-manipulate text format to work with in preparing advanced reports, or migrate to some other product in disgust…

Combine Property AKA “Get Married” (Priority:Low)
User combines two formerly disjoint inventory files into a single inventory set.

Divide Property AKA “Divorce/Junior Moves Out” (Priority:Low)
Users indicates property to be split off into a separate inventory file.

PRELIMINARY DESIGN DECISIONS

We have made some key design decisions early on (always subject to change, of course) that will affect the outcome of the project. These include:

  • We will not make a special distinction of something called location. Everything is an item, but any item can contain other items. Plus, items can have an arbitrary set of attributes. So, for example, a house is just an item, and it can contain rooms, and those can contain, for example, bookshelves or CD racks, or whatever, which can contain the lowest-level items. Very similar to a file system based on folders, except that different folders can have different attributes.
  • Categories will serve as available templates for instantiating an item: e.g. they define a pre-established (but also changeable) set of attributes that can be given to an item when it is created. There can be as many categories as a user wants, and a category can be changed over time. Once an item is created, however, it lives apart from its category. That is, if the category is later modified, all the items of that category do NOT inherit the subsequent category changes.
  • Most home inventory systems provide for some means to sub-total and total the value of items. Some systems define multiple values, such as original cost, replacement value, depreciation, etc. Rather than pre-defining a single value, or even requiring any value, we’ll allow the user to specify what attribute they’d like to total, and any items being included in the report will be totaled on that attribute (if it exists).
  • We recognize that there’s a risk that we may not like the outcomes of all of these decisions when all is said and done. For example, by eliminating even a basic set of required attributes for items, we may not have an effective means for filtering a report. We’ll address that in version 2! Our primary goal is learning and we accept that learning from our mistakes is legitimate.

DOCUMENTATION and SUPPORTING FILES


homeInventoryProjectOverview.pdf
homeInventory st file.zip

Note: 8/7/05 -> download projectDemo.inventory below instead of zip file mentioned in overview slides (sl)
projectDemo.inventory

Link to this Page

  • Class projects last edited on 2 April 2008 at 5:20:59 pm by vpn3-144241.near.uiuc.edu