T7 Object Finder

From SoftwarePractice.org

Contents 1 Team Members 2 Project Logbook 3 Introduction 3.1 Objective 4 Inception 4.1 System Specification 4.2 Planning for Phases of the MUP 4.3 Key System Elements 4.4 Stakeholders of System 4.4.1 Indirect Stakeholders 4.4.2 Direct Stakeholders 4.5 Project Risks 5 Elaboration 5.1 Usage Scenarios 5.2 Use Case Diagram 5.3 Use Cases 5.4 Initial Class Diagram 5.5 CRC Cards 5.6 Initial Sequence Diagram 5.7 Design of User Interface 5.7.1 Overview of Initial Proposed User Interface 5.7.2 Initial Proposed User Interface 5.7.3 Analysis of Initial Proposed User Interface 6 Construction 6.1 Final Class Diagram 6.2 Final Sequence Diagrams 6.3 Final User Interface 6.4 Unit Test Cases 7 Transition 7.1 Implementation Issues 7.2 Code Contribution 7.3 Demonstration of Program Prototype 8 References

Team Members

Daniel So XXXXXXXX
Daniel's Logbook

Jimmy Tang 10306722
Jimmy's Logbook

Anna Tang 10063725
Anna's Logbook

Project Logbook

The Team Log section shall be documented by the Project Manager (PM) every Tuesday night on the progress of the team and project.

Team Log

Introduction

This project focuses on developing a technology known as the RFID (Radio Frequency Identification) Tagged Object Finder. The purpose of the RFID object finder technology is to help people locate objects which are tagged with the RFID. The tagged object finder will have a hardware mobile tracking device that allows end-users to read data from any RFID tagged objects.

Objective

The aim of this project will be to design an application so that it can be implemented on the mobile device to read nearby RFID tagged objects. Another important part of this project is to analyse and design user interfaces and maintain good design practices and document all of these procedures.

Inception

System Specification

• The tagged object finder can read and find object(s) within a radius of 10 metres.
• The object finder is able to find any nearby objects when the user selects that function.
• A map is displayed on screen showing all nearby objects found.
• The distance between tagged object and hand-held mobile device is calculated and displayed on map.
• Tagged object(s) can be selected on screen and interrogated for more information and displayed on screen.
• The tagged object(s) can be edited, added or deleted from database stored in mobile device.
• Tagged object(s)' location is updated with current reading if tagged object already exists in the store.
• Tagged object(s) that are stored can be browsed.

Planning for Phases of the MUP

This section defines the team's project planning for the the different phases of the Miniature Unified Process (MUP). Each of these phase will be analysed and documented further below in this document or article. Please visit Team Log page for a more detailed planning of the MUP.

Here is a Gantt chart showing the phases of the MUP for managing this project:

Key System Elements

The key system element of the tagged RFID object finder will include:

• The end-user
• The RFID mobile tracking device
• The RFID tagged object(s)
• A server that all RFID tags are linked to
• The server will contain a database of all tagged objects with an identification
• Software/System/Application that locates the tagged objects
  • Graphical User Interface
  • Java Program
  • Database of stored tagged objects (include location information)

Stakeholders of System

Indirect Stakeholders

Supermarkets/Department stores/Store owners/Warehouse

• Corporate or businesses that require such technology for controlling their inventory for inventory management purposes
• Keeping track of a large amount of items

General Public

• Ordinary people who require such technology to locate small to larger objects

Household

• Ordinary people for daily use of finding missing or misplaced items in the house
• Items could be small objects like a set of keys

Pet Owners

• People who owns a pet and would like to track their pets if they go missing.
• Household with pets would highly benefit
• RSPCA would highly benefit

Office

• People working in the office for finding misplaced important documents or items.
• Missing important paper files can be tagged

Direct Stakeholders

Investors

• People who invest into the design and development of the technology
• Cheap to produce

Engineers and Designers

• Professionals who design the code, implement the system and assure quality of the technology
• Trained and qualified skilled personnel that knows the requirements well to meet the needs
• Produce quality documentation and easy to read user guide manual and instructions

Manufacturers

• Mass production of this technology
• Enough resources to build
• Understand the requirements and given instructions from engineers

Technicians

• Trained associates who know the system well
• They install, upgrade and maintain the system
• They also demonstrate the use of the technology to end-users or customers who rely on this technology

Project Risks

Downtime
Any Downtime (ie, the system failing/not working for any amount of time) can result in the theft of tagged items. Listed below are several possible causes of downtime and ways to minimise each risk:

• Power
  Power is essential to any modern electrical/electronic computer system. In the Tag Finder system there are 2 things that require power.
  • The Tag Finder: If the Tag Finder does not have power it will be impossible to locate any tagged items thus defeating the purpose of having a Tag Finder.
    Risk Minimisation
    Have a Battery Indicator that tells you when the battery is almost out. When the battery is almost out, take it to a charging point to charge it.
    
    
  • The Tags: The Tags we are using are Active Frequency Tags. What this means is that the tags are equipped with a battery which allows it to broadcast its location. If the battery runs out it will be unable to broadcast its location and thus the item cannot be brought up on the Tag Finder and will be marked as 'lost'.
    Risk Minimisation
    On the Tag have a timer that counts down a from when a fresh battery is installed, after the timer ticks over, have the tag broadcast out a warning indicator that it needs its battery changed.

• Breach of Data Security
  The data inside the Tags and the Tag Finder can be breached and changed by Hackers or when correct usage protocols are not observed.
  Risk Minimisation
  By implementing security protocols such as requiring log-ins before any vital information can be changed can minimise this problem.

Elaboration

Usage Scenarios

1. Searching for tagged objects

A foreman of a huge stationary warehouse has misplaced a number of boxes of Post-it stationary goods and would like to know where it is located within the warehouse. The foreman takes out his RFID mobile device, logs into tracking system and browse for tagged goods. He inputs the item number to see if the item numbers for the Post-it goods are tagged. However no item number is returned on screen of the Post-it goods. The foreman realises that the RFID can only pick up tagged items within a radius of 10 metres only. So he selects the search all command and is able to view a list of nearby RFID tagged goods and moves around the warehouse to locate the Post-It.

2. Adding and deleting tagged objects

Mambo has a set of keys he just tagged with RFIDs. He wants to store his RFID tagged keys into his tracking system's database. He locates the tagged keys on the map and selects to store the keys' information as well as storing the RFID identifier and original distance. Along with the storing option, Mambo can add description of the keys to the data store. Mambo use to have an old set of keys he noticed still floating in the database when he views all, he removes that from the data-store to clean up a bit. Mambo then updates his map and it will refresh the map so that the keys' location will appear and can be viewed. The location (the distance in co-ordinates) is seen to update every 1 second to 3 seconds.

3. Searching for particular items, viewing and modifying

Lillian would like to search for the misplaced remote TV control, but she can't seem to find it anywhere on the map. She wasn't sure if she stored the remote control into the database so she attempts to search the item by typing in 'remote control' into the keyword field in the search option. There were two results that appeared from the database and she selects the first result and it happened to be the one so she investigated further when she last viewed the information for that item. She found out what the RFID identifier was for the remote control and quickly locates the control within seconds as she moves around the house. Once the remote control was found she entered in where the control was last found in the modify selection then stores it in for future reference.

Use Case Diagram

Use Cases

Initial Class Diagram

CRC Cards

Initial Sequence Diagram

Searching for tagged items

Design of User Interface

Overview of Initial Proposed User Interface

The Initial Proposed User Interface was designed to be installed on a mobile tracking device. Our group all agreed that the device fit the following criteria:

• The Tracking Device must be able to run java programs, hence, run the software of which we are programming.

• The Tracking Device must have a large touch screen that will allow users to interact with the items/icons/information displayed on the screen with ease.

• The Tracking Device must be able to pick up RFID tags and connect to a wireless server to check/swap information.

Looking at the above criteria, it was agreed that the most suitable device was one that was very readily available and easily customisable:

A Palm Pilot.

Initial Proposed User Interface

Analysis of Initial Proposed User Interface

The first and most central design goal of the IPUI was to make the interface as user-friendly as possible. One way of doing this was by installing a quick interface tutorial (screen not shown) which the user is given the option of loading after they have signed onto the system. The tutorial is specific to the type of user, ie: customer, staff, administrative staff.

The second design goal of the IPUI was making it a fast and effective system. This goal was achieved by minimizing the number of screens in which the user must go through in order to complete a task. By grouping a specific function for each particular screen, as can be seen in the above list of IPUIs, the user of the Tracker should be able to search, locate and buy each item fairly quickly.

The third and final design goal of the IPUI was the way information is displayed on the screen. It can be noted that the screen of a Palm Pilot can be fairly small therefore icons must be big. Pictures are used instead of words as they take up less space (eg, the Magnifying Glass symbolising the "Search" function). Also only the most important information are displayed on the Information screen eg, picture of the item searched for, price, short description, etc.

Construction

Final Class Diagram

Final Sequence Diagrams

Storing tagged items

Deleting tagged items

Viewing tagged items

Searching tagged items

Final User Interface

The Final Proposed Graphical User Interface is radically different to what we had planned to create. This was due to a number of factors that will be explained in greater detail in Implementation Issues. Due to these factors, the Final GUI needed to be dramatically cut down by taking out various functions that were considered 'too fancy' or 'too technical' to be implement efficiently.

For this reason the Final GUI contains only the following Functions (Labelled Above):
1. A Half Working Map/Tracking Screen
2. Half Working Tags
3,4,5. Add, Delete, Modify Tag Functions
6. A scaled down version of our 'Scan Screen' (See Below)
7. A Working Co-Ordinate System
8. A List of Favourites/Already Stored Tags

XML Stored Tags
One very distinguishing feature of our RFID Tracker program is its ability to store Tags in an XML Format. It was one aspect that we worked very hard to get working in order to simulate that the tags were 'there' and that previously found tags are still saved onto the system instead of disappearing when switches off the RFID Tracker.

Unit Test Cases

Search a tagged item in the list and display information about it

Test Case	Event	Input	Expected	Description	Pass/Fail
1	Click ‘search’ button	Action by user	Option Input Panel appear	Normal case actionPerformed	Pass
2	Key in word to search for item name	String text actioned by user	Text is displayed in Option Input Panel field	Normal case Key pressed	Pass
3	Click ‘ok’ in Option Input Panel	Mouse click on button by user	The item name in the list will be compared to the search input text and be highlighted in the JList and displays all information about the tag in the Info Panel	The input text for the search Option Input Panel should match the item name listed in JList for this test case to execute correctly. Everything about the item will be displayed though the vector saved in an XML file	Pass

View/Edit information about stored tagged object

Test Case	Event	Input	Expected	Description	Pass/Fail
1	Click on an item name in JList panel	Action by user	Item name is highlighted and information about the tagged previously stored by user will appear in Info Panel	actionPerformed and valueChanged triggers	Pass
2	Mouse click on text fields of information of the tag in Info Panel	String text in any more information or change information about the tagged item	Information about the the item is removed and cannot be seen in text field	...	Pass
3	Click on 'store' to edit changed information about the item	Action by user	Once stored the edited information will be re-stored in a vector (same position) and saved in XML file. The edited information can be viewed again	actionPerformed. This test case partially passes because the prototype does not overwrites and saves into the XML file correctly	Partial Pass

Store tagged object to data store

Test Case	Event	Input	Expected	Description	Pass/Fail
1	Click anywhere on the 'map' to assign a co-ordinate to the tag	Action by User	Co-Ordinates X are filled with selection, Co-Ordinates Y are filled with selection	Co-Ordinates should be saved onto the Tag. Editing of these co-ordinates are not allowed. Tags must contain Co-Ordinates X and Y before continuing. If Co-Ordinates are blank, display Prompt	Pass
2	Input Name in the form box	Action by user	Form box displays what the user has typed in	...	Pass
3	Input Description in the form box	Action by user	Form box displays what the user has typed in	...	Pass
4	Click on the ‘Store’ button	Action by User	Whatever that has been typed into the Name form box will be added onto the Stored Panel on the right hand side.	Tag ID, Co-ordinates, Name and description are stored in the Vector and saved onto the XML file.`	Pass

Delete tagged object from data store

Test Case	Event	Input	Expected	Description	Pass/Fail
1	Select Item from the Stored Panel	Action by user	Stored Panel will highlight item selected.	...	Pass
2	Select Delete	Action by user	Highlighted item from stored panel will be removed	Previously highlighted Item is removed from the Vector. Deleted Data is removed from the XML	Pass

Transition

Implementation Issues

Every project is not without its issues encountered along the way during its production process. Here in this section we attempt to address all the major issues may have hindered our progress or are preventing us from bringing this project to its total completion. This section is broken down into the following 3 sub-sections:

- Problems Encountered
- What has been Implemented?
- What is yet to be implemented?
- Improvements that can be made current program

• Problems encountered
  This section describes all the major problems encounted during the project from the Initial Inception stage all the way to Final Transition stage.
  • Unmapped Class Diagram and Unsure of Methods
    Our group had unknowingly skipped the most important step to designing any program: DESIGNING and KNOWING all our proper class diagrams and methods. We only had a rough idea of how the program was INTENDED to work. We knew what each of the buttons on the screen did but did not know HOW they worked. This resulted in us designing a GUI and basing our code off that instead of building our GUI with the PLANNED out code.
  • A Complex GUI
    We began with a rather complicated GUI. We intended it to have motion graphics, slide-in/slide-out panels, log-ins etc. Had we have known just how complex our system really was and how limited our skills really were (not to mention the fact that we did not even know what classes and methods to use for our program). We tried to implement too many functions before we got the basic GUI running. In the end we realised (a little too late) that we had to dramatically scale down our program's functions in order to be able to make a working program from scratch, working without a class diagram or methods.
  • A Missing Team Member
    A more uncontrollable factor which was in our project. The missing team member, Daniel So, had caused more stress than anticipated. We did not foresee Daniel leaving the team and therefore we were quite unprepared when he all of a sudden left the group without earlier notifying the other team members. It strained the human resources of the other two team members. The extra amount of work and coding which Daniel So had not even started on had placed a strain on the team making them work harder to get each part of the system implemented.
  • Technical Knowledge
    Developing a program of such a vast scale (considering the complexity of the GUI) required a broad Technical Knowledge base. This is also another factor that we did not consider. The methods that need to be called and functions that need to be built were very complex and required extensive research on our part in order to implement properly. We severely underestimated our skills as programmers and struggled a bit in order to come up with the required bits of code that gets our program working.

• What has been Implemented?
  The current version of Team 7's RFID Program is 0.9. This indicates that it is not yet a completed product. Our team of two managed to implement enough code to get the following working:
  • A VERY basic GUI
  • The Tracking Co-ordinates
  • Half working Map
  • Half Functioning Tags
  • Tags that can be stored into an array AKA Add Function
  • Tags that can be recalled from the array
  • The list of 'Favourite' Tags can be saved into a file and viewed later
  • Tags that can be deleted from the array AKA Delete Function
  • Tags that can be searched from list of Tags

• What is yet to be Implemented?
  A great portion of the functions described in the Initial GUI (see above) had to be dropped or scaled down due to the 3 main issues just mentioned. This is a list of the functions that we were not able to implement:
  • Login
    This was supposed to be a simple UserID and Password check by cross referencing a list with corresponding UserID and Passwords.
  • On-Screen Keyboard
    The On-Screen keyboard was dropped from the early development stages when we did not know how to implement a sliding/moving keyboard listener function.
  • Battery Indicator
    The Battery Indicator was also dropped early from the development stages. The battery usage was supposed to be a simulated count of the number of times the user "presses" on the screen. Once this count is exceeded, the battery would be 'drained'. Another way the Battery Indicator function was was going to be implemented was to have a counter which times the duration in which the application is 'turned on'. When this duration is exceeded, the battery is considered 'drained'.
  • Information Screen & Buy Screen
    The Information Screen was dropped after we realised Daniel was not going to participate in the team anymore. We settled with a reduced version of the Search/Scan Screen instead.

• Improvements that can be made on the current program?
  This section we discuss the possible improvements that could be implemented if the project was offered an extension of a week or two. Please note that these are only minor improvements and if provided with an even larger time frame and better resources, the full program would be possible to produce. The following list of functions will be implemented from least complex to most complex.
  • Battery Indicator
    The Battery Indicator would be a simple function to implement as is it just a simulation of the expected Battery Life. The construction of a simple timer would work nicely to tell the user how much battery he/she has left on their hardware.
  • Information Screen
    The Information screen can also be implemented quite easily as a part of our existing GUI. It is a simple matter of adding extra fields to the 'data form' that is at the bottom left of the existing GUI. These extra fields being a picture of the Tagged item, a barcode (if the existing item has one), amount of the same item with the same tag, a blurb that is a description of what exactly the tagged item is.
  • Login and Passwords
    The Logins and Passwords is not as simple to build as was described earlier in the 'What is yet to be Implemented?' section. This function will be hard to implement simply because there will be alot of error checking and data checking and security checking to be tied into the program itself so that only the authorised users get to edit the data inside the tags.
  • On-Screen Keyboard
    An on-screen keyboard that slides on and off the screen so that the user can use it to input data instead of having to 'type' it in is something that will require extensive research before it can be implemented. As of yet, neither team members have any idea as to how such a state (sliding the keyboard 'off-screen' so as to make it 'invisible') can be achieved.
  • Buy Screen
    Perhaps the hardest of all functions to implement. Although the function itself sounds very simple build, it isn't necessarily as easy as deleting the tagged item off the database. One example is, the Tagged item that is currently 'owned' by us must be 'de-tagged' and have its 'ownership' 'transferred' to the new owner. This will prevent theft of items and will clear the Tag to leave the system in a clean and clear-cut fashion without the need to classify the 'tagged' item as 'stolen'.

Code Contribution

50% equal contribution

Anna

• MainGUI class
• MapPanel class
• Controller class
• Main class

Jimmy

• Tag class
• TagArray class

Demonstration of Program Prototype

• Delivered the prototype on 1/11/07
• Post the program on UTSonline Digital Drop box
• Finalise documentation by 8/11/07

References

Deitel & Deitel, "How to program - Introducing C++ and Java Third Edition", Prentice Hall 2001

Horstmann, Cay, "Big Java", Wiley 2002

Schildt, Herbert, "The Complete Reference - Java 2 Fifth Edition", McGraw Hill 2002

Wu, Thomas, "An Introduction to Object-Oriented Programming with Java Third Edition Update", McGraw Hill 2002