Collection Inventory Software

Collection Inventory Software Final Report Team May06-04 Client David Stuart Faculty Advisors John Lamont Ralph Patterson III Team Members Eric Anderson Adam Kovar Dustin Lunde Matt Moeller Brian Steger DISCLAIMER NOTICE DISCLAIMER: This document was developed as a part of the requirements of an electrical and computer engineering course at Iowa State University, Ames, Iowa. This document does not constitute a professional engineering design. Although the information is intended to be accurate, the associated students, faculty, and Iowa State University make no claims, promises, or guarantees about the accuracy, completeness, quality, or adequacy of the information. The user of this document shall ensure that any such use does not violate any laws with regard to professional licensing and certification requirements. This use includes any work resulting from this student-prepared document that is required to be under the responsible charge of a licensed engineer. This document is copyrighted by the students who produced this document and the associated faculty advisors. No part may be reproduced without the written permission of the senior design course coordinator. Date Submitted May 3 rd 2006

Table of Contents LIST OF FIGURES LIST OF TABLES LIST OF DEFINITIONS IV V VI 1. INTRODUCTORY MATERIAL 1 1.1. EXECUTIVE SUMMARY 1 1.2. ACKNOWLEDGEMENT 1 1.3. PROBLEM STATEMENT AND SOLUTION 1 1.3.1. PROBLEM STATEMENT 1 1.3.2. PROBLEM SOLUTION 2 1.4. OPERATING ENVIRONMENT 2 1.5. INTENDED USER(S) AND INTENDED USE(S) 2 1.5.1. INTENDED USER(S) 2 1.5.2. INTENDED USE(S) 2 1.6. ASSUMPTIONS AND LIMITATIONS 3 1.6.1. PROJECT ASSUMPTIONS 3 1.6.2. PROJECT LIMITATIONS 3 1.7. EXPECTED END-PRODUCT AND OTHER DELIVERABLES 3 2. APPROACH AND PRODUCT DESIGN RESULTS 5 2.1. APPROACH USED 5 2.1.1. FUNCTIONAL REQUIREMENTS 5 2.1.2. DESIGN CONSTRAINTS 6 2.1.3. TECHNICAL APPROACH CONSIDERATIONS AND RESULTS 6 2.1.4. TESTING APPROACH CONSIDERATIONS 7 2.2. DETAILED DESIGN 8 2.2.1. DESIGN OVERVIEW 8 2.2.2. INTERFACE SCREENSHOTS 9 2.2.3. SAFETY CONSIDERATIONS 15 2.2.4. INTELLECTUAL PROPERTY CONSIDERATIONS 15 2.2.5. EXTERNAL COMPONENTS AND RESOURCES 16 2.3. IMPLEMENTATION PROCESS 17 2.3.1. IMPLEMENTATION PROCESS DESCRIPTION 17 2.3.2. IMPLEMENTATION PROCESS IMPROVEMENTS 17 2.4. END PRODUCT TESTING DESCRIPTION 17 2.4.1. TESTING METHODOLOGY 17 2.5. PROJECT END RESULTS 18 Senior Design May06-04 Project Plan i

3. ESTIMATED RESOURCES AND SCHEDULE 19 3.1. PERSONNEL EFFORT REQUIREMENTS 19 3.2. OTHER REQUIREMENTS 21 3.3. FINANCIAL REQUIREMENTS 21 3.4. PROJECT SCHEDULES 23 4. CLOSURE MATERIAL 28 4.1. PROJECT TEAM INFORMATION 28 4.1.1. PROJECT DEFINITION 28 4.1.2. TECHNOLOGY CONSIDERATIONS AND SELECTION 28 4.1.3. END-PRODUCT DESIGN 29 4.1.4. END-PRODUCT IMPLEMENTATION 29 4.1.5. END-PRODUCT TESTING 29 4.1.6. END-PRODUCT DOCUMENTATION 29 4.1.7. END-PRODUCT DEMONSTRATION 29 4.1.8. PROJECT REPORTING 30 4.1.9. FINAL PROJECT SCORE 30 4.2. COMMERCIALIZATION 30 4.3. RECOMMENDATIONS FOR ADDITIONAL WORK 30 4.3.1. GUI PREFERENCES 31 4.3.2. MULTIPLE COLLECTIONS OPEN AT ONE TIME 31 4.3.3. EXTENSIVE TESTING 31 4.3.4. ADDITIONAL PLUG-INS 31 4.4. BOTTOM-LINE RECOMMENDATIONS FOR PROJECT CONTINUATION 31 4.4.1. ADDITIONAL MULTIPLE SEMESTER SENIOR DESIGN TEAM 31 4.4.2. ADDITIONAL SINGLE SEMESTER INDIVIDUAL OR SMALL GROUP 31 4.5. LESSONS LEARNED 32 4.5.1. WHAT WENT WELL 32 4.5.2. WHAT DID NOT GO WELL 32 4.5.3. TECHNICAL KNOWLEDGE GAINED 32 4.5.4. NON-TECHNICAL KNOWLEDGE GAINED 32 4.6. RISK AND RISK MANAGEMENT 33 4.6.1. ANTICIPATED POTENTIAL RISKS AND MANAGEMENT THEREOF 33 4.6.2. ANTICIPATED RISKS ENCOUNTERED AND MANAGEMENT THEREOF 34 4.6.3. UNANTICIPATED RISKS ENCOUNTERED AND MANAGEMENT THEREOF 34 4.7. PROJECT TEAM INFORMATION 34 4.7.1. CLIENT INFORMATION 34 4.7.2. FACULTY ADVISOR INFORMATION 34 4.7.3. PHASE II MEMBER INFORMATION 34 4.7.4. PHASE I MEMBER INFORMATION 35 4.8. CLOSING SUMMARY 35 4.9. REFERENCES 35 Senior Design May06-04 Project Plan ii

5. APPENDICES A-1 A: ATTRIBUTES FOR SUPPLIED TEMPLATES A-1 B: TEMPLATE DESCRIPTIONS B-1 B.1. MUSIC TEMPLATE B-1 B.2. MOVIE TEMPLATE B-3 B.3. BOOK TEMPLATE B-4 B.4. STAMP TEMPLATE B-5 B.5. COIN TEMPLATE B-6 B.6. PAPER MONEY TEMPLATE B-7 C: HSQLDB SUPPORTED SYNTAX C-1 D: PROTOTYPE TESTING FORM D-1 E: DATA DICTIONARY E-1 F: CURRENT CLASS STRUCTURES F-1 Senior Design May06-04 Project Plan iii

List of Figures Figure 1: High Level Collection Inventory System Components... 9 Figure 2: Main Window Interface... 10 Figure 3: New Collection Wizard... 11 Figure 4: Import/Export Wizard... 12 Figure 5: CD Lookup Interface... 13 Figure 6: Database Interface Components... 14 Figure 7: Graphical User Interface Components... 15 Figure 8: Personnel Hour Distribution... 21 Figure 9: Project Cost Breakdown... 23 Figure 10: Original Estimated Project Schedule Gantt Chart... 24 Figure 11: Revised Project Schedule Gantt Chart... 25 Figure 12: Actual Project Schedule Gantt Chart... 26 Figure 13: Project Deliverables Gantt Chart... 27 Senior Design May06-04 Project Plan iv

List of Tables Table 1: Estimated (Original and Revised) Personnel Effort (in Hours)... 19 Table 2: Actual Personnel Effort (in Hours)... 20 Table 3: Estimated (Original and Revised) Project Costs... 22 Table 4: Actual Project Costs... 22 Table 5: Evaluation Scores for Milestone Completion... 28 Table 6: Summary of all attributes of all templates...a-1 Table 7: All attributes of the music template... B-1 Table 8: All attributes of the movie template... B-3 Table 9: All attributes of the book template... B-4 Table 10: All attributes of the stamp template... B-5 Table 11: All attributes of the coin template... B-6 Table 12: All attributes of the paper money template... B-7 Senior Design May06-04 Project Plan v

List of Definitions 1. Black box testing or functional testing; a testing technique where the internal working components are not known to the tester, i.e., only the inputs and expected outputs are known. 2. CVS Concurrent Versions System; a program which allows development teams to track different versions of source code as it is being completed, tested, and modified 3. Gantt chart a graphical representation pertaining to the duration of tasks versus the progression of time. 4. HSQLDB Hyperthreaded SQL Database; a java-based database and database management system. 5. IDE integrated development environment; a programming environment aided by a software application which provides tools to make programming simpler. 6. MySQL an open source software database management system created by Microsoft that uses a subset of SQL. 7. PDA personal digital assistant; a handheld device that can function as a Web browser, fax sender, personal assistant or cellular phone. 8. Phase I the section(s) performed and/or completed of this project by the Dec04-01 team. 9. Phase II the section(s) performed and/or completed of this project by the May06-04 team. 10. SQL Structured Query Language; a language designed to quickly and effectively sort, query, and manage a database. 11. White box testing or glass box, structural, clear box and open box testing; a testing technique where the specifics of the internal workings are known and used to select test data to test critical sections. Senior Design May06-04 Project Plan vi

1. Introductory Material This section provides an overview of the project; including an executive summary, acknowledgements, the problem statement and solution, operating environment, intended users and uses, assumptions and limitations, and expected end product and deliverables. 1.1. Executive Summary People enjoy collecting items and need a way to organize and inventory what they have and what they need; whether this collection is music, movies, books, coins, lawn gnomes, bottle caps, or anything else imaginable, both the usual and the absurd. Some people, in an almost feeble attempt, use hand written lists or occasionally, a minimally useful computer spreadsheet that takes more time than its worth. There should be a simpler, less time consuming and more dynamic way to do this. The issue is that there currently isn't a computer program out there that can. This project implemented a program as such: a computerized inventory system which allows collectors to easily record and maintain their collection. The system had to be simple enough so that almost anyone can operate it and dynamic enough that it can be used for any collection. It provides templates for a handful of standard items and can be operated on any standard platform, from Windows, to Mac OS, to Linux. With an attractive GUI, this software will enable collectors greater enjoyment of their hobby through greater control of their inventory. 1.2. Acknowledgement The team would like to express our gratitude to a number of individuals for their specific support of this project. First, Professors John Lamont and Ralph Patterson III for their contributions through out the project as our faculty advisors, as well as clients, they ve helped immensely in almost every aspect of this project. Second, Professor David Stuart for his continued contribution as our project client, providing and modifying the system criteria and testing the end product among other things. Finally, the team of Dec04-01, Matthew Ring, Neil Kronlage, Brian Ross, and Allan Hammell, for all of their early work on this project. 1.3. Problem Statement and Solution This section defines the problem and an overview of the project solution. 1.3.1. Problem Statement Some people have collections of only one simple item, while others have collections of many different types of items that are completely different. For example, someone might collect stamps but also have a collection of movies and music. As the size of such collections increase, managing what is already owned, what is desired, and many other things becomes increasingly difficult. Most people, if they ve even taken the time, create a very specific system for their single collection which it takes a long time to set up, has limited functionality, and little if any use outside of that single collection. Senior Design May06-04 1

A number of collections have programs designed to manage them, but these systems can only be used for a small selection of collections. Also, many of these programs are only compatible with a single platform. There is a need for a simple and flexible collection inventory program that can be used on multiple platforms and on many different collections, regardless of size. 1.3.2. Problem Solution A standalone collection inventory software application shall be produced that will use attractive GUIs to update and manage a collection and store this data in a relational database which is primarily hidden from the typical user. This database will allow for easy storage and searching of collection items. The software will need to be easily setup by the user to be applicable to their specific type of collection. However, generalized templates or wizards shall be available for users to be able to quickly begin to use the system and further customization can come later. The available templates will be for collections of movies, music, books, stamps, coins, and paper money. 1.4. Operating Environment The primary operating environment is the user s personal computer, specifically running the current platforms of Windows XP, MacOS X, and Linux kernel version 2.6. This system should also be made available for future development to the secondary systems of the user's PDA or accessibility to online data management. 1.5. Intended User(s) and Intended Use(s) This section describes who this project is defined for and how it is supposed to be used. 1.5.1. Intended User(s) The intended users of the collection inventory software are anyone who has a collection and basic computer knowledge. Collectors of music, movies, books, stamps, coins and paper money will need no further customization of the software. This system is currently only designed for English-speakers. There are no other restrictions on the target audience. 1.5.2. Intended Use(s) The collection inventory software is intended for home and personal use, as well as small businesses that intend to use the system solely for its inventory purposes. Although the system may be used for small businesses, features to provide a system for sales, purchasing and other business functions will not be included. The collection inventory software will allow users to categorize and organize any inventory of items that they have or want to collect; items could include music, movies, books, stamps, coins and paper money, among countless others. Users will be able to enter new items into both existing and new collections quickly and easily. The collection inventory software will allow users to check the content of, update and manage, and make notes of their collections or individual items within them. In Senior Design May06-04 2

addition, users can search and sort their collections efficiently according to any of the fields. 1.6. Assumptions and Limitations This section lists the initial assumptions and limitations of the project. assumptions and limitations may be added as the project progresses. Additional 1.6.1. Project Assumptions The work and source code of the Dec04-01 team will be made available. Types of data the user may enter into the inventory fields will be limited to text, numerical values, image files, and category lists. This software will run on Windows XP, MacOS X, and Linux kernel 2.6 platforms. The software will not provide any conversions on monetary values entered by user. Both English and metric standards will be accepted. All users of the collection inventory software will be proficient with the English language. Multiple users can use the software on one computer with different collections. One user can store multiple separate collections. 1.6.2. Project Limitations The work of the Dec04-01 project is to be used. o General project descriptions o Key project designs o Initial implementation The collection inventory software shall be limited in size only by the amount of disc space and memory on the user s computer as the collection data must be able to be stored on said computer. The level of computer expertise displayed by the users will range from novice to advanced users. The time allocated to this project is set at two semesters. This may require some minor features to be passed over to allow for on-time delivery of an initial release. 1.7. Expected End-Product and Other Deliverables This project shall result in a standalone software application with an easy to use interface for the management of collections which uses a database system to contain all of the information. The software shall run on most popular computer platforms and thus available for download or on an installation CD. Along with this executable, a help tutorial or manual shall be provided in order to offer further understanding of the entire software. Senior Design May06-04 3

Documentation describing all functionality, menu functions, help topics, installation methods, technical specifications, and all other useful information shall accompany the previously mentioned collection inventory software. Senior Design May06-04 4

2. Approach and Product Design Results This section will detail the requirements and constraints of this project, any approaches considered, and end-product design. 2.1. Approach Used This section details how the software was completed; specifically covering the functional requirements, design constraints, technical approaches, and the testing approach. 2.1.1. Functional Requirements This section lists and explains what functionality the software shall and shall not have. It is as follows: 1. The user shall be able to create a new collection of items. 2. The user shall be able to add an item to a collection. 3. The user shall be able to edit an existing item of the collection. 4. The user shall be able to remove an existing item from a collection. 5. A collection shall have fields which contain an item s information. 6. The user shall be able to edit these fields. 7. The user shall be able to customize the visible fields to form a view of any collection. 8. The following data types are valid for fields: strings of text, numbers, dates, and times. 9. Each field shall have a name which describes the type of information that it contains. 10. The user shall be able to define new fields for an existing collection. 11. If a new field is added to the collection, the user shall be able to define a default value for that field for all of the preexisting items within the collection. 12. The user shall be able to remove a field from a collection. 13. Collections shall either be created from a blank template or from preexisting templates. 14. Blank templates shall contain no preexisting fields or item information. 15. The user shall be provided basic templates for common collection types, specifically: music, movies, books, coins, paper money, and stamps. 16. Each predefined template shall offer the choice of item-specific attributes or field values. 17. The user shall be able to search or filter a collection for items based on a given field type. 18. The user shall be able to sort items in ascending or descending order according to a certain field value. 19. The software shall be able to dynamically build collections from a preexisting file given a user specified format. 20. The user shall be able to export the collection in multiple formats. 21. The user shall be able to print the current collection view in a grid format. 22. The software shall not support any functionality with a PDA. 23. The software shall offer various help and tutorial functions. Senior Design May06-04 5

24. The software will not use any encryption with respect to user collection information. 2.1.2. Design Constraints The design constraints are a list of non-functional requirements which the software must satisfy. 1. The software shall run on Windows XP, Linux, and Mac OS X compatible computers. 2. Collections shall be universally compatible with all versions of the software. 3. The initial version of the software shall support the English language. 4. No currency conversions shall be made by the software. 5. The software shall accept English and metric based measurements. 6. The number of fields that a collection may maintain shall only be limited by storage capacity. 7. The number of items that a collection may maintain shall only be limited by storage capacity. 8. The software shall be fully implemented and white and black box tested within 2 semesters. 9. A java runtime environment of 1.5 or later must be installed. 2.1.3. Technical Approach Considerations and Results This section will discuss the various technologies considered for this project s design. Advantages and disadvantages of all topics will be discussed as well as the reasons for the final decision. 2.1.3.1. Programming Language Because the project was a continuation of a previous team s attempt, all existing source code was used whenever possible. This means that development continued in Java as it was the programming language previously used by Phase I. The reasons for the selection of Java are: the cross platform advantages of Java were necessary for completing this project on time, and Java is supported on all target systems making it easy to write one version of the software which will run on all platforms. 2.1.3.2. Database Manager Again, Phase I made the decision on what type of database manager to use. HSQLDB was chosen as the database for this project. It was chosen because it is platform independent, it has an easy setup making it ideal for novice users, it does not require a lengthy amount of time to configure, and it demands reuse of existing components. 2.1.3.3. Development Software In order to reduce the amount of time required for development, the team considered two different integrated development environments (IDE s) which provide a programmer with an environment where they can develop code quickly Senior Design May06-04 6

and easily. The IDE s assist with correcting code mistakes, giving a developer runtime errors, displaying available commands, and many other features. For Java programming, the team considered the Netbeans and Eclipse IDE s for the development of the application. NetBeans NetBeans is a Java IDE created by Sun Microsystems, the makers of Java. It is available free of cost from Sun s website. An advantage that NetBeans has is its graphical user interface (GUI) designer. It has a drag-and-drop interface that is easy and simple to use for creating complex designs. NetBeans will work on any platform as long as the Java runtime is installed. A major disadvantage of NetBeans is in the application s speed. NetBeans is a very large program and it was written in Java making it very slow on older or low-performance computers. Eclipse Eclipse was developed by IBM and is now a completely open-source program written in Java with contributions from an enormous online community. Its interface makes it much faster than NetBeans. An advantage of using Eclipse is the many plug-ins available. Any developer can create a plug-in for Eclipse, extending its functionality. Some examples of plug-in functionality are C++ development, C# development, GUI creation, and many more. Eclipse does have its disadvantages too. It is always being worked on and upgraded by the open-source community; therefore, sometimes the features that are needed might be contained in a release that is not stable yet. Eclipse is also written in Java with makes it slower on older or low-performance computers. Selected Development Environment: Eclipse This project s development will be done in Eclipse. Even though both NetBeans and Eclipse are both written in Java, Eclipse is still considerably faster. Eclipse also provides the developer with greater control of the code written. A plug-in for Eclipse called Jigloo will enable the team to create GUI s as easily as in NetBeans. 2.1.4. Testing Approach Considerations The software will need to be tested in order to ensure that it meets all functional requirements. The team will utilize two modes of testing: white-box and black-box. White-box testing will begin during the implementation phase of the project. While a team member writes the program codes, he shall also write a piece of code to test the new functionality. Manual or automated testing such as JUnit will be the main methods of the white-box tests. JUnit is a feature within Java created for testing applications functionality. It provides the developer with the tools needed to test a function very quickly and over a wide variety of criteria. Senior Design May06-04 7

Black-box testing will begin after the implementation phase is complete to the team s satisfaction. The application will be delivered to the client to test the usability and functionality. During the client s test, a form will be provided with question to fill out and an area to give additional comments. See Appendix D for an example of the form that will be used. Any errors or suggestions found will then be discussed and a decision will be made to make a change or not. If changes need to be made, the team may need to update the design document and then implement the changes. 2.2. Detailed Design This section features a thorough description of the design of the final software component. 2.2.1. Design Overview The database interface is the component of the program that manages the collection. It is responsible for storing, searching and modifying the collection s information and structure. It also provides everything necessary to add and extract items to and from the database. The graphical interface is the users view of the program. It provides facilities to access all features of the program. This component provides a graphical view of the features in the database interface component. This component is devoted only to the graphical interface; it has no knowledge of the database structure and only interacts with the database interface while retrieving and updating items in the collection. This software is designed to allow additional functionality to be added at a later time without rewriting the initial components. These additional functions are packaged in plug-ins that the user can load. The program also allows default loading of plug-ins so common plug-ins are always available. The plug-ins have the ability to add and retrieve items to or from the collection through a restricted interface to protect the database. Online CD lookup is a feature that is well suited for plug-ins. This component is useful for more than just music collections, and thus will automatically be loaded when starting a collection of any type. Phase I has already implemented this plug-in, so only minor modifications were needed to meet the updated requirements. This plug-in allows a music collector to reduce the amount of data to enter by hand by searching by title, artist, or song in the online CD database. The plug-in system allows for future expansion of the project. Such features as a PDA implementation or HTML reader/writer could be easily added. The PDA implementation could allow for a PDA to retrieve items from the database as well as update modified items through the plug-in. Figure 1 shows the components and major functions that the team has completed during the current senior design session. Senior Design May06-04 8

Figure 1: High Level Collection Inventory System Components 2.2.2. Interface Screenshots This section shows screenshots of the program thus far in its implementation. Short descriptions of these screenshots are also included. These are not necessarily the final product as further changes and updates will continue to be made. 2.2.2.1. Main Window Interface The main program is represented below in Figure 2. The right panel displays all attributes of the selected item and contains check boxes to select whether or not to display that attribute in the left view panel. There is also a quick search option at the top of the window which will query either the entire collection or the currently viewed data. This layout allows the user to quickly view any or all data they need to for any given item in their collection. It also minimizes the clutter for collections that have a lot of information but very little is needed at any specific time. For example, a movie collection data set could include title, runtime, rating, price, own, want, copyright and comments, but copyright and comments do not always need to be displayed. However, by selecting a given item in the left panel, all information is readily available for that item in the right panel. Also at a later time, price could be removed from the display in the left panel as well. Senior Design May06-04 9

Figure 2: Main Window Interface The figure also shows a menu bar and tool bar. The tool bar, which includes the search functions already mentioned, allows the user to more quickly access common actions for the program, such as saving the view, printing the current table, or opening a new or different collection. 2.2.2.2. Main Menu Interface The main menu consists of the standard categories commonly found in most applications. These include menus such as: file, edit, tools, view, and help. These menus include functions that are present on the toolbar and main screen as well as functions not as frequently required by the user. 2.2.2.3. New Collection Wizard Interface The new collection wizard is comprised of several smaller steps that allow a user to create a new collection. Two types of collections can be created, custom or template-based collections. Both of these collections allow the user to import existing data from magnetic format or create a completely blank collection to be added to later. Figure 3 shows a screen capture of the new collection wizard that has been implemented. Senior Design May06-04 10

Figure 3: New Collection Wizard 2.2.2.4. Import/Export Interface The import window is shown in Figure 4. At the top of the window is a display of the opened file to be imported for quick reference. In the middle of the window are three lists, Available Attributes, Available Separators, and Selected Attributes. Finally at the bottom there is a layout display, which displays exactly what will be imported into which attributes based on what is in the selected attributes list. The available attributes list contains all attributes that are defined in the collection. If a new attribute needs to be added to accommodate the import data, there is a readily available button to open the new attribute portion of the new collection wizard. The available separators list contains all previously defined separators, a general list will come by default. Any new separators can be added by clicking the New Separator button. This allows for many very different types of data layouts, as just about anything can be used to separate attributes in existing data sets. By first selecting an available attribute, then by selecting an available separator, pressing the >> button will add the attribute-separator combination to the bottom of the selected attributes list. Items can then be moved to the correct order by using the Up and Down buttons. Also by using the << button, items can be removed from this list. Senior Design May06-04 11

This import layout allows the user to easily import existing data into a new or old collection. By displaying both the file that has been opened and exactly what the program is going to try to do, the application has added one more failsafe to avoid mishaps. Figure 4: Import/Export Wizard 2.2.2.5. CD Lookup Interface The CD lookup interface is a simple GUI that allows the Collection Inventory Software user to interact with the freedb.org database to query CD information. The interface allows for four different search methods: all, artist, title, and track. If the user finds the information he/she is looking for, they will be able to add the chosen CD to their collection with all of the information provided by freedb.org. Senior Design May06-04 12

Figure 5: CD Lookup Interface 2.2.2.6. Class Diagrams The following diagrams give a high level overview of the Collection Inventory Software structure. Figure 6 delivers a diagram of the database interface components used to produce the core functionality of the system. The graphical user interface layout and connections are visible in Figure 7. Senior Design May06-04 13

MusicCollection MovieCollection BookCollection Collection +Collection() +addtable(in Table : Table) +gettables() : Table +deletetable(in table) CoinCollection PaperMoneyCollection StampCollection 1 * Schema AttributeType Table +getattributetypes() +Table() +additem(in item : Item) +removeitem(in item : Item) +upadteitem(in item : Item) +getitem(in id) +getname() +setname(in name) +getschema() +search(in value, in attribute : Attribute) : Item 1 * Item Attribute -Type : AttributeType +gettype() IntegerAttribute StringAttribute DateAttribute TimeAttribute CurrencyAttribute BooleanAttribute ReferenceAttribute Figure 6: Database Interface Components Senior Design May06-04 14

Figure 7: Graphical User Interface Components 2.2.3. Safety Considerations The collection and inventory software is only designed for non safety critical applications. The licensing agreement shall exempt the team from any damage of information resulting from the use of the software. 2.2.4. Intellectual Property Considerations The software will be available as open source upon completion allowing anyone access to the source code. This will allow future development on the software. But Senior Design May06-04 15

upon completion, the client and/or faculty members may choose to commercialize the software as they see fit. 2.2.5. External Components and Resources This section outlines the necessary components to complete this project, the source, and estimated cost. Java Vendor: Sun Microsystems Website: java.sun.com Estimated cost: $0.00 Description: The Java development kit is a free download on Sun s website. Phase I wrote the previous version in Java. HSQLDB Vendor: The HSQLDB Development Group Website: http://hsqldb.sourceforge.net Estimated Cost: $0.00 Description: HSQLDB is a free, open-source database manager written entirely in Java. Phase I used HSQLDB for their database. Eclipse Vendor: IBM Website: www.eclipse.org Estimated Cost: $0.00 Description: Eclipse is the development tool chosen for the software development of this project. The software is a free, open-source program that includes support for Java development. This also allows for CVS, a version control system to be implemented and shared among team members. Development Platforms Vendor: Various Website: NA Estimated Cost: $0.00 Description: The development team will produce the software on their home IBM compatible computers with Microsoft operating systems or similar systems available in computer labs on the Iowa State University campus. There will be no costs. Test Platforms Vendor: Various Website: NA Estimated Cost: $0.00 Description: The software will be tested on several platforms. The initial testing will occur on the team members development platforms. The team will also test the software on Macintosh and Linux systems available on campus. The faculty and client will test the software on their existing computers. Senior Design May06-04 16

2.3. Implementation Process This section explains the process used to implement the requirements set forth in the project s design specifications. It also explores alternative methods and suggestions that may have led to faster implementation. 2.3.1. Implementation Process Description The first step of the implementation process was familiarizing the group with the previously implemented code of Phase I. To accomplish this task, the group divided the software into five logical sections. For a one week period of time, each group member was to analyze the section of software assigned to him. When the group met again for the next team meeting, each group member was to report to the entire team what they had learned about the system and do their best to explain how things worked. The next step was to start implementing features. The team agreed on a list of features and had prioritized them according to the team s consensus. Features were divided among the team members and each person was held responsible for implementing their part. This approach tried to keep everyone working separately to prevent team member s from interfering with each other when writing their code. Also, by having a team member act as an owner of a piece of code, if someone had a question it was relatively easy to get it answered by asking the correct person. After the new features had been implemented to a point and added to the application, the group would meet in a lab where they could easily communicate. The purpose of this was to give everyone a chance to use the new features and while sitting there troubleshoot any problems that arose and get them taken care of quickly. 2.3.2. Implementation Process Improvements The process of having the developers implement their parts separately seemed to work fairly well. A way to improve this process would have been to meet with the group more often. While meeting with the group as a whole, it seemed that questions would get answered faster and more work would get done. A process where the team would meet together discuss some things then go write code for the rest of the time may have been better suited for the situation. Or perhaps have the team meeting at the end before everyone goes home. This methodology would allow for decisions to be made quicker and more implementation to be done. 2.4. End Product Testing Description This section explains the testing methodology used when verifying the Collection Inventory Software. 2.4.1. Testing Methodology The team s testing strategy for verifying the software was strictly to use human testing. While JUnit testing was a possibility, the team felt that it would not provide the feedback or the variety that human testing could. To proceed with the testing, the Senior Design May06-04 17

team compiled a beta release of the software and made it available on the senior design website. This was made known to the team s advisors and the client. These beta testers download the program and start using it. If they find any problems with the software they were to report it back to the team so that a fix could be made and another release could be compiled and uploaded to the website. For error reporting, the team created an account with GMail. If any of the testers found a problem with the system, they simply had to send a description of their problem in an e-mail to the given GMail account. All team members had access to this mailbox and could see the feedback whenever they logged in. When a bug had been fixed, the person who fixed it was also responsible for logging into the GMail account and adding the closed label to that particular bug so that no one else would start to work on it. The team feels that this method worked exceptionally well and other groups may want to think about doing things in a similar fashion. 2.5. Project End Results This section lists the accomplishments the team has made on the software over the course of the year. The major accomplishments are the addition of the edit bar on the side of the main screen, and redoing search to have it work on the main screen. The team now has a functional piece of software that has undergone dramatic enhancements since its inception and first build. Now collectors have an application that can take care of pretty much any collection and it is also available that the greatest price: free. Senior Design May06-04 18

3. Estimated Resources and Schedule This section contains the original and revised estimates for the project resources and schedule created earlier in the year, as well as the final results for the Collection Inventory Software. The resources have been broken up into three separate categories; these categories are personnel effort requirements, financial requirements, and other requirements. Reasons for the variances in the predictions and results will be analyzed and stated. 3.1. Personnel Effort Requirements The first table below is the original estimate made by the team for the number of hours each member would contribute to the project. As these figures were produced very early on in the project, it was expected there would be a significant variance in the final outcome. As the project progressed, the initial predictions remained accurate throughout the researching and design phases. Because of this, the original estimate and revised estimates for team hours remained the same. The predictions changed and those changes are reflected in the second table below which contains the actual hours contributed to the project. Table 1: Estimated (Original and Revised) Personnel Effort (in Hours) Problem Definition Tech. Considerations and Selections End-Product Design End-Product Implementation End-Product Testing End-Product Documentation End-Product Demonstration Project Reporting Total Eric Anderson 4 4 25 33 42 31 26 35 200 Adam Kovar 4 3 28 30 36 32 25 45 203 Dustin Lunde 4 2.5 27 31 38 33 21 50 207 Matt Moeller 4 3.5 26 32 39 35 24 43 207 Brian Steger 3 3 29 35 40 30 22 40 202 Total 19 16 135 161 195 161 118 213 1018 Senior Design May06-04 19

Table 2: Actual Personnel Effort (in Hours) Problem Definition Tech. Considerations and Selections End-Product Design End-Product Implementation End-Product Testing End-Product Documentation End-Product Demonstration Project Reporting Total Eric Anderson 4 4 25 33 42 16 21.5 19 165 Adam Kovar 4 3 28 30 36 17 23 20 161 Dustin Lunde 4 2.5 27 31 38 17.5 21 36 177 Matt Moeller 4 3.5 26 34 39 14 19 18 158 Brian Steger 3 3 29 35 40 15 22 25 172 Total 19 16 135 163 195 79.5 106.5 118 832 All team members had a partial role fulfilling each of the defined tasks. If the task was particularly large, it was broken up and the team decided how to appropriately assign each member an adequate portion. With other tasks, such as end-product demonstration, it will be necessary to have the entire team present and contributing almost equally. The actual personnel effort was approximately 18% less than the original estimate. The reason for this is mostly due to the team over-estimating for project reporting and documenting. Because of the clarity of the instructions and the ability to modify and reuse charts and sections from previously created documents, the team was able to efficiently produce the artifacts for this project. The project reporting section also holds the key for the only significant difference in team hours. Because Dustin Lunde was the team coordinator, he was responsible for weekly reporting and this added a little more time to his totals in this area. The following chart shows the relatively even distribution of work from all team members. Senior Design May06-04 20

180 160 140 120 100 80 60 Project Reporting End-Product Demonstration End-Product Documentation End-Product Testing End-Product Implementation End-Product Design Tech. Considerations and Selections Problem Definition 40 20 0 Anderson, Eric Kovar, Adam Lunde, Dustin Moeller, Matt Steger, Brian Figure 8: Personnel Hour Distribution 3.2. Other Requirements Computer and internet access, including web space for the project webpage, was already available to the team to work on the project. Other resources that were required include: printing of project poster, printing and binding of all reports, distribution media, project log books, and most other unforeseen items. The cost of all items listed here was consumed by the team or an individual team member. 3.3. Financial Requirements This project had a maximum budget of $150 for parts, materials, and other necessary items. Below is a table indicating estimated materials and related costs. Also included is an estimate of software development cost with labor added in. Senior Design May06-04 21

Table 3: Estimated (Original and Revised) Project Costs W/o Labor With Labor Parts and Materials a. Dev. Tools $0.00 $0.00 b. Poster Materials $50.00 $50.00 c. Printing and Binding $25.00 $25.00 Subtotal $75.00 $75.00 Labor at $12.00/hr Eric Anderson $2,400.00 Adam Kovar $2,436.00 Dustin Lunde $2,484.00 Matt Moeller $2,484.00 Brian Steger $2,424.00 Subtotal $12,228.00 Total $75.00 $12,303.00 All development tools are available through Iowa State University or are free to the public for use. The poster was estimated to cost approximately 50 dollars to produce, but didn t due to the use of the department of Electrical and Computer Engineering s printers. Labor costs were estimated by taking 12 dollars an hour for each group member and their predicted labor hours in Table 2. Because of the significant decrease in actual hours contributed to the project, the project cost with labor substantially decreased. The ability of the Computer Services Group to print our poster also reduced the cost for that. The team was also able to print and bind the documents for less than the initial estimated cost. The following figures break down these values. Table 4: Actual Project Costs W/o Labor With Labor Parts and Materials a. Dev. Tools $0.00 $0.00 b. Poster Materials $18.18 $30.18 c. Printing and Binding $15.65 $27.65 Subtotal $33.83 $57.83 Labor at $12.00/hr Eric Anderson $1,974.00 Adam Kovar $1,932.00 Dustin Lunde $2,124.00 Matt Moeller $1,890.00 Brian Steger $2,064.00 Subtotal $9,984.00 Total $33.83 $10,041.83 Senior Design May06-04 22

Figure 9: Project Cost Breakdown 3.4. Project Schedules The first Gantt chart shown depicts the team s original plan to accomplish the goals of this project. In order to extensively test and provide test support for the Collection Inventory Software, the team hoped to complete all project tasks up to product testing by the end of the fall semester. Tasks included up to that point are: defining the project, technology considerations, product design, and product implementation. The second semester of the project was originally designed to be devoted to product testing, documentation, and demonstration. A lot of time was devoted to testing because it involves the cooperation of individuals outside the immediate team. This original project schedule is displayed in a Gantt chart below, Figure 10. Senior Design May06-04 23

Figure 10: Original Estimated Project Schedule Gantt Chart Senior Design May06-04 24

The second Gantt chart displays the revised project schedule the team developed during the design reporting phase of the project. Being further into the project, the team was able to modify the original project schedule to more accurately reflect the project status. Implementation was the major adjustment made to this Gantt chart. The team was also able to narrow down the time for the IRP presentation to a one week period. Figure 11: Revised Project Schedule Gantt Chart Senior Design May06-04 25

The third Gantt chart displays the actual project schedule the team followed to complete the Collection Inventory Software. This is shown below. This chart displays how product implementation took place throughout the entire second semester of the project. This was necessary to completely debug the application and fully support the testing process. The team was also given the date for the IRP presentation, so they were able to directly indicate when that would take place. Figure 12: Actual Project Schedule Gantt Chart Senior Design May06-04 26

The following Gantt chart has remained the same throughout the course of the project. It consists of the deliverable dates for all the artifacts contained in this project. We successfully met all deadlines throughout the course of the project. Figure 13: Project Deliverables Gantt Chart Senior Design May06-04 27

4. Closure Material This section contains information about the team members responsible for this project, their faculty advisors, and the product s client. It also contains an overall summary of the project, an evaluation of the project success, and any reference material the project team used in developing the product. 4.1. Project Evaluation This section describes the milestones for the project and the criteria used to evaluate the success of the completed project. For each milestone, the team evaluated the completeness and success of that item and assigned a score to it from Table 5 below. The team then took the scores for all of the individual milestones and multiplied them by their overall importance metric to get a final score for the project. A final score of greater than 85% is considered a success for the project. Table 5: Evaluation Scores for Milestone Completion Evaluation Result Numerical Score Greatly Exceeded 100 % Exceeded 100 % Met 100 % Almost Met 90 % Partially Met 80 % Did Not Meet 40 % Did Not Attempt 0 % 4.1.1. Project Definition Description: The project had to be adequately defined before work could commence. An accurate definition ensured all team members knew the scope and desired functionality of the project. Evaluation criteria: This was defined by Phase I. Overall importance: 10% Milestone score: 100% 4.1.2. Technology Considerations and Selection Description: The project team members had to research available software technologies such as software tools, languages, databases, and IDE s. From these, the team selected the technologies that helped produce software that met all functional requirements in the shortest amount of time with minimal amount of errors. Senior Design May06-04 28

Evaluation criteria: The team determined how well all options for technology were considered. Overall importance: 10% Milestone score: 100% 4.1.3. End-Product Design Description: The end-product design detailed all components of the final product. This expanded the functional requirements to include architectural details of the software and implementation-level design choices. The design provided interface specifications for software modules and classes. Evaluation criteria: The team determined how well the design accomplished the functional requirements and facilitated ease of implementing the design. Overall importance: 15% Milestone score: 100% 4.1.4. End-Product Implementation Description: The prototype is the realization of the product design in actual software. Evaluation criteria: The team determined how well the prototype conforms to the functional requirements and design. Overall importance: 22% Milestone score: 100% 4.1.5. End-Product Testing Description: The end-product testing ensured that the product is free of bugs and errors. Evaluation criteria: The team determined the quality, usability, and lack of bugs of the software. Overall importance: 15% Milestone score: 80% 4.1.6. End-Product Documentation Description: The end-product documentation provides a user manual for the software. Evaluation criteria: The team determined how clearly the end-product documentation described the usage of the system. Overall importance: 8% Milestone score: 80% 4.1.7. End-Product Demonstration Description: The final software was presented to the client. The client was informed of the use of the software. Evaluation criteria: The team determined how well the end-product solved the intended purpose of the project. Overall importance: 8% Milestone score: 90% Senior Design May06-04 29

4.1.8. Project Reporting Description: The team created several documents as the project progresses. These included the project definition, project plan, product poster, end-product design, and final report. The final reporting for the project described all aspects of the system and included maintenance documentation that details the implementation of the project. The final report will be the longest surviving record of the project implementation and had to account for any changes to functional requirements, design, and architecture made through the development of the end-product. Evaluation criteria: The team measured how well the final report captures all salient aspects of the project for future reference. Overall importance: 12% Milestone score: 100% 4.1.9. Final Project Score The result of the project evaluation was determined by multiplying the milestone score by the overall importance, and finding the sum of each milestone. The computation has resulted in an overall final project score of 93.75% which results in a successful project based on the criteria defined at the onset of the project, 85% being a success. 4.2. Commercialization The collection inventory software produced has the potential to be marketed to collecting enthusiasts, as well as instructors. The product is not designed as a commercial product, but if the results are favorable the team estimates that the project took about $11,000 to produce. The features not included in this software that are deemed desirable to a marketable product, such as the ability to download collections to a PDA, programming the software to be optimized for compactness and speed, and programming data-checking into the software, would only cost a firm the labor hours for development. The team would also like to perform more testing that will be allowed for during the two semesters of the project. These remaining features are estimated to cost about $11,000 dollars more in labor costs at a rate of $12.00/hour resulting in an updated total project cost of $18,000. The actual cost of producing a sellable product after the initial software application is developed would be negligible as the software would be distributed by CD media or as an online download. The team believes that a reasonable selling price of the software would be $25/license. If such a commercial product should be released, it should be noted that any commercially released product containing the HSQLDB needs to have the disclaimer listed in the appendix. 4.3. Recommendations for Additional Work This section makes recommendations for continued work on the project. This additional work includes items that were passed over in the infancy of the project and items that were passed over during the development of the software as it became clear that time constraints would not allow their completion. It should be noted that the majority of these items were not explicitly defined in the team s design report, but were items that would be desirable in a finished product. Senior Design May06-04 30

4.3.1. GUI Preferences The first recommendation for additional work would be to add more GUI preferences to the preferences dialog already in place. This would also include implementing the disabled functionality in the existing preferences window such as alignment for headers, default font for headers, and default font for cells. 4.3.2. Multiple Collections Open At One Time The second recommendation for additional work would be to implement the window view, another feature that the team had to drop due to time constraints. This window view will enable the user to have multiple collections open at one time and give them a means of selecting which collection is displayed. These window views of multiple collections would all be displayed in the main GUI window so that the user would not have to navigate through multiple, separate windows for each collection. 4.3.3. Extensive Testing The third recommendation for additional work would encompass all of the aforementioned items for additional work and it involves testing. This is a major component of future work and is important for the success of the product. Due to the time constraints, and the lengthy development of the software, the team was not able to accomplish the thorough amount of testing to ensure a completely bug-free, optimized software product. This extra testing of the above new components, as well as the software refinements, would make for a more stable and useable product. 4.3.4. Additional Plug-ins The fourth recommendation for additional work would be additional plug-ins to allow for the importing of more data. Such as FreeDB was used to access cd information from the web and import that into a collection, movie databases exist as well as possibly vinyl record databases that may provide collectors with a lot more information than they have in their current collections. The more of these services available to the user, the more useful and enjoyable this product will be to them. 4.4. Bottom-Line Recommendations for Project Continuation The team recognizes two possibilities for future development of the project. This section discusses each possibility below. 4.4.1. Additional Multiple Semester Senior Design Team If another senior design team is assigned the task of implementing additional features to the CIS project, the team recommends that extensive testing be performed on the existing application to expose any hidden bugs that were not uncovered by the original team. The team believes that another senior design team would be able to implement most, if not all, of the additional features listed in Section 4.3. 4.4.2. Additional Single Semester Individual or Small Group Senior Design May06-04 31

Another possibility for continued development of this project would be for an individual or small group to perform thorough testing and maintenance of the original software to expose and fix any existing bugs that were not uncovered by the original team. The team believes that another senior design team would be able to implement most, if not all, of the additional features listed in Section 4.3. 4.5. Lessons Learned This section outlines some of the lessons learned by the project s team during the two semesters of senior design. 4.5.1. What Went Well The team had several successes over the course of the project. The team all in all put together a great end product. This was accomplished with the help of Phase I s previous work and the great work of Phase II to add, update, or remove anything to make the end product what it is today. The team managed to meet each week and work together to set goals and accomplish those goals by given deadlines. The distribution of work remained fair throughout the project as well. 4.5.2. What Did Not Go Well The team had a few difficulties during the course of the project. This included a few instances when the CVS server was down or had switched IP addresses. The overall scheduling was also delayed and everything pushed back due to time constraints. Because the team inherited a lot of quickly written and uncommented code from Phase I, there were quite a few difficulties initially in trying to make progress on the software. The delays caused by this hurt team morale. 4.5.3. Technical Knowledge Gained Each team member learned several new technologies while working on this project. The first technology was the features of Microsoft Word that helped create technical reports. When developing, the team members were exposed to Java, database, and graphical interface programming. HSQLDB was a database new to all members of the group. A wealth of database knowledge was gained trying to work with this new database. The complexity of the user interface, primarily the tables, required a lot of research into abstract programming techniques. 4.5.4. Non-technical Knowledge Gained Not everything the team learned was technical. The technical reports and presentations gave the team members excellent practice with the types of documentation of the working world. Time management skills were also developed as the team tried to work in a group consisting of five different individuals with completely different schedules. As programming on this project was a collaborative effort, individuals also had to develop personal skills and the ability to transfer knowledge to the other group members effectively. Senior Design May06-04 32

4.6. Risk and Risk Management This section describes the anticipated potential risks of this project as well as the steps taken to minimize the damage of their occurrence to the project s success. In addition this section also describes the unanticipated risks encountered, and the success of the steps that were taken in an effort to manage these risks. 4.6.1. Anticipated Potential Risks and Management Thereof The first anticipated potential risk that the team planned for was the loss of a team leader. In order to minimize the chance of this risk damaging the success of the project, the team took many precautionary measures. One was to start taking meeting minutes at most of the individual team meetings which covered which topics were discussed, what was worked on during the meetings, any outstanding issues to be covered in a future meeting, tasks assigned to individual team members, and goals for the time between meetings. These meeting minutes were useful means of documenting the process of the project as well as to keep all team members abreast of what the other team members were working on outside of the team setting. In this way, if the team did lose a member, the other members would know what the lost member had worked on, were working on, and were planning on working on. These meetings were cataloged on the team s web site to make them easily accessible to all in the team. Another precautionary step along the lines of posting meeting minutes to the web site was to post all project documentation (problem definition, design report, project poster, testing forms, major collection templates, etc.) and weekly reports, which were sent to the client and faculty advisors, were posted to the team web site. A second anticipated potential risk was the loss of code or documentation. The team countered this by storing all project code and documentation in a CVS repository that was available to all team members and was stored on an engineering server that was backed up on a regular basis. A third anticipated potential risk was the understanding of Phase I s implementation and Phase II s ability to update and manage their previous code. To make sure the code was understood the team gave each team member a section of code to study and report to the other team members about this. There was also enough time planned for the team to update and manage this code successfully. A final anticipated potential risk was to create a product that was unsatisfactory to the client. The team countered this by first establishing clear functional requirements by meeting with the client at the beginning of the project to get his vision of what the end product would be as well as finding out his desired uses of the project. The team then spent weeks with the faculty advisors further defining the project based on information that the client provided in regards to music collections, as well as information gathered by the team on other main types of collections (i.e. movies, books, stamps, coins, and paper money). The team also kept the client in constant communication through the previously mentioned face-to-face meetings as well as Senior Design May06-04 33

sending him weekly reports of the project status. The client is also involved in the product testing and will be the ultimate judge of its success. 4.6.2. Anticipated Risks Encountered and Management Thereof The only setback that the team foresaw and encountered was the understanding of Phase I s implementation and their ability to update and mange their code successfully. The team planned accordingly before they started to dive into the previous team s code, and assigned each member with a part of code to report back the next week. This was done for several weeks until they had understood the code as a team. Then they were able to update, edit, and manage this code successfully. 4.6.3. Unanticipated Risks Encountered and Management Thereof The team did not encounter any unanticipated risks. 4.7. Project Team Information 4.7.1. Client Information Professor David Stuart 241 Music Hall Ames, IA 50011 (515) 294-2924 (Phone) (515) 294-6409 (Fax) dstuart@iastate.edu 4.7.2. Faculty Advisor Information Professor John W. Lamont 324 Town Engineering Ames, IA 50011 (515) 294-3600 (Phone) (515) 294-6760 (Fax) jwlamont@iastate.edu Professor Ralph Patterson III 326 Town Engineering Ames, IA 50011 (515) 294-2428 (Phone) (515) 294-6760 (Fax) repiii@iastate.edu 4.7.3. Phase II Member Information Eric Orion Anderson CprE (815) 347-6668 airander@gmail.com Adam Kovar CprE Senior Design May06-04 34

(402) 617-1390 akovar@iastate.edu Dustin Lunde CprE (507) 219-9698 dlunde@iastate.edu Matt Moeller CprE (319) 470-8614 moellerm@iastate.edu Brian Steger CprE (563) 580-0583 bstegs@iastate.edu 4.7.4. Phase I Member Information Matthew Ring (Project Leader) CprE/ComS (515) 268-0036 mring82@iastate.edu Neil Kronlage (Communications Coordinator) CprE (515) 572-3181 nkron@iastate.edu Brian Ross EE (515) 292-0546 bfross@iastate.edu 4.8. Closing Summary Individuals with difficulty keeping track of their growing collections now have a solution that is easy-to-use, platform independent, and completely customizable. The end-product provides collectors with a program to keep track of their unique collections easily and efficiently, while giving them the most control over inventory management. Windows and Macintosh users both can benefit from this full-featured collection management tool. 4.9. References This section provides a list of references that were used in the technical approach and considerations section as well as throughout the development of the collection inventory software. Arnold, Ken, et al. The Java Programming Language, 3rd Edition. Boston: Addison- Wesley Co. 2002. Burd, Barry. Java 2 for Dummies. New York: Wiley Publishing, Inc. 2001. Keogh, Jim. Java 2 Database Programming for Dummies. New York: Hungry Minds, Inc. 2001. Senior Design May06-04 35

Lemay, Laura and Rogers Cadenhead. Sams Teach Yourself Java 2 in 21 Days. Indiana: Sams Publishing Co. 1999. Piroumian, Vartan. Java GUI Development. Indianapolis: Sams Publishing Co. 1999. http://www.sleepycat.com Berkeley DB Database Manager http://hsqldb.sourceforge.net/ - Developer s resources for an Open Source Java Database engine. http://www.eclipse.org Eclipse Development Environment http://java.sun.com/ - Java Developers Source Page http://www.cloudgarden.com/jigloo/index.html - Jigloo GUI Builder http://msdn.microsoft.com/vstudio/ - Microsoft Visual Studio Development Environment http://www.mysql.com MySQL Database Manager http://www.netbeans.org NetBeans Development environment Senior Design May06-04 36

5. Appendices A: Attributes for Supplied Templates Table 6 below provides a summary of all templates and their attributes. Table 6: Summary of all attributes of all templates Senior Design May06-04 A-1

Senior Design May06-04 A-2

B: Template Descriptions It is important for all users to be able to quickly and easily create a collection suited to their needs. The collection inventory system provides a list of templates that can be used when creating some of the more common collections. The templates provided allow for music, movie, book, stamp, coin, and paper money collections. The following tables further detail the provided templates and the attributes described in appendix A. Each of the tables in this appendix follow from those generated by Phase I. B.1. Music Template Table 7 lists all of the attributes provided in the music template. Table 7: All attributes of the music template Senior Design May06-04 B-1

Senior Design May06-04 B-2

B.2. Movie Template Table 8 lists all of the attributes provided in the movie template. Table 8: All attributes of the movie template Senior Design May06-04 B-3

B.3. Book Template Table 9 lists all of the attributes provided in the book template. Table 9: All attributes of the book template Senior Design May06-04 B-4

B.4. Stamp Template Table 10 lists all of the attributes provided in the stamp template. Table 10: All attributes of the stamp template Senior Design May06-04 B-5

B.5. Coin Template Table 11 lists all of the attributes provided in the coin template. Table 11: All attributes of the coin template Senior Design May06-04 B-6

B.6. Paper Money Template Table 12 lists all of the attributes provided in the paper money template. Table 12: All attributes of the paper money template Senior Design May06-04 B-7

C: HSQLDB Supported Syntax Phase I selected HSQLDB as the database for the collection inventory software. Here is a list of supported SQL commands for HSQLDB version 1.7.0 from http://hsqldb.sourceforge.net/ web/hsqldocsframe.html. SELECT CREATE TRIGGER REVOKE CALL DROP TRIGGER SET PASSWORD INSERT CREATE VIEW SET REFERENTIAL_INTEGRITY UPDATE DROP VIEW SET TABLE READONLY DELETE SET AUTOCOMMIT SET TABLE SOURCE ALTER TABLE COMMIT SET WRITE DELAY ALTER INDEX ROLLBACK CHECKPOINT CREATE ALIAS CONNECT SCRIPT CREATE INDEX DISCONNECT SET IGNORECASE DROP INDEX CREATE USER SET LOGSIZE CREATE TABLE DROP USER SHUTDOWN DROP TABLE GRANT HSQLDB also supports the following SQL features: Expression Stored Procedures / Functions List Comments HSQLDB supports the following data types: INTEGER TIME BIGINT DOUBLE [PRECISION] TIMESTAMP REAL VARCHAR DECIMAL BINARY VARCHAR_IGNORECASE NUMERIC VARBINARY CHARACTER BIT LONGVARBINARY LONGVARCHAR TINYINT OBJECT DATE SMALLINT Senior Design May06-04 C-1

D: Prototype Testing Form Beginning on the following page is an example of the testing forms, created by Phase I, to be used by the client and faculty advisors when evaluation the software. The client and advisor will perform the tests listed and rate the success of the program. The development team will use the feedback from these tests to improve the quality of the software. The forms will be useful for removing software bugs, interface inconsistencies, and any other concern the testers have with the software. Senior Design May06-04 D-1

Senior Design May06-04 D-2

Senior Design May06-04 D-3

Senior Design May06-04 D-4

Senior Design May06-04 D-5

Senior Design May06-04 D-6

Senior Design May06-04 D-7

Senior Design May06-04 D-8

Senior Design May06-04 D-9

Senior Design May06-04 D-10

Senior Design May06-04 D-11

Senior Design May06-04 D-12

E: Data Dictionary The following pages contain a data dictionary, as of 11/10/05, composed of all the key variables represented in the Collection Inventory Software classes. The first column contains the class where the variable appears, the second column defines the variable type, the third column gives the name of the variable, and the fourth column defines the purpose of the variable. The dictionary will be continually modified as the progress progresses. Class Variable Type Variable Name Definition -------------------------------------------------------------------------------------------------------------------------------------- CollectionTable JLabel blank - label for new subcollections CollectionTable boolean issubtable - subtable of another table CollectionTable int[] x - right side of cell CollectionTable int[] y - bottom side of cell CollectionTable Hashtable subtables - subcollection tables CollectionTable Hashtable scrollpanes - subcollection tables in scrollpanes HierarchialCollectionTable TableSorter sorter - collection table sorter HierarchialCollectionTable HierarchicalCollectionTable parenttable - parent of table HierarchialCollectionTable Point point - last point checked by row/column-atpoint HierarchialCollectionTable int[] pointcache - cached row and column at point HierarchialCollectionTable CollectionTableModel collectionmodel - collection table model backing this table HierarchialCollectionTable TableSorter sorter - table sorter of the collection HierarchialCollectionTable int standardrowheight - row height for non-subcollection rows CollectionTableModel DatabaseTableModel dbmodel - database table CollectionTableModel ArrayList databaserows - database row corresponding to row in GUI CollectionTableModel Hashtable subcollections - subcollections CollectionTableModel Hashtable rows - database indicies(key) to table row(value) CollectionTableModel int viewrowcount - number of rows CollectionTableModel ArrayList isexpanded - track if row in database model is expanded CollectionTableModel String subcollectiontablename - name of subcollection table DatabaseTableModel Vector datavector - data in the table (vector of vectors) DatabaseTableModel Connection database - connection to database DatabaseTableModel Query query - query that produced table DatabaseTableModel int superprimarykey - primary key of refering collection DatabaseTableModel int indexcolumn - column containing index of table DatabaseTableModel int foreignkeycolumn - contains foreign key of subcollection DatabaseTableModel HashMap modifiedcells - stores modified cells of each row DatabaseTableModel HashMap columns - column values for each attribute in table DatabaseTableModel HashMap rows - row values for each table index DatabaseTableModel CollectionFile collection - the collection file DatabaseTableModel int expandcolumn - the expand column of this super collection ResultSetTableModel Vector columnnames - names for each column Senior Design May06-04 E-1

ResultSetTableModel Vector columntypes - type of each column ResultSetTableModel CollectionFile collection - the collection file ResultSetTableModel String query - query that produced the table ResultSetTableModel String tablename - name of database table being displayed ResultSetTableModel Vector datavector - data in the table (vector of vectors) ResultSetTableModel Connection database - connection to the database ResultSetTableModel int indexcolumn - column containing index of the table ResultSetTableModel HashMap rows - row values for each table index SimpleDatabaseTable Connection connection - connection to database SimpleDatabaseTable Vector rows - Vector of columns storing the table data SimpleDatabaseTable Vector columnnames - String names for the columns of the table CategoricalListRenderer DatabaseTableModel model - the database storing the possible values of the categorical list CategoricalListEditor DatabaseTableModel model - database table corresponding to the values the categorical list can take CategoricalListEditor Class columnclass - class of the column in the table CategoricalListEditor JComboBox combobox - combo box used as the editor of the categorical list CollectionInventorySystem JButton searchbutton - search button for main panel CollectionInventorySystem JButton jbuttonsearch - button to hold the search icon in toolbar CollectionInventorySystem JMenu FileMenu - file menu for main application CollectionInventorySystem JMenu EditMenu - edit menu for main application CollectionInventorySystem Jmenu ToolsMenu - tool menu for main application CollectionInventorySystem CollectionFile collection - main collection file CollectionInventorySystem JSplitPane tabledetailssplitpane - vertical split pane dividing table and detail panels CollectionInventorySystem JPanel detailpanel - lower-right details panel CollectionInventorySystem TablePanel tablepanel - upper-right table panel DatabaseDebugWindow JPanel panel - main panel in frame of Debug Window DatabaseDebugWindow SimpleDatabaseTable table - gets filled with the information recieved from database DatabaseDebugWindow JPanel querypanel - contains the query box, button, and cancel button JDialogAboutCIS JLabel jlabelauthors - contains list of authors for application JDialogAboutCIS JLabel jlabelaboutversion - contains the version number of application JDialogAboutCIS JLabel jlabelaboutname - contains name of application JDialogAddAttribute Attribute attribute - Attribute currently adding JDialogAddAttribute JLabel jlabeldesc - label for the attribute description JDialogAddAttribute JComboBox jcomboboxtype - combo box listing the existing data types JDialogAddAttribute JLabel jlabeltype - label for the attribute type JDialogAddAttribute boolean addclicked - did the user click add SearchWindow JPanel querypanel - Panel contains the JTextField: searchfield SearchWindow JPanel toppanelowleftpane - Container to hold REFINE, CLEAR buttons Senior Design May06-04 E-2

SearchWindow JPanel previouspane - Container to hold PREVIOUS search button SearchWindow JPanel bottomleftpane - Container to hold PRINT and EXPORT buttons SearchWindow JPanel middlepane - Middle pane search results SearchWindow Query query - The query to submit to the database SearchWindow JComboBox attributecombobox - Holds drop down attribute listings SearchWindow JComboBox categoricalsearchcombobox - Combo box to hold drop down categories SearchWindow HierarchicalCollectionTable tableresults - Table to hold the results of the search SearchWindow JTextField searchfield - Text field to hold the search term SearchWindow JButton REFINE - Button to control the refine method SearchWindow JButton CLEAR - Button to control the clear search method SearchWindow JButton PRINT - Button to control the print method SearchWindow JButton EXPORT - Button to control the export method SearchWindow JButton SEARCH - Button to control the search method SearchWindow JButton PREVIOUS - Button to control the previous search SearchWindow boolean state - Boolean value used to disable and enable search window buttons as necessary SearchWindow String searchstring - Current string to use in query SearchWindow String tempsearchstring - Holds searchstring for previous searches SearchWindow Attribute attribute - Current attribute to use in query SearchWindow Attribute tempattribute - Attribute to use for previous searches Senior Design May06-04 E-3

F: Current Class Structures The following appendix contains the existing class structures developed my Collection Inventory Software Phase I. These class structures form the basis of the continuation of our project and bringing this software to completion. They will be modified as development continues, but their general structures will be the groundwork for Phase II coding. Diagrams are displayed below, separated by package structure. components.table.model Senior Design May06-04 F-1

components.table Senior Design May06-04 F-2

components.table.header components.table.ui Senior Design May06-04 F-3

logic Senior Design May06-04 F-4

logic.managers logic.templates logic.exporter Senior Design May06-04 F-5

userinterface Senior Design May06-04 F-6

userinterface.newcollectionwizard Senior Design May06-04 F-7

userinterface.import userinterface.searchwindow userinterface.print Senior Design May06-04 F-8