G52GRP Interim Group Report

moodusroundoΛογισμικό & κατασκευή λογ/κού

15 Αυγ 2012 (πριν από 4 χρόνια και 11 μήνες)

373 εμφανίσεις





G
ROUP
ID:

GP
09
-
CMG


04/12/09

G52GRP Interim Group
Report

RFID Application Development Suite

Matthew Anthony Constant Albers (maa08u), Nicholas
Guillermo Holliday

(ngh08u)
, Cai Qiuzhen

(qxc09u)
, Gil Sassoon

(gxs08u)

and Ho Dac Dung Viet

(dvh09u)

S
U P E R V I S O R
:

P
R O F
.

C
H R I S
G
R E E N H A L G H

-

2
-


Table of Contents

PROJECT DESCRIPTION

................................
................................
................................
..........................

-

3
-

BACKGROUND INFORMATI
ON AND RESEARCH

................................
................................
.....................

-

4
-

RFID

B
ACKGROUND
I
NFORMATION

................................
................................
................................
................

-

4

-

Current Uses

................................
................................
................................
................................
.......

-

4
-

Existing RFID Software

................................
................................
................................
.......................

-

5
-

F
I
LE
F
ORMATS

................................
................................
................................
................................
.............

-

6

-

P
HIDGETS
H
ARDWARE

................................
................................
................................
................................
..

-

6

-

M
ETHODOLOGIES

................................
................................
................................
................................
........

-

7

-

XP (Extreme Programming)

................................
................................
................................
...............

-

7
-

RAD (Rapid Application Development)

................................
................................
.............................

-

7
-

REQUIREMENTS SPECIFI
CATION

................................
................................
................................
............

-

8
-

F
UNCTIONAL
R
EQUIREMENTS

................................
................................
................................
........................

-

8

-

N
ON
-
FUNCTIONAL
R
EQUIREMENTS

................................
................................
................................
.................

-

9

-

INITIAL DESIGN

................................
................................
................................
................................
...

-

10
-

A
DOPTED
M
ETHODOLOGY

................................
................................
................................
..........................

-

10

-

GUI

D
ESIGNS
(D
RAFT AND
F
INAL
)

................................
................................
................................
................

-

10

-

Authoring Tool

................................
................................
................................
................................
.

-

10
-

Simulator

................................
................................
................................
................................
..........

-

13
-

KEY IMPLEMENTATION D
ECISIONS

................................
................................
................................
.........

14

U
SE OF
J
AVA

................................
................................
................................
................................
.................

14

U
SE OF
XML

AS A
F
ILE
F
ORMAT

................................
................................
................................
.......................

14

D
RAG AND
D
ROP USAGE

................................
................................
................................
................................
.

14

Z
IPPING OF
F
ILES

................................
................................
................................
................................
...........

14

F
OCUS ON A PARTICULAR

K
EY
U
SE

................................
................................
................................
....................

14

PROTOTYPING
................................
................................
................................
................................
.........

16

A
UTHORING
T
OOL

................................
................................
................................
................................
.........

16

XML Coding

................................
................................
................................
................................
..........

16

Actual Authoring Tool Coding

................................
................................
................................
..............

17

R
UNTIME
P
LAYER

................................
................................
................................
................................
..........

17

S
IMULATOR

................................
................................
................................
................................
..................

17

PROBLEMS ENCOUNTERED

................................
................................
................................
.....................

18

W
RITING
XML

................................
................................
................................
................................
..............

18

L
IMITATIONS OF
F
ILE
Z
IPPING

................................
................................
................................
..........................

18

J
AVA
C
OMPATIBILITY FOR
V
IDEO
F
ILES

................................
................................
................................
..............

18

TIME PLAN

................................
................................
................................
................................
..............

19

APPENDIX

................................
................................
................................
................................
...............

21

M
SCAPE
I
N
-
D
EPTH
R
ESEARCH

................................
................................
................................
.........................

21

G
ANT
T
C
HARTS

................................
................................
................................
................................
.............

25

M
INUTES
1

................................
................................
................................
................................
...................

27

M
INUTES
2

................................
................................
................................
................................
...................

27

M
INUTES
3

................................
................................
................................
................................
...................

28

M
INUTES
4

................................
................................
................................
................................
...................

29

M
INUTES
5

................................
................................
................................
................................
...................

30

M
INUTES
6

................................
................................
................................
................................
...................

30

M
INUTES
7

................................
................................
................................
................................
...................

31

-

3
-

Project Description


Radio
-
Frequency Identification (RFID) is the use of an object (typically referred to as an RFID tag)
applied to or incorporated into a product, animal, or person for the purpose of identification and
tracking using radio waves. Each RFID tag contains a uni
que code number (in this case, a string
consisting of 10 characters) which can be read by a nearby reader. If the tag is attached to,
embedded in or carried by this object then whenever a known reader observes a particular tag it
implies that the associate
d object is at the location of the reader. RFID technology is currently being
used in various applications including stock control, access control and interactive installations. It is
even being used in passports, animal identification and human implants.
It is functionally similar to
other "tagging" or labelling technologies such as 1
-
D and 2
-
D barcodes.


The aim of this project is to design an efficient RFID Application Development Suite. This entails
designing a file format that can be used to specify si
mple behaviours of RFID tags, readers and linked
devices (such as the presentation of content “linked” to a tagged physical object when it is placed on
a reader, which could be a picture, text, video file etc.), and to design, implement and evaluate three
linked applications based on this file format. All three should be usable by a non
-
programmer (such
as a graphic designer or a museum curator). They are:

1.

An authoring tool (a program that helps you write
hypertext

or
multimedia

applications) for
creating b
ehaviours files.

2.

A simulator which “plays” these files in an interactive simulated environment, independent
from the actual RFID hardware and linked devices.

3.

A runtime player which “plays” these files relying on the use of the actual RFID hardware
and link
ed devices.


Optional additions that could be included, in either the developing process of the prototype or
at a later date, are:



Support for more sophisticated behaviours, such as multi
-
tag interactions, sequences and
time dependence.



Generalisation to
other tagging and sensing technologies.



Links to formal modelling and verification tools and approaches.



An application to review and analyse logs of actual use.



Links to other display and interaction technologies, such as Flash.


In order to produce a mor
e efficient and effective suite, there will be a focus on a particular area
(such as stock control for retail franchises) in which the suite could be used. This key area is
interactive exhibits in national and local museums. The suite could help the museum
s introduce
interactivity into various exhibits a lot easier and in doing so, make the exhibits more fun and
interesting for those visiting the museum. For example, every time a tag is scanned over a reader a
piece of text, picture or video clip focused on

a particular topic (such as a dinosaur fossil) could be
displayed onscreen for the user.


-

4
-

Background Information and Research


This section consists of all the necessary research that was carried out in order to progress with
the project.


RFID Backgroun
d Information

Radio
-
frequency identification

(
RFID
) is the use of an object (
usually

referred to as an RFID tag)
applied to or incorporated into a product, animal, or person for the purpose of identification and
tracking using radio waves. Some tags can be read from several meters away and beyond the line of
sight of the reader.

Most RFID

tags contain at least two parts. One is an integrated circuit for storing and processing
information, modulating and demodulating a radio
-
frequency (RF) signal, and

any

other functions

specified by the creator of the program for the RFID tag
. The second i
s an antenna for receiving and
transmitting the signal.

There are generally three types of RFID tags:
active

RFID tags, which contain a battery and can
transmit signals autonomously,
passive
RFID tags

(the ones that we are using for this project)
, which
ha
ve no battery and require an external source to provoke signal transmission and
battery assisted
passive (BAP)

which require an external source to wake up but have significant higher forward link
capability providing great read range.

Current Uses

RFID and

Asset Management:

RFID (Radio Frequency Identification) combined with mobile
computing and Web technologies provide a way for organizations to i
dentify and manage their
assets
. Mobile computers, with integrated RFID readers, can now deliver a complete set

of tools that
eliminate paperwork, give proof of identification and attendance.

M
anual data entry
is eliminated
via this approach
. Web based management tools allow organizations to monitor their assets and
make management decisions from anywhere in the w
orld. Web based applications now mean that
third parties, such as manufacturers and contractors can be granted access to update asset data,
including for example, inspection history and transfer documentation online ensuring that the end
user always has ac
curate, real
-
time data
.

Product Tracking:
High
-
frequency RFID or HFID/HighFID tags are used in library book or
bookstore tracking, jewellery tracking, pallet tracking, building access control, airline baggage
tracking, and apparel and pharmaceutical items
tracking. High
-
frequency tags are widely used in
identification badges, replacing earlier magnetic stripe cards. These badges need only be held within
a certain distance of the reader to authenticate the holder.

Also,
UHF, Ultra
-
HighFID or UHFID tags
are c
ommonly used commercially in case, pallet, and shipping container tracking, and truck and
trailer tracking in shipping yards.

Biometric Passports:
In 2006, RFID tags we
re included in new US passports
. The chips inlays
store the same information that is pri
nted within the passport and include a digital picture of the
owner. The US State Department implement
s

Basic Access Control (BAC), which functions as a
Personal Identification Number (PIN) in the form of characters printed on the passport data page.
Befor
e a passport's tag can be read, this PIN must be entered into an RFID reader. The BAC also
enables the encryption of any communication be
tween the chip and interrogator.

-

5
-

Also, RFID has a lot of other potential uses in which it can be used in a variety of a
pplication such
as:



Access management

-

the regulation of interchanges, intersections, driveways and median
openings to a roadway



Tracking of goods and RFID in retail



Tracking of
human
s and animals



Toll collection and contactless payment



Machine readable
travel documents



Smart dust (for massively distributed sensor networks)



Location
-
based services



Tracking Sports memorabilia to verify authenticity



Airport Baggage Tracking Logistics



Vehicle and transport identification

Existing RFID Software

There are many

examples of RFID software present in all types of industries. What follows are a
few relevant examples including a case study of RFID technology in use in museums.


Rifidi:
Rifidi is the premier open source IDE for RFID. Rifidi allows you to develop an RF
ID system
entirely with Software Components and removes the dependency on hardware and infrastructure
that RFID typically demands. Rifidi makes it possible to 'virtualise' your infrastructure with Software
Defined RFID Readers, RFID Tags, and RFID Events t
hat behave like their real
-
life counterparts.


RFID Anywhere:
RFID Anywhere is a flexible software infrastructure that integrates business logic
and processes with a variety of automatic data collection and sensor technologies, including RFID,
barcodes, mo
bile devices, PLCs, location tracking systems, environmental sensors and feedback
mechanisms. By using RFID Anywhere, sensors are able to work together as an intelligent network by
combining, organizing and coordinating these technologies through event
-
dri
ven development
architecture.


MScape
:
Mscape is a mobile media gaming platform

developed

by Hewlett Packard that can be
used to create location
-
based games
. It is encouraged for users

to use Mscape to create not just
games, but also informational guides t
o points of interest, imaginative stories about places, and
practical information about worksites. Mscape makes a player's GPS location an element of the
game play. Events in a game are triggered by a player's location

(with the help of RFID technology)
,
a
nd the player interacts with a game by moving from place to place.

Mscape is used to create mediascapes, interactive experiences made up of video, audio, images,
and text. Mscape stores the digital media files in a structure that associates them with posit
ions
from a GPS system. Players play mediascapes on a Windows Mobile device, such as a mobile phone
or a PDA, that's GPS enabled. As players move around, the device senses their position and activates
the appropriate media files
. (See
A
ppendix

for in
-
depth research on Mscape)


Exploratorium (Museum):
The eXspot system consists of a small RFID reader package for

mounting on museum exhibits, an RF tag carried by visitors on a card

or necklace, a wireless network,
a registration kiosk, and dynamic
ally

generated Web pages. It
enables visitors to capture information
about exhibits they visit and take

souvenir p
hotographs while at the museum.
Later, they can access
the

exhibit information on personalised Web pages.

eXspot RFID readers attached to the
exhibits
allow visitors to use their RFID cards to trigger cameras to take digital images of themse
lves.
After
interacting with exhibits, visitors use their ID cards to log on to a museum kiosk and view the exhibit
photographs they’ve captured
.
They can th
en continue their exploration

either from home or at the
kiosks in the museum

by logging on to personalized Web pages through their ID card number and
email address.


-

6
-

File Formats

The file format used in RFID project must be able to record all the
behaviours associated with
the tag. Also it needs to be easy to read and modify. The file format used in RFID project should have
following properties:

1.

Should be able to record all the behaviours associated with the tag in a proper way.

2.

Should be easy to p
arse by the applications.

3.

Should be easy to access by the application. For instance, finding specific information and
change it.

4.

Should be easy to modify, such as delete a part of file or change some part of file.

5.

It will be better if it can be directly re
ad and understand by non
-
expert user.


With this is mind, it was believed that XML (Extensible Mark
-
up Language) would be able to
meet all of these properties. The research for this is as follows:


XML is a set of mark
-
up grammar which use tag set of pairs

of tag to represent specific
information. Unlike HTML, XML does not predefine any tags, so XML can be used to record any
information or data. An example of XML, it represents a recipe. The tag defines an area or a process
of the recipe and specific inform
ation is enclosed within two tags. XML is like an object in Java, which
can also be used to stand for any object in our life.


<?xml version="1.0" encoding="UTF
-
8"?>

<collection>


<description>


Some recipes used for the XML tutorial.


</description>



<recipe>


<title>
Beef Parmesan with Garlic Angel Hair Pasta
</title>


<ingredient name="beef cube steak" amount="1.5" unit="pound"/>


...



<preparation>


<step>


Preheat oven to 350 degrees F (175 degrees C).


</step>


.
..


</preparation>


<comment>


Make the meat ahead of time, and refrigerate overnight, the acid in the


tomato sauce will tenderize the meat even more. If you do this, save the


mozzarella until

the last minute.


</comment>


<nut
rition calories="1167" fat="23" carbohydrates="45" protein="32"/>



</recipe>


...

</collection>


The XML can be compatible to most of programming language. Java provides the XML package
to deal with all the XML issues such as editing and parsing. Also,
XML is illustrative and easy to
understand as it does not contain any complex grammar but the simple tags.


Phidgets Hardware

The Phidgets hardware are the reader and tags that are being used for the project. In order to
begin design and coding for the sui
te, we first had to look into how to use the hardware and how to
use it in conjunction with a programming language. This was done by having access to various
-

7
-

documentation and programming libraries (including API’s and example code of interfacing the
hardw
are) from the Phidgets website (
http://www.phidgets.com/index.php
).


Methodologies

In order to progress with the project in a more structured manner, research had to be carried
out on possible methodologies

to be adopted. We had 2 particular ones in mind: XP and RAD (Rapid
Application Development). The research for these is as follows.


XP (Extreme Programming)

The main goal of XP is to lower the cost of change in software requirements. With traditional
syst
em development methodologies, like the Waterfall Methodology, the requirements for the
system are determined and often "frozen" at the beginning of the development project. This means
that the cost of changing the requirements at a later stage in the proje
ct


something that is very
common in the real
-
world


can be very high.

There are 12 core practices that can be broken down into 4 key areas. They are
Fine Scale
Feedback
(
t
est driven development
, p
lanning game
, w
hole team
, p
air programming
),
Continuous
process rather than batch
(continuous i
ntegration
, design i
mprovement (a.k.a refactor)
, s
mall
r
eleases
),
Shared Understanding
(s
imple design
, s
ystem metaphor
, c
ollective code ownership
,
c
oding

standards or coding conventions) and
Programmer Welfare
(sustai
nable pace).

Also, there are core principles such as feedback, assuming simplicity and embracing change.
There are 4 basic activities that are performed within this software development process; coding,
testing, listening and designing. Although there are
many advantages to this methodology, there are
also some disadvantages, such as
r
equirements are expressed as automated acceptance tests rath
er
than specification documents and

are defined incrementally, rather than trying to get them all in
advance.

Also, s
oftware developers are usu
ally required to work in pairs and t
here is no Big Design
Up Front. Most of the design activity takes place on the fly and incrementally, starting with "the
simplest thing that could possibly work" and adding complexity on
ly when it's required by failing
tests.


RAD (Rapid Application Development)

This methodology
uses minimal planning in favour of rapid prototyping. The "planning" of
software developed using RAD is interleaved with writing the software itself. The lack of
extensive
pre
-
planning generally allows software to be written much faster, and makes it easier to change
requirements. All flavours of RAD have the potential for providing a good framework for faster
product development

with improved
code quality
, but suc
cessful implementation and benefits often
hinge on project type,
schedule
,
software release cycle

and
corporate culture
.

The advantage to using RAD is that it
p
romotes strong collaborative atmosphere and dynamic
gathering of requirements
. A disadvantage co
uld be that there is
Dependency on strong cohesive
teams and individual commitment to the project. Success depends on disciplined developers and
their exceptional technical skills and ability to
produce efficient work.

-

8
-

Requirements Specification


This sec
tion specifies all of the requirements for the system to be built, as agreed between the
group and supervisor.


Functional Requirements


1

The RFID tag must be able to be read by the RFID tag reader.

1.1

When tag scans over the reader, the LED light should
react.

1.2

The 10
-
character identification string of the individual tag must be recognised.


2

An authoring tool must be able to allow the user to create or open a new project where behaviours can
be associated with tags.

2.1

For each project, a file must be created

containing details of the behaviours and the associated tags.

2.1.1

Each behaviour must have a name and one or more tags associated with it.

2.1.2

Each behaviour must have information regarding the type and location of the linked media
which is to be displayed when t
he tag is scanned.

2.2

The user will be able to create new behaviours or edit behaviours which have already been created.

2.2.1

The user will be able to specify whether the behaviour is run when a single tag is scanned, a
sequence of tags are scanned (or any combina
tion of both), or when any tag is scanned.

2.2.2

The user will be able to scan the tag or enter in the tag ID number.

2.2.3

The user will be able to specify which images, videos, sound and text are to be displayed, or
what program is to be executed, or what file will
be opened in the default application.

2.3

The tool will create a ZIP file which will contain all of the relevant media and the file which contains
the behaviour and tag information.

2.3.1

The ZIP file will have a ‘.rfid’ extension so that the files created with the
authoring tool can be
distinguished from other ZIP files.


3

A simulator application must allow the user to use the files independent of the actual RFID hardware
and linked devices.

3.1

Must allow for the tag files to be loaded and be represented by a picture.

3.1.1

The picture must have the ability to be dragged around the simulator window.

3.1.2

When dragged onto and released over the tag reader picture, the file must then be played (i.e.
functionality should then be passed to the runtime player).

3.2

Must be a picture of a t
ag reader.

3.2.1


The picture must act as a link to the runtime player.


4

A runtime player must be used to “play” the behaviours of each individual file.

4.1

Must have the ability to display text.

4.2

Must have the ability to display images (of different formats).

4.3

Must h
ave the ability to play a video file (of different formats).

4.4

Must have the ability to play an audio file (of different formats).

4.5

Must have the ability to run third party programs.

4.6

Must have the ability to open files in their default application.

4.7

Must log w
hich tags are scanned and when.






-

9
-

Non
-
functional Requirements


1

An application to review and analyse logs of actual use.

1.1

Should show logs of which tags were scanned and when.

1.2

Should show logs of what behaviours were ‘run’ and when.

2

The suite must be
platform independent.

3

The suite must be dependent on other select technologies, including JVLC and JRE.

4

All applications within the suite must be able to run independently of each other.

5

The suite must be portable.

6

The suite must not use unnecessary amount
s of CPU and RAM space.

7

The suite must be accompanied with up
-
to
-
date Javadocs of the authoring tool, simulator and runtime
player applications.

8

The authoring tool must treat any file that is outside of its working directory as read only.

9

All applications
in the suite must not take an extensive length of time to “load.

10

The suite must be easily understood by users of all levels of computer literacy, including non
-
programmers.

11

All aspects of the suite should be user
-
friendly
.

-

10
-

Initial Design


This section
consists of the main design decisions made for the proposed system and its user
interface, accompanied by draft GUI designs of the applications themselves.


Adopted Methodology

The software development methodology chosen should allow for multiple programme
rs working
on different parts of the suite at the same time. It should also be adaptive, meaning that changes in
the specification should be easy to implement, as we may not know all of the requirements in the
original planning stage. A methodology like th
e waterfall model would therefore not be suitable for
our project as it would not be conducive to changes once the programming has started. There are,
however, other models we could use which would be more suitable. An example of a suitable model
would be
the Rapid Application Development methodology (RAD). RAD focuses on breaking down
the application into many smaller parts, and creating prototypes for each section. This would allow
each member of the team to focus on a section each, without the limitation
s of a methodology like
XP which insists on pair programming which would be impractical due to the differing schedules of
each member of the group. It also places less emphasis on the customer than XP which states that
the customer should always be availab
le, which will not be the case for our project. RAD also focuses
on delivery deadlines which suits our project perfectly, if the project falls behind schedule the
emphasis is put on reducing the functionality to fit the time frame as opposed to extending t
he time
frame which we cannot do for our project.

Therefore, we decided to adopt the RAD (Rapid Application Development) methodology.


GUI Designs (Draft and Final)

The first step of designing the applications was to draw some draft GUI (Graphical User
Int
erface) designs. There were several stages of design for these before we came up with a final
version. They are as follows:

Authoring Tool



Figure
1

-

The first GUI design of the Authoring Tool


-

11
-

After having had further discussio
ns regarding what the authoring tool should do, we decided to
make
Figure 1
the sub
-
menu and design a new main menu which enabled the user to view all
existing tags. It would only when adding new tags or editing the old ones that the sub
-
menu would
be give
n focus.



Figure
2

-

The second GUI design of the Authoring Tool (combined with the first: now a 2 menu application)


However, this was not our final version of the GUI for the authoring tool. After further
discussions, we came
to the conclusion that it would be best to combine all of the functionality of
the application into one simple, user
-
friendly interface, accompanied by a couple of dialog boxes to
obtain necessary information from the user at start
-
up.



Figure
3

-

The "official" 2nd draft GUI design of the Authoring Tool


-

12
-

The above draft design was very close to our final version though there were one or two parts of
it that we felt could be improved for the functionality and user
-
friend
liness for the user. The final
version of the GUI for the authoring tool can be seen below.



Figure
4

-

Final Version of the Authoring Tool (Part 1)




Figure
5

-

Final Version of the Authoring Tool (Par
t 2)







-

13
-

Simulator

This draft GUI design of the Simulator application was our first and, all things being hopeful, our
final version. The design provides all the functionality that is required of the application as well as
being user
-
friendly through eas
y
-
to
-
understand layout and sufficient interactivity.



Figure
6

-

The first and final version GUI design of the Simulator application

Key Implementation Decisions

This section consists of details on the key implementation decisions that were made in regards
to the progression of the project as a whole or an individual

area of it, such as the authoring tool or
simulator application.


Use of Java

Phidgets does support the working environment along with code libraries to C/C++ and Java.
However, we were more acquainted with Java and more confident in constructing all piec
es of
hardware and software interfacing that was believed to be needed to be able to address and debug
all code errors. Moreover, Java was found to be much easier to enhance the authoring tool and
player performance over a Java Platform such as Netbeans in

which, lots of applets and gadgets are
always ready to be embedded with vast assistance tools and resources built
-
in and online.

In comparison of Java advantages over C/C++ in software designing, in spite of the familiarity of
syntax and object oriented p
rogramming; Java represents the ability to create two different types of
programs which are applications and applets. It goes beyond the significant difference in the APIs
where it offers a wide range of application types in terms of Pure Object oriented l
anguage while
C/C++ does not. Most of these advanced features will be found missing in C/C++.


Use of XML as a File Format

We chose XML as a file format as it provides readable and easily noticeable code. It is also fully
compatible with Java. It ideally a
ccommodates for linking all display data and information over
simple multiple attributes and tags which are mostly done by self
-
creating. XML is easily extended
and performs as a well
-
organized document. It also has the ability to merge to all applications

which
mostly accept the XML publish. It also vendors the system independent while keeping any
exchanged data away from being lost even they perform in different formats.


Drag and Drop usage

To enable ease of use with our program, we came to a decision of

using the function ‘drag and
drop’. The reason for this is that our program needs to be able to be used by everyone (not just
computer science students who know a computer inside out) so it has to be user friendly and simple
when editing data.

This featur
e will be used in the authoring tool application to drag the file content
of which is to be associated as a behaviour and drop into the main pane and move into desired
position. Also, it will be used as a focus in the simulator application as the user will

have to drag a
“tag” over the “reader” in order to play the associated behaviours with the runtime player.


Zipping of Files

S
o that the XML created by the authoring tool application and the behaviours to be associated
with the tags would

take up as littl
e space as possible, we decided to zip any files generated by the
authoring tool. In doing this, it would

free up space, therefore leaving space for more information on
multiple tags

and not having an impact on the CPU and RAM capabilities of the computer
on which
the suite is being run.


Focus on a particular Key Use

When we started the project we were looking at different ways that we could go with RFID tags.
Eventually we

decided to build a project with focus to a particular theme;
Interactivity with
in
15

Museums
.
By this it is meant that visitors to the museum

can scan tags, have information displayed
about a particular exhibition
. T
he curator can use the authoring tool to create the information on
the tags, therefore, making their vis
it a lot more enjoyable and user friendly

for getting access to
further information
.

The main reason for the decision to place focus on a particular theme is that we
feel the project could be more efficient and useful if had a main “use”. Also, on the Open

Day, the
project can be presented in a more understandable manner.

Prototyping


This section consists of details on the prototyping that has been completed so far for the suite.


Authoring Tool

The prototyping of the authoring tool can be split into two m
ain sections; XML and the actual
authoring tool, including the creation of the GUI, zipping files, drag and drop usage and the merging
of it with the XML code.


XML Coding

A class XMLEditor was

created for all the interactions with an XML file that contain
s all the
behaviours. The Class mainly makes use of domj4 package and Java IO package.

Firstly, the structure of XML file format will be described. The example of file format can be seen
below:


<?xml version="1.0" encoding="UTF
-
8"?>

<root>



<behaviour

name="
behaviour1
" TagIDs="
123456|3453456456
">




<Info>TEST</Info>




<filelist>





<picture x="
3
" y="
4
" width="
30
" height="
40
">pic1.jpg</picture>





<video x="
4
" y="
5
" width="
40
" height="
66
">mymovie.mov</video>




<picture x="
4
"

y="
5
" width="
30
" height="40">pic2.jpg</picture>





<video x="
4
" y="
5
" width="
50
" height="
50
">video1.aVi</video>





<text x="
6
" y="
7
" font="
arial
" colour="
red
" style="
bold
">Here is some
text.</text>





<program>Notepad.exe</program>




</filelist>



</behaviour>




<behaviour name="behaviour2" TagIDs="5435436">




<Info>TEST2</Info>




<filelist>





<text x="10" y="6" font="arial" colour="green" style="bold">RFID
project.</text>




</filelist>



</behaviour>

</root>


T
he outermost element is “behaviour”, and it has two attributes; the name of this behaviour and
the tag IDs associated with it. As can be seen in the example, multiple tag IDs can be associated with
one behaviour, which can avoid repeating writing the same

behaviour for different tags. These tags
are split with character '|'. Inside the behaviour element there are two elements; “Info” and
“filelist”. The former one is for adding the description about this behaviour and the latter one is for
containing all t
he files associated with this behaviour. Each file has its own attributes.

Secondly, the methods in the class will be introduced. The methods can be divided into two
parts. For the first part, its purpose is editing an XML file. It contains methods that a
dd and delete
behaviours, any kind of file in specific behaviour and any tags in specific behaviour. The second part
of the method is aiming for reading or searching information in an XML file, containing methods that
list all the behaviours, getting behav
iours by tag name or behaviour name and getting the file list of a
behaviour.

17


Actual Authoring Tool Coding

One of the first prototypes to be made was the ZipFile class which would allow us to zip and
unzip files quickly and easily. The reason for this wa
s that a key element of the authoring tool would
be to package all necessary files up together so that any project could be moved without being
dependent on any other files which were not included in the zip file. The zip class makes use of the
Java.util.z
ip library and provides a few methods which would be necessary for the authoring tool.
These methods include:



countFiles method which counts the number of files in the zip file;



getFileList method which returns a list of the names of all the filenames whic
h have been
zipped up;



unZip method which unzips the specified file to the user’s temporary directory and returns
the absolute path name to the new file;



zip method which creates a new zip file containing the specified files.


At the same time a prototype
was created to see if we would be able to implement a drag and
drop interface which we thought would improve the user interface of the authoring tool


instead of
the user specifying the coordinates of an image for example, the user could just drag and dro
p the
image onto a pane and the image would appear in the same place when the appropriate tag was
scanned. We identified the java.awt.dnd library as the library which we would use and a simple
prototype was created which allowed image filenames to be dragg
ed from a JTree on to a pane, and
for the image to appear as soon as the mouse reached the pane allowing the user to place the image
where they liked.

Following this, a prototype of the GUI for the authoring tool was produced. The GUI took the
form of a wi
zard which takes the user through the process of creating or opening a project file;
creating, editing and deleting behaviours; associating tags with behaviours; and if necessary creating
what will be displayed to the user if text, an image or a movie, or
a combination of these is to be
displayed. Finally, after thoroughly testing each of the other prototypes

(zip files and drag and drop)
,
they were merged into this project which gave us our first version of the authoring tool.


Runtime Player

The prototype

for the runtime player was created by first writing and testing methods which
would allow for different types of media to be displayed on a panel. Once methods for showing text,
images, movies and sound had been produced, work started on creating methods
which would allow
for programs to be run and files to be opened in their default application. This code was then
merged with the tag reader library and the XML Editor class and the ZipFile class we had made, to
create the final first draft of the player.

N
o actual GUI for it has, as of yet, been designed.


Simulator

No prototyping has as of yet begun on the simulator application as the main focus has been on
completing a first prototype of the authoring tool and the runtime player in conjunction with it.
However, when prototyping does begin we should be able to progress at a reasonable pace as the
main features of the simulator application will have already been covered in other areas of the suite,
such as drag ‘n’ drop and the “playing” of the files. The
section of prototyping that will take the
longest is the design of the GUI for the simulator application.

18

Problems Encountered


This section consists of the main problems that were encountered throughout the duration of
the project so far.


Writing XML

There were mainly two problems that were encountered when implementing the XML editor.
The first one was what tool was to be used to create the XML editor. Java has its own tool set to deal
with XML issues, but it seemed like a substituted package could be

used. Dom4j package is designed
to handle XML issues in a
n

easier way. So that was what we did.

The second problem was what format will be used to record tag behaviours. At first, a format
which sorts all the information and splits them to different secti
ons by tag IDs was implemented.
However, an issue was been raised about this format; different tags may share the same behaviours.
When the quantity of the tags is increasing, these shared behaviours must be repeatedly expressed
in every tag section which
has these behaviours. The solution was sorting all the information
corresponding to behaviours and in each behaviour section, multiple tags could

be marked


Limitations of File Zipping

After having decided that once behaviours were created with the authori
ng tool that the files
that belonged to the behaviour would be “zipped up”, we encountered an issue related to
limitations on zipped files. By this it is meant that we realised that, based on the types of files that
were being zipped and version of ZIP bei
ng used, there is a 4GB size limitation. Seeing as some files
that will be associated with behaviours could be potentially large in size, this could clearly be an
issue. Later versions of ZIP are able to overcome this as well as other limitations (uncompre
ssed size
of a file, compressed size of a file and total size of the archive). We are currently looking into this
more.


Java Compatibility for Video Files

When implementing the authoring tool / runtime player, a problem was encountered relating to
the pla
ying of video files. In order to play video files through Java, one needs access to other
frameworks and libraries to tell Java that a particular file can be associated with it and actually be
played. When we tried to implement the Java Media Framework/Lib
raries, we found that not many
file formats could be associated as it is a fairly old framework meaning that newer formats could not
be recognised, only older ones such as .AVI. Eventually we found another framework/library that
would do a much better job;

JVLC (VLC Media Player for Java). Also, in order to provide more
compatibility for the application(s), we wanted to allow file extensions usually associated with
QuickTime to be accepted. However, when we tried to implement this it kept causing Java to cr
ash.
For the time being we have removed this from our code but are currently looking into how to solve
this issue.






19

Time Plan


This section consists of a time plan of the project, from start to finish. Although there may be
some aspects of the project

that have not been accounted for (mainly in the advanced
improvements at a later date in the project), it is fairly detailed. It covers all the key areas of the
project, including the writing up of this report and the final one, the coding of each applica
tion and
even the preparation for the Open Day and Presentation to be done in May 2010. The table of the
time plan, which is then represented by a Gantt chart (see
A
ppendix
), can be seen below. Some
periods of development are longer than they need to be du
e to other events being taken into
account, such as holidays and exam periods. Also, the time plan has been split up into 2 sections:
start to basic prototype up and running, and addition of more advanced features to open
day/presentation preparation.


Tas
ks

Start Date

Duration (Days)

End Date

Write up updated project description
for Interim Report

12/10/2009

7

19/10/2009

Carry out / write up research for
Interim Report

12/10/2009

7

19/10/2009

Requirements specification

19/10/2009

7

26/10/2009

GUI draft

designs

19/10/2009

9

28/10/2009

Authoring Tool Prototype up and
running

26/10/2009

35

30/11/2009

Basic Prototype of Runtime Player up
and running

09/11/2009

25

04/12/2009

Write up of initial design of project for
Interim Report

16/11/2009

7

23/11/2009

Write up of all main decisions made in
project for Interim Report

23/11/2009

8

01/12/2009

Write up results of initial
implementation for Interim Report

23/11/2009

8

01/12/2009

Write up of problems encountered so
far for Interim Report

23/11/2009

8

01/12/2009

Final Adjustments to Interim Group
Report

01/12/2009


3

04/12/2009

Basic Prototype of Simulator up and
running

07/12/2009


49

25/01/2010


All of the tasks above (except for the final one) have been and were completed on time
according to
their end dates.


Tasks

Start Date

Duration (Days)

End Date

Carry out testing on the basic
prototypes

25/01/2010

14

08/02/2010

Application to log use of reader and
applications

25/01/2010

10

04/02/2010

Multi
-
reader interaction capabilities

25/01/2010

21

15/02/2010

Visit a Museum for research into how to
better expand project for the main theme

01/02/2010

7

08/02/2010

Make improvements on Suite based on
findings from museum visit

08/02/2010

28

08/03/2010

Carry out testing on all aspects of the
08/03/2010

14

22/03/2010

20

Suite
(since new additions)

Update design (and user interface)
section for Final Report

08/03/2010

7

15/03/2010

Update implementation section for
Final Report

15/03/2010

7

22/03/2010

Write up testing for Final Report

22/03/2010

7

29/03/2010

Write up Summary of what was
achieved and Reflective Comments for Final
Report

15/03/2010

14

29/03/2010

Preparation for Open Day

01/04/2010

32

03/05/2010

Preparation for Presentation

01/04/2010

32

03/05/2010








21

Appendix


This appendix
consists of in
-
depth research on an existing application called Mscape, the 2 Gantt
Charts for the time plan of the project and the minutes taken in every formal meeting that has taken
place since the start of the project.


Mscape In
-
Depth Research


MScape

overview:

Having GPS traced out the location over any handheld devices which have this certain technology
embedded is basically building the essential application of navigation. It would be more ideal since
HP decided to change the way GPS was used by dev
eloping MScape that was described as a gaming
platform allowing user to build their own games, guides, maps or any portable media software
based on GPS. All applications encouraged to build on MScape prefer to the term Mediascape in
which, all simulated ev
ents are triggered by the real location of player and thus, the player will be an
element in the game as well. Apart from the player, highly rich texts, videos and images make the
whole game background; they are all encrypted to a file and ready to associa
te with a GPS system.

MScape Suite:

MScape suite provides all necessary tools for a play of imagination. It contains the followings:




MScape player (Installed on handheld devices, holds and loads all created mediascapes to run on
device)



MScape library
(Store and Organize all mediascapes on computer)



Figure
7

-

Mscape Library Feature




MScape maker (a player tool for user to create applications)


22


Figure
8

-

Mscape Maker Feature




MScape tester
(embedded in MScape maker, used for simulation testing on a specific Windows
Mobile Device)

Exploring MScape on computer:

It was suggested to focus on how the mediascape will work on the standard environment or with a
requirement of GPS. In fact, the form
is already classified applications into 2 specific types:





Anchored: All mediascapes state this form can only play with the GPS enabled.



Portable: As a normal portable application, this mediascape can be played everywhere.


i)

Experience designing an applica
tion framework:

So far a basic step to start a mediascape is to build its framework considering all concepts and
prototypes expected to be performed. These aspects is able to be alternated as soon as they are all
briefly written down for the further design
ing and followed during the design process, all the
refinement and test will be carried out accordingly to these first draft. In order to optimize the
application, four aspects were emphasized that need to think about:




Who will use this application?



Wher
e will the experience be located?



What is the content of experience?



How will it be interacted with the user?

Within each of above aspects, individual decisions of building the experience depend mostly on how
they will associate and perform under the point

of view of player. Therefore, examine all the user
cases and plan situations may happen when the context has been changed and continue decide the
boundaries for the context. According to the interaction or literally say how the player will press the
butto
n and what function that button will perform; approaches to this method can be achieved by
using an image hotspot, HTML or Flash and using physical buttons which can easily done by coding
some simple Java or C/C++ script assigning a specific function onto
correlative button. For example,
a demonstration of navigation buttons but built with different function in which each button will
23

displayed a picture or map independently while centre button hold the task of playing a demo intro
song.














For the purpose of enhancing the emulation of experience on application which is recommended
to test out in the environment on the device rather

than doing it only on the computer due to the
insufficiency.


ii)

Export the mediascape for testing:

Conquer every pieces of issues encountered during the design and had it fixed before experience
any worse bug when they are all messed up. The MScape tester also helps user to debug any error in
the design as well as the code implemented, it shows two main

panels separately where the one on
the left is simulating the experience of viewed on device while the other display the prototype
design of application and point out any error while the process running.


Another example of anchored experience mediascape

is a real action game where player in order to
play, must have a ticket going to the Tower of London along with their GPS device where they will be
updated in GPS data system and begin the game. Each authentic position of player will be
continuously updat
ed through the GPS and appeared as an role in the game unless they are out of
the Tower.

Dedicate function for Right Button

Dedicate function for Left Button

Dedicate
function for Centre Button

24























What’s behind the platform?

The
general idea of MScape came up with the research of augmented reality when it first innovated
from the initial interaction of human and computer. Two other computational terms also used to
describe what MScape performing related to Ubiquitous computing and

context
-
aware pervasive
system. But essentially, it should have been mentioned of simpler technology that mostly defined by
hardware such as portable computing. In the other words, all device with GPS enabled were adapted
this ability to be read over MSca
pe.


Embedded sensors takes all advantages of MScape making it not only work well with GPS location,
but also support other types of sensors as short
-
range radio and associate data with other
compatible plug
-
ins as RFID
-
tags or digital compasses.


Indeed,

the user import all several of media file to build the fancy context for application but by
themselves obviously unable to create the interaction. Context
-
coded information allows these files
define all behaviours of player regard to the space they presen
t as well as vary the change of
behaviour with all acceptance input every time the player enter the space again.









Output sub
-
panel displays output status

Simulated Device Screen

Manual Edit Panel

25

Gantt Charts






















































12/10/2009
01/11/2009
21/11/2009
11/12/2009
31/12/2009
20/01/2010
Write up updated project description for Interim Report
Carry out / write up research for Interim Report
Requirements specification
GUI draft designs
Authoring Tool Prototype up and running
Basic Prototype of Runtime Player up and running
Wrute up of initial design of project for Interim Report
Write up of all main decisions made in project for Interim Report
Write up results of initial implementation for Interim Report
Write up of problems encountered so far for Interim Report
Final Adjustments to Interim Group Report
Basic Prototype of Simulator up and running
26









25/01/2010
04/02/2010
14/02/2010
24/02/2010
06/03/2010
16/03/2010
26/03/2010
05/04/2010
15/04/2010
25/04/2010
05/05/2010
Carry out testing on the basic prototypes
Application to log use of reader and applications
Multi-reader interaction capabilities
Visit a Museum for research into how to better expand project for the main theme
Make improvements on Suite based on findings from museum visit
Carry out testing on all aspects of the Suite (since new additions)
Update design (and user interface) section for Final Report
Update implementation section for Final Report
Write up testing for Final Report
Write up Summary of what was achieved and Reflective Comments for Final Report
Preparation for Open Day
Preparation for Presentation
27

Minutes 1


Date: 07/10/09

Time: 1:00pm

Place: B2

Chair:
Matt

Secretary: Gil

Present: Nick, Gil, Cai, Matt, Ho


Decisions:



Extend product description.



Make list of requirements.



Create time plan.



Define a schema.

Action points:

1.

What
-

Look at example code/edit.

Who:
Cai.

When:

Next supervisor meeting.


NEXT
MEETING:

Date: 14/10/09

Time: 1:00pm

Place: B2

Chair: Gil

Secretary: Nick


Minutes 2


Date: 14/10/09

Time: 1:00pm

Place: B2

Chair: Gil

Secretary: Nick

Present: Gil, Nick, Cai, Matt, Ho


Discussions:



Requirements


Action points:

1.


Extend description.

Who:

Gil, Matt, Ho.

When:

Next supervisor meeting.


2.


Build basic prototype.

Who:

Nick.

When
:

Next supervisor meeting.


3.


Build basic authoring tool.

Who:

Cai.

When
:

Next supervisor meeting.

28


4.

What


Think of core requirements.

Who:

Everyone.

When:
Next superviso
r meeting.


NEXT MEETING:

Date: 21/10/09

Time: 1:00pm

Place: B2

Chair: Nick

Secretary: Ho


Minutes 3


Date : 21/10/2009

Time: 1:00pm

Place: B2

Chair: Nick

Secretary: Ho

Present: Matt, Gil, Ho, Nick, Cai


Discussions:



Extending specification



Go through
requirements



Working on authoring tools

Action Points:

1.

Creating layout, sketching GUI and researching on format

Who: Matt

When: Next week


2.

Extending file behaviors (zip and unzip file in XML)

Who: Nick

When: Next week


3.

How java actually display box layout

base on Netbeans

Who: Nick

When: Next week


4.

Playing with HTML (suggested)

Who: Ho

When: Next week


5.

Adapting software methodology
-
> Optimize software on different OS and platform rather
than just XP

Who: Everyone

When: Unplanned


NEXT MEETING:

Date:
28/10/2009

Time: 1:00pm

Place: B2

29

Chair: Ho

Secretary: Cai


Minutes 4


Date: 28/10/2009

Time: 1:00pm

Place: B2

Chair: Ho

Secretary: Matt

Present: Matt, Gil, Ho, Nick


Discussions:



GUI Designs

o

Simulator


consideration on adapting for multi
-
tag/reader
interaction

o

Authoring tool


incorporate display of other tags created so far and comparisons to
other authoring tools.



Association of media files

o

Can use JVLC / VLC Java Bindings.

Action Points:

1.

Adapt GUI designs based on today’s discussion and carry out
research into other authoring
tools around.

Who: Matt

When: Next meeting


2.

Associating tags with media files (sound and video) based on today’s discussions.

Who: Nick

When: Next meeting


3.

Write up basic research that was carried in first 2 weeks, into report

format.

Who: Gil

When: Next meeting


4.

Develop on the interactivity of the simulator application based on GUI design.

Who: Ho

When: Next meeting


5.

Continue developing the authoring tool.

Who: Cai

When: Next meeting


6.

Look into the deve
lopment of the “runtime”

player


Who: Everyone


When: Next meeting

NEXT MEETING:

Date: 04/11/2009

Time: 1:00pm

Place: B2

Chair: Matt

Secretary: Cai

30


Minutes 5


Date:
05
/1
1
/2009

Time: 1:00pm

Place: B2

Chair:
Matt

Secretary:
Cai

Present: Matt, Ho,

Cai



Discussions:



If the
authoring should tool working without scanning the tag.

o

Use alternative name for purpose of remembering.



Contain multiple tags’ information in one xml file or not.

o

Prefer one file for multiple tags.

Action Points:

1.

Continue to do research about RFID applica
tions.

Who: Matt

When: Next meeting


2.

Enable the drag and drop function of associating behaviors.

Who: Nick

When: Next meeting


3.

Write up basic research that was carried in first 2 weeks, into report format.

Who: Gil

When: Next meeting


4.

Implement the GUI des
ign of authoring tool.

Who: Cai

When: Next meeting


NEXT MEETING:

Date:
11
/11/2009

Time: 1:00pm

Place: B2

Chair:
Ho

Secretary: Cai


Minutes 6


Date:
11
/1
1
/2009

Time: 1:00pm

Place: B2

Chair: Ho

Secretary: Cai

Present: Matt, Nick, Gil, Cai


Discussions:



Do
we miss anything from the description?

31

o

Once basic requirements have been met, more advanced functions can be added,
such as link player to mobile phone. Also, user evaluation can be done to get
opinions from user from different areas, which can help the de
velopment.



Do we need to implement the applications in multiple platforms?

o

It’s an optional requirement.



Interim report

o

The content of final report may be different to the interim report as different
opinions may have been developed.



Should we use file
stream in java to copy files or just call system functions?

o

It’s safer to use file stream.

Action Points:

1.

Continue work on the interim report (complete all sections up to and including requirements
specification).

Who: Matt, Gil

When: Next meeting

2.

Creating

an authoring tool with drag and drop functions.

Who: Nick

When: Next meeting

3.

Create an XML editor for authoring tool.

Who: Cai

When: Next meeting


NEXT MEETING
:

Date: 20/11/2009

Time: 10:30

Chair: Nick

Secretary: Gil


Minutes 7


Date: 25/11/09

Time: 1:45p
m

Place: B2

Chair: Nick

Secretary: Gil

Present: Gil, Nick, Cai, Matt, Ho


Decisions:



Complete the interim report as well as the prototype.


Action points:

1.

Write up the authoring tool section in the interim report.

Who


Nick.

When
-

Next informal meeting.


2.

Continue working on the XML editor.

Who
-

Cai.

When
-

Next informal meeting.


32

3.

Work on the implementation section of the interim report and start coding for a jtree and
the authoring tool.

Who


Ho.

When
-

Next informal meeting.


4.

Finish off
Interim Group R
eport.

Who


Matt.

When


04/12/09.


5.

Work on the implementation section of the interim report.

Who


Gil.

When
-

Next informal meeting.


NEXT MEETING:

Date: 02/12/09

Time: 1:00pm

Place: B2

Chair: Gil

Secretary: Nick