U N I V E R S I T Y

deliriousattackInternet και Εφαρμογές Web

4 Δεκ 2013 (πριν από 3 χρόνια και 11 μήνες)

172 εμφανίσεις

C O V E N T R Y

U N I V E R S I T Y

Faculty of Engineering and Computing

Department of Computing and the Digital Environment

Computer Science

303COM Individual Project

An
Educational Mobile
Application Which Will Take Interactive
User Input to Dynamically T
each the A* Search Algorithm to
Students

Author:

Peter Dixon

SID:

2943013

Supervisor:

Yih
-
Ling Hedley

Submitted in partial fulfilment of the requirements for the Degree of Bachelor of
Computer Science

Academic Year:

2012
/1
3


Peter Dixon


2943013


Interactive Mobile Application to Teach A* Algorithm

COM Project 2012/13


Page
1

of
8


Declaration of originality


This project is all my own work and has not been copied in part or in whole from any other
source except where duly acknowledged. As such, all use of previously publis
hed work (from
books, journals, magazines, internet etc.) has been acknowledged within the main report to an
item in the References or Bibliography lists.


I also agree that an electronic copy of this project may be stored and used for the purposes of
pla
giarism prevention and detection.


Copyright Acknowledgement


I acknowledge that the copyright of this project report, and any product developed as part of the
project, belong to Coventry University.


Signed:









Date:



Family
Name
(Surname)

Dixon

Forename(s)

Peter Leslie


Student ID
no.

2943013


Course

Computer Science



Project Module Code

303COM



1
St

Supervisor

Yih
-
Ling Hedley


2
nd

Assessor

Carey

Pridgeon










Office Stamp



Coventry University

Faculty of Engineering and
Computing

Computing department

Peter Dixon


2943013


Interactive Mobile Application to Teach A* Algorithm

COM Project 2012/13


Page
2

of
8

Abstract


With the rising popularity of ‘Smart Phones’ and
mobile devices in general, it is becoming easier
for students to enhance their education by using these devices. Whether it is as simple as using
the calendar on their phone to keep track of deadlines and classes, or taking notes on a tablet
device, these
devices are already starting to change student’s daily lives. So, why aren’t
teachers using these devices to their advantage? This project will achieve this by creating an
interactive application for both teachers and students.


The application to be const
ructed for this project will teach students about the workings of the
A* Search algorithm. To do this effectively a literature review into shortest route algorithms will
need to be conducted, along with reviews into mobile technology and programming tools
for the
technology in question. In addition research into current educational mobile applications will be
completed, specifically into the learning of shortest route algorithms. Finally, the mobile
application will be developed using the SCRUM methodology.

User requirements will be
captured from a mix of feedback from student with previous experience with Video Games and
feedback from teachers in the Computing department.


What is unique about this application is that it is both interactive for the user an
d will react
dynamically to the input of the user. An application that just teaches the user how the algorithm
works is just as functional as a book. With this in mind the application will provide a dynamic
and interactive learning experience by allowing s
tudents to place obstacles in a grid that will
dynamically show the working of the A* algorithm. The dynamic nature appears every time the
user adds an obstacle to the grid the algorithm will recalculate the shortest route and display it
immediately on the

screen.


The functionality of this application will contain the grid which will dynamically develop as the
user interacts with it. It will also contain a tutorial element to teach the user how the algorithm
determines the shortest route, as the user is us
ing the grid. Additional Functionality that could
be added includes a full tutorial which will take the user step by step through the inner workings
of the algorithm and a side by side view of the differences between A* and a similar chosen
shortest route
algorithm, such as Dijkstra’s algorithm.


In conclusion, this project shall enhance students learning experience and understanding of the
A* algorithm through interactivity. This will only be possible after conducting literature reviews
on search algorithm
s, mobile technologies and the programming tools for those technologies.
The use of interactivity into the application will ensure that it is a much more desirable way to be
taught the algorithm than traditional methods.



Peter Dixon


2943013


Interactive Mobile Application to Teach A* Algorithm

COM Project 2012/13


Page
3

of
8

Table of Contents


Abstract

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

2

Table of Contents

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

3

Table of Fig
ures

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

6

Acknowledgements

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

8

1

Introduction

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

1

1.1

Background to the Project

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

1

1.2

Project Objectives

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

1

1.2.1

To Complete Literature Reviews On:

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

1

1.2.2

To Identify Problems in Current Educational Mobile Applications.

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

1

1.2.3

To
Determine

User
Requirements

Using

Chosen

Research

Methods.

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

1

1.2.4

To

Apply

Scrum

Methodology

and

Develop

a Mobile

Educational

Application By

Employing

Design,

Implementation
,

Testing

and

Evaluation
.

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

2

1.2.5

To

Critically Evaluate

the

Research Conducted

and

Write

Up the Final Report.

2

1.2.6

To Conduct Project Management by Taking Advantage of a Project, Schedule,
Personal Log and a Discussion Meeting Record With Supervisor to Monitor the
Progress
of the Project.

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

2

1.3

Overview of This Report

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

2

2

Investigation

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

4

2.1

Introduction

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

4

2.2

Backgrou
nd Research

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

4

2.2.1

How the A* Algorithm is Taught

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

4

2.2.2

A* Algorithm

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

6

2.3

Shorte
st Route Algorithms

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

8

2.3.1

Dijkstra’s Algorithm

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

8

2.3.2

Bellman
-
Ford Algorithm

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

9

2.3.3

Floyd
-
Warshall Algorithm

................................
................................
.................
10

2.3.4

Johnson’s Algorithm

................................
................................
.........................
11

2.3.5

Comparisons

................................
................................
................................
....
11

2.4

Mobile Technologies

................................
................................
............................
11

2.5

Programming Tools for Mobile Applications

................................
......................
12

2.6

Educational Applications

................................
................................
.....................
13

3

Methodology

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

14

3.1

Why Scrum Methodology

................................
................................
.....................
14

3.2

How it is Implemented

................................
................................
..........................
14

3.
3

Sprints

................................
................................
................................
...................
15

3.3.1

First Sprint

................................
................................
................................
.......
15

3.3.2

Second Sprint

................................
................................
................................
..
15

3.3.3

Th
ird Sprint

................................
................................
................................
......
16

3.3.4

Additional Sprints

................................
................................
.............................
16

3.4

Burndown Chart
................................
................................
................................
....
16

Peter Dixon


2943013


Interactive Mobile Application to Teach A* Algorithm

COM Project 2012/13


Page
4

of
8

4

Requirements Gathering

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

18

5

An
alysis

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

19

5.1

Introduction

................................
................................
................................
...........
19

5.2

Functional Requirements

................................
................................
.....................
19

5.2.1

System Must Visualise the A* Algorithm Navigating a Grid

..............................
19

5.2.2

System Must Accept User Input to Manipulate the Grid

................................
...
19

5.2.3

System Must React to Use Input on Grid

................................
.........................
19

5.2.4

System Must Contain Elements Which Efficiently Help Teach the A* Algorithm
19

5.2.5

System Would Be Functional on Mobile Devices

................................
.............
19

5.3

Non
-
functional Requi
rements

................................
................................
..............
20

5.3.1

System Shall Be Reliable

................................
................................
.................
20

5.3.2

System Shall Be Accessible

................................
................................
.............
20

5.3.3

System Shall Be Effective

................................
................................
................
20

5.3.4

System Shall Be Testable

................................
................................
................
20

5.3.5

System Shall Be Usable
................................
................................
...................
20

5.3.6

System Shall Be
Portable

................................
................................
................
20

6

Design

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

21

6.1

Introduction

................................
................................
................................
...........
21

6.2

Functional Specification

................................
................................
......................
21

6.2.1

When the User Clicks an Active Block

................................
.............................
21

6.2.2

When the User Clicks an Inactive Block

................................
...........................
21

6.2.3

When the User Clicks Outside the Grid or On the Grids Borders

.....................
21

6.2.4

When the Agent Is Navigating the Grid the User Is Being Taught

....................
21

6.3

Interface Design

................................
................................
................................
....
21

6.3.1

Prototype One

................................
................................
................................
..
22

6.3.2

Pr
ototype Two

................................
................................
................................
..
23

6.3.3

Prototype Three

................................
................................
...............................
24

6.3.4

Final Prototype

................................
................................
................................
.
25

6.4

HC
I Issues Addressed

................................
................................
..........................
25

6.4.1

Attempt for Consistency

................................
................................
...................
26

6.4.2

Enable Frequent Users to Use Shortcuts

................................
.........................
26

6.4.3

Offer Informative Feedback

................................
................................
..............
26

6.4.4

Design Dialog to Yield Closure
................................
................................
.........
26

6.4.5

Offer Simple Error Handling

................................
................................
.............
26

6.4.6

Permit Easy Reversal of Actions

................................
................................
......
26

6.4.7

Support Internal Focus of Control

................................
................................
....
26

6.4.8

Reduce Short
-
Term Memory Load

................................
................................
...
27

7

Implementation

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

28

7.1

Tools

................................
................................
................................
......................
28

7.2

Development

................................
................................
................................
.........
28

7.2.1

Sprint

One

................................
................................
................................
.......
28

7.2.2

Sprint Two

................................
................................
................................
.......
29

7.2.3

Sprint Three

................................
................................
................................
.....
29

7.2.4

Project Burndown

................................
................................
............................
30

7.3

Current State

................................
................................
................................
.........
31

8

Testing

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

32

Peter Dixon


2943013


Interactive Mobile Application to Teach A* Algorithm

COM Project 2012/13


Page
5

of
8

8.1

Strategy

................................
................................
................................
.................
32

8.2

Test Plan

................................
................................
................................
...............
32

8.2.1

Sprint One Testing

................................
................................
...........................
32

8.2.2

Sprint Two Testing

................................
................................
...........................
32

8.2.
3

Sprint Three Testing

................................
................................
........................
32

8.2.4

Usability Testing

................................
................................
..............................
33

8.3

Results

................................
................................
................................
..................
33

8.3.1

Sprint Two Testing

................................
................................
...........................
33

8.3.
2

Usability Testing

................................
................................
..............................
33

9

Project Management

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

34

9.1

Introduction

................................
................................
................................
...........
34

9.2

Project
Schedule
................................
................................
................................
...
34

9.3

Logs

................................
................................
................................
.......................
35

9.4

Quality Assurance

................................
................................
................................
35

10

Critical Appraisal

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

37

11

Conclusions

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

38

11.1

Achieveme
nts

................................
................................
................................
..
38

11.2

Future Work

................................
................................
................................
.....
38

12

Student Reflections

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

40

Bibliography and References

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

41

Appendix A


Project Proposal

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

1

12.1.1

An Ed
ucational mobile app which will take interactive user input to dynamically
teach the A* Search algorithm to students.

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

1

Appendix B



Personal Log

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

1

Appendix C


Version History of Report

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

1

Appendix D


Scrum Stand Ups

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

1

Appendix E


Meetings with Supervisor Reco
rds

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

1

Appendix F


Feedback from Supervisor Presentation

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

1

Appendix G


Source Code

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

1

Appendix H


User Manual

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

1

Appendix I


Interview Questions

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

1

Appendix J


Interview Transcription

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

1

Appendix K


Testing Results

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

1




Peter Dixon


2943013


Interactive Mobile Application to Teach A* Algorithm

COM Project 2012/13


Page
6

of
8

Table of
Figures


Figure 1
-

Searching the iPhone App Store for "Algorithm"

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

5

Figure 2
-

Search the iPhone App Store for "a* algorithm"

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

6

Figure 3
-

Example of G, H and F (
Ray Wenderlich 2011
)

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

7

Figure 4
-

Open and Closed List (
Policyalmanac 2005
)

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

8

Figure 5
-

Example Dijkstra’s Algorithm (Introduction to Algorithms 659)

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

9

Figure 6
-

Example Bellman
-
Ford Algorithm (Introduction to Algorithms 652)

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

10

Figure 7

-

Sprint 1 Task Cards

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

15

Figure 8


Sprint 2 Task Cards

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

16

Figure 9
-

Sprint 3 Task Cards

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

16

Figure 10
-

Projected Burndown Chart

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

17

Figure 11
-

First Prototype

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

22

Figure 12
-

Second Prototype

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

23

Figure 13
-

Third Prototype

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

24

Figure 14
-

Final Prototype

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

25

Figure 15
-

Projected vs Actual Burndown Chart

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

30

Figure 16
-

Project Proposal Gantt Chart

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

34

Figure 17
-

Actual Gantt Chart

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

35

Figure 18
-

Ma
ze 1

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

3

Figure 19
-

Maze 2

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

4

Figure 20
-

Maze 3

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

5



Peter Dixon


2943013


Interactive Mobile Application to Teach A* Algorithm

COM Project 2012/13


Page
7

of
8

Additional Materials on the Accompanyi
ng CD



All Draft Versions of Report



Final Version of Report



Final Builds of Project



Personal Log



Version History for Report



Meeting with Supervisor Records



Interview Questions



Interview Record with Peter Every



Project Proposal



Proposed Gantt Chart



Actual
Gantt Chart



Presentation to Supervisor Feedback



All Images used in Report



Design Prototypes



Burndown Charts



Task Cards



Stand Up Records



Source Code Files (Unity Required to Open Project, Actual Source Code be Opened By
Notepad++ or Similar Software)



Presen
tation to Supervisor




Peter Dixon


2943013


Interactive Mobile Application to Teach A* Algorithm

COM Project 2012/13


Page
8

of
8

Acknowledgements


I would like to thank the following for their support throughout this year:




Yih
-
Ling Hedley, for

providing me with constant

support throughout the project including
weekly meetings.




My friends and family for supporting me through tough and stressful times throughout my
final year.




Anyone

else

who aided the project in any way including any feedback given, testing
completed, or content produced.
Peter Dixon


2943013


Interactive Mobile Application to Teach A* Algorithm

COM Project 2012/13


Page
1

of
47

1

Introduction

In this section, we look into the background of the Project itself. This will include looking

into the
origin of the project
, as well as th
e users that the project could potentially benefit.
Following this,
the objectiv
es for the projects are stated which are
each expanded upon
in detail. Finally an
overview of the entire report is
detailed
, where b
oth the stru
cture and content of the report

will
be stated.


1.1

Background to the Project

The issue solved by this project is the lack of mobile applications designed to teach algorithms,
in this case the A* algorithm.

This gap in the market provides an excellent opportunity. This is
because of the
large

market for educational
applications on mobile devices. “Apps are an
important and growing medium for providing educational content to children” (
KQED 2012
).
C
hildren are now growing up using these applications to enhance their learning. There is
however a severe lack of such applications for students in higher education.
The lists such as
“48 iPad apps that college students love” (
Online Colleges 2011
) is extremely different from
similar lists targeted at younger students such as (
Teach Thought 2012
). The apps targeted at
younger student are far more creative and potentially forward thinking. Whereas the list for
college students contains apps like “Rate My Professors”.

There are
many

argu
ments

for why
this is the case
, such as that because college student are at such a higher level of education
applications to aid them are not possible. However it is still a gap in the market that can be filled.
This spawned the idea for the application, to create an interactive and dy
namic mobile
application for higher education student.

1.2

Project Objectives

1.2.1

To Complete Literature Reviews O
n:




Background research on A* algorithm



Search algorithms/shortest route algorithms



Mobile technology



Programming tool for mobile applications


Each
of t
hese literature reviews will be completed and detailed in the Investigation section of the
report which follows this
chapter
.


1.2.2

To Identify Problems in C
urrent
E
ducational
M
obile
A
pplications
.

Educational applications can have many flaws, like all softw
are. When these flaws are present
the efficiency of application will be
decreased
. To help ensure this project does
not fail in the
same ways
, existing mobile application
s will be examined to determin
e what their pros and cons
are.


1.2.3

To
D
etermine

U
ser
R
equirements

U
sing

C
hosen

R
esearch

M
ethods
.

User requirements will be determined by conducting inter
views with certain
lecturer
s in

Coventry
U
niversity.
The

lecturer
s

taking part

will be
members of

the Engineering Computing department
and have a connection
wit
h teaching the subject matter of

this project.

After the interviews have
been conducted the data acquired will be used to determine the requirements of the application.


Peter Dixon


2943013


Interactive Mobile Application to Teach A* Algorithm

COM Project 2012/13


Page
2

of
47

1.2.4

To

A
pply

Scrum

M
ethodology

and

D
evelop

a M
obile

E
ducational

Application B
y

E
mploying

D
esign,

I
mplementation
,

T
esting

and

E
valuation
.

Scrum

methodology will be applied throughout the project. This will affect how the design,
implementation, testing and evaluation wi
ll be conducted through

t
he project. The process of
scrum

will also be detail
ed

and the reason why it is being used will
be explai
ned in the
methodology section.


1.2.5

To

Critically E
valuate

the

R
esea
rch C
onducted

and

W
rite

Up the Final
R
eport.

E
valuation on the research conducted for the project will be detailed in
the
final

section
s

of the
report. In addition the quality of the application itself will be evaluated by the users
.
T
he results
of these tests will be contained in the evaluation section
. Finally the entire report will be
completed
, ready for the deadline
.


1.2.6

To
Conduct Project Management by Taking Advantage of a Project,
Schedule, Personal Log and a Discussion Meeting Record With S
upervisor
to Monitor the Progress of the P
roject.

Project management is an important part of any p
roject, with correct manageme
nt
the project is
more likely to be successful
. Furthermore, if
portions

of the project do not meet expectations it is
more likely that the issue will be discovered if
successful

project management is conducted.

With this in mind, project management will b
e conducted as much as possible during this
project. This involves keeping a project schedule up to date, completing personal logs and
ensuring discussion meeting records with supervisors are maintained, in order to monitor
progress.


1.3

Overview of This Repo
rt

This report will go through step by step the process that has been conducted to complete this
project.
This Introduction is Chapter 1.


Chapter 2, I
nvestigation, will detail the literature reviews conducted for the project. It will also
discuss
the deta
ils of the decision
s

that arose from the research.



Chapter 3

will be the
M
ethodology. This will detail the methodology being used throughout the
projects lifecycle. Furthermore, why that methodology is being used will be explained and what
this means for

the
project.


Chapter 4

will be the R
equirements

G
athering
. This will contain the details on how the
requirements for the project were collected. Which research methods were used and why
.


Chapter 5

is th
e Analysis. In this section all of the functional a
nd non
-
functional requirements
gathered for this project will be explained.


Chapter 6 is

the section on Design. The
functional specification

and design
prototypes

will be
the focus of this section. Additionally the
HCI issues addressed

will be described in the design
section.


Chapter

7

will detail the I
mplementation process. The details of this section will cover subject
like the platform, languages and tools used to develop the project. The issues
that occurred

and
Peter Dixon


2943013


Interactive Mobile Application to Teach A* Algorithm

COM Project 2012/13


Page
3

of
47

how they were overc
ome will also be covered.
In addition, how the methodology used
affected

the project will be explained in this section of the report.


Chapter 8
is

T
esting. The description of the tests conducted will be contained in this section and
additionally the resul
ts of the test themselves.
This chapter will cover everything from the test
plans to the results of the tests.


Chapter 9

is

Project M
anagement which will
go through the project schedule, variety of logs
used and quality assurance
employed

to ensure the p
roject
is as well organised as possible.
The effectiveness of these methods will also be evaluated and how they could be improved
discussed.


Chapters

10 and 11 are Critical Appraisal and C
onclusions respectively. In the former the work
conducted in the
project will be analysed for both positive and negative aspects. This will have
the aim of demonstrating the knowledge that has been gathered throughout the project.

The
latter however will discuss what the achievements of the entire project have been and
what
future work can be done.


The final
chapter, chapter 12, will be the Student R
eflection
. This section will discuss how the
project went from the student’s perspective.
Discussing

personal performance, problems
encountered and how they were overcome, w
hat was learnt and finally what could have been
done differently to improve the project.


Following this final section will be the bibliography/references and the Appendixes.




Peter Dixon


2943013


Interactive Mobile Application to Teach A* Algorithm

COM Project 2012/13


Page
4

of
47

2

Investigation

2.1

Introduction

This section details the research conducted prior
to starting the development of this project.


There were several areas where research was conducted before the project began
development. The first was background research on the A* algorithm which was mostly
conducted before the proposal for the project.

The topics that were looked into were
how the A*
algorithm works, how many different places you can learn about how the algorithm works
(Books, internet etc.), how they teach the algorithm.


Following that research into several other shortest route
algorithms is conducted. This is to
determin
e what makes the A* algorithm

useful in the areas that it is used the most. This is
accomplished by
detailing other shortest route algorithms and comparing them to the A*
algorithm.


The next area
discussed

is Mo
bile Technologies. In this section the pros and cons of different
mobile platforms are detailed to determine which of these should be the focus. This will also
help find the limitations of mobile platforms in general which will aid the development of the
p
roject.


The final research area is the programming tools for mobile applications. While software such
as Xcode and Eclipse will be part of the research, they will not be the focus. The focus will be
on software that can export software for many different

platforms, software such as Unity.


2.2

Background Research

2.2.1

How the A* Algorithm is Taught

When the idea for the project was conceived
firstly

background research on the algorithm itself

needed to be conducted
. This is to
certify

that the project was a good i
dea from the standpoint
of being original and that it could be
achieved
. The
next

step was to learn how the A* algorithm
works.


When looking for resources teaching the A* algorithm a wealth of them was found on the
internet. Tutorials such as “Introductio
n to A* Pathfinding” (
Ray Wenderlich 2011
)
were
extremely helpful when attempting to learn all the details of how the algorithm works. That was
not the only tutorial that was used however, other useful materials were “A* Pathfinding for
Beginners” (
Policya
lmanac 2005
) and “Introduction to A*” (
Stanford n.d.
). That final
tutorial has
comparisons between A
* and other shortest route algorithms also.


There are
variety of alternative
ways to learn the A* algorithm however, online tutorials is only
one of many ways.

T
here are plenty of journals which detail
how the A* algorithm works and/or
how it can be adap
ted to many different scenarios. One such journal goes into great detail
about how the A* algorithm can solve the problem of determining the minimum cost path
through a graph. It achieves this by detailing how to use heuristic approaches to solve the
probl
em and as stated previously, goes into a
greater

on the subject (
Hart et al 1968
).


Looking through these resources not only helped me learn in great detail how the A* algorithm
works, but also allowed me to gain insight into how the algorithm itself is taught currently. There
were generally two different ways the algorithm was taught, th
e first of which was to use
Peter Dixon


2943013


Interactive Mobile Application to Teach A* Algorithm

COM Project 2012/13


Page
5

of
47

diagrams and break the solution down into steps. The diagrams used were all very similar, they
all used the same large grid to simulate the algorithm on. On the grid the start and exit would
usually be blocked in the middle by
a

barrier so the algorithm would have to go above or below
the obstacle. This made for a very simple example
that could be easily explained
.


The other way the algorithm was taught was through pseudo code or in certain cases, actual
code. This method could

potentially be helpful in certain circumstances, for example
when

implement
ing

the algorithm into a project, but when simply trying to learn how the algorithm
works, it is not the best method.


However what is noticeable

is that there was no interactive
tutorials to teach the algorithm
anywhere.
This was
intriguing

because this sort of problem seems perfect to be solved by an
interactive application.
When searching both the iPhone App Store and Google Play store for
Android devices,
nothing

fit that descr
iption. Evidence of which can be seen
in Figure 1 & 2.


Figure
1

-

Searching the iPhone App Store for "Algorithm"

Peter Dixon


2943013


Interactive Mobile Application to Teach A* Algorithm

COM Project 2012/13


Page
6

of
47


Figure
2

-

Search the iPhone App Store for "a* algorithm"


As you can see with both these

figures
, the quality of the applications on this topic is
lacking.
The best
seems to be an application called “Algorithm Handbook” which can be seen in the first
picture. However this application only teaches a small amount of theory and also uses raw cod
e
to teach
the algorithms. On top of this the
list of algorithms is perhaps
limited and A* algorithm is
not included in it.


2.2.2

A* Algorithm

The A* algorithm is the main focus of this project and will be discussed
in great detail

throughout the
entire
report. Therefore it is

important

to explain how the algorithm itself works.
The A* algorithm finds the shortest path from a start point to an end point.
It achieves this using
the best techniques from other algorithms to achieve the task much more efficie
ntly (
Stanford
n.d.
). It utilises elements from Dijkstra’s algorithm and Best
-
First
-
Search. These elements are
preferring to choose a grid node closer to the starting po
int and preferring to choose a grid node
closer to the goal, from Dijkstra’s algorithm and Best
-
First respectively.


The terminology used by A* refers to preferring to choose nodes closer to the starting
point

as
g
, and preferring to choose nodes closer t
o the goal as h. G is calculated using the cost of
movement from the start node to the current node. H is calculated by estimating the cost of
movement from the current square to the end node. This is called an estimate because it will
generally ignore obs
tacles along the way to the goal. Both of these are used to calculate the
shortest route, so both of these are added to together to make F.


Peter Dixon


2943013


Interactive Mobile Application to Teach A* Algorithm

COM Project 2012/13


Page
7

of
47


Figure
3

-

Example of G, H and F (
Ray Wenderlich 2011
)

The above example shows these thr
ee figures in action. In every square the cat can move to, all
three numbers are display. In the bottom left of the square is G, the bottom right is H and the
top left is F. Each of these squares has a G value of one because they have all only moved one
sq
uare. However, there are varying values for H. This is because they are varying distances
away from the goal, in this case the bone. Remembering that H is calculated by ignoring the
obstacles we can see why the closest square has a value of four, while the

other two have a
value of 6.


The final element to the A* algorithm is how it decides which node to travel along next. Similar
to other shortest route algorithms such as Dijkstra’s algorithm A* uses an open list and a closed
list to find the best path.

T
he closed list are nodes which have been cho
sen to explore because
they have the lowest F score of any node on the open list. The open list is the list of nodes we
have not explored which are adjacent to any node on the closed list. An example of this can
be
seen clearly
in Figure 4

where the blue squares are nodes in the closed list and the green
squares are in the open list.

Peter Dixon


2943013


Interactive Mobile Application to Teach A* Algorithm

COM Project 2012/13


Page
8

of
47



Figure
4

-

Open and Closed List (
Policyalmanac 2005
)

Now that the algorithm has calculated the shortest route using both the techniques shown, we
need to find and save the path that has been calculated. The algorithm achieves this by starting
at the end node and working its way back to the start node. This i
s only possible due to
each
node saving the node that it was navigated from. Alternatively it could be described as t’s
predecessor.

Therefore from the end node, the algorithm looks at every node in the paths
predecessor to discover the optimal path.


2.3

Shortest Route

Algorithms

While the main focus for this project is the A* algorithm there are plenty of other shortest route
algorithms
which serve a similar purpose. Examples of such algorithms are
Dijkstra’s

algorithm,
Bellman
-
Ford algorithm, Floyd
-
Warsh
all algorithm and Johnson’s algorithm.

The first two are for
graphs where the goal is to get from
one node to another
, whereas the last two are to calculate
the shortest paths from every node, to every other node. Each of these algorithms
is

detailed
below
.


2.3.1

Dij
k
s
tra’s Algorithm

“Dijkstra’s algorithm solves the single
-
source shortest
-
paths problem on a weighted, directed
graph … for the case in which all edge weights are nonnegative.” (
Cormen et al 2009: 658
).
Breaking that definition down into something mo
re manageable, we see that Dijkstra’s algorithm
searches a graph where each vertices has a weight cost which is used to determine how
desirable that path is.
In the case of this algorithm all the weight costs have to be nonnegative.
Explaining how the algo
rithm achieves the goal of finding the shortest path can be very
complicated if every aspect is explained, but
these diagrams aid greatly in this task
. Dijkstra’s
algorithm will repeatedly search the graph for the next node with the lowest cost, this next
node
could be anywhere on the graph that it can reach with already opened nodes. However the cost
of each vertices is added up to where

the

current path is. Furthermore if the cost of one path to
a node is less than a path to the same node which was alread
y found, the shorter path will
replace that path.


Peter Dixon


2943013


Interactive Mobile Application to Teach A* Algorithm

COM Project 2012/13


Page
9

of
47


Figure
5

-

Example Dijkstra’s Algorithm (Introduction to A
lgorithms 659)

Using
Figure 5 from

“Introduction to algorithms” we can see all of this in action.
The transition
from (c) to (d) is a perfect example of this. We can see in (c) The path from s to x goes from s to
y to x and has a cost of 14. However we can see in state (d) that a shorter path in terms of cost
was found, from s to y to z to x. This path

costs 13, which is less than the last path, so now the
path found in (c) is ignored.


Dijkstra’s algorithm has many different uses, one of
the
biggest uses being routing networks.
However what is actually used to achieve this is not just Dijkstra’s algor
ithm, usually there is an
additional element to the solution. One of the
examples

found was a journal proposing an
algorithm that used Dijkstra’s algorithm as the base and built upon it to improve it for the
ap
plication it was being used for (
Garcia et al
2007
).

This sort of practise seems to be common
place, at least with Dijkstra’s algorithm, proving the algorithm can be very modifiable.


2.3.2

Bellman
-
Ford Algorithm

Where Dijkstra’s algorithm solves single
-
source shortest
-
paths where edge weights are non
-
nega
tive, the Bellman
-
Ford algorithm solves these problems where edges weights may be
negative.
One of the major differences between this algorithm and Dijkstra’s algorithm is that
Bellman
-
Ford is searching for a route which does not contain a negative cycle.
A negative cycle
is a path where all edges contained in the path sum to a negative value. If a negative cycle is
found the Bellman
-
Ford algorithm then the algorithm will return false and the path cannot be
used.


While Bellman
-
Ford is very similar to Dijks
tra’s algorithm in the way that it is run, there are a
couple of key differences. The most important being that Dijkstra will search the graph for the
next node it shall relax in a greedy nature, however Bellman
-
Ford will
relax all of the edges. It
will re
peat this as many times as there are nodes in the graph minus 1. This makes the
algorithm itself slower than Dijkstra’s algorithm however this is necessary to accurately
determine the shortest route through a graph which may contain negative values. As is
evidenced by this example from “Introduction to Algorithms”
.


Peter Dixon


2943013


Interactive Mobile Application to Teach A* Algorithm

COM Project 2012/13


Page
10

of
47


Figure
6

-

Example Bellman
-
Ford Algorithm
(Introduction to Algorithms 652)

Figure 6

is very useful for showing how negative values can effect a graph, for example the
transition between (c) and (d), however it does not show what is happening in the background.
Each iteration in the graph every single vertices is being relaxed, however th
e diagram only
shows the vertices which result in an improved route. This is an important factor to keep in
mind.


Again as Dijkstra’s algorithm is very similar to the Bellman
-
Ford algorithm a significant amount
of the use cases for the algorithm are very

similar. However the cases in which Bellman
-
Ford
will be chosen over Dijkstra’s will be when the graph has negative values in it that need to be
taken into account. Another use is when you wish to find a negative cycle then you could use
Bellman
-
Ford algo
rithm to check this for you.
An extremely interesting example of
implementation of the algorithm is from a user’s blog

(
Shriphani Palakodety 2010
)
.

The post
describes an implementation of the Bellman
-
Ford algorithm to attempt to exploit exchange
rates. The example shows how a wide variety of problems can be translated into graph
problems with relative ease.


2.3.3

Floyd
-
Warshall Algorithm

Both Dijkstra’
s algorithm and Bellman
-
Ford algorithm solve single
-
source shortest paths which
means there is only one start point and one end point in the solution. However, if one wanted to
see the paths from every point in a graph to every other point in the graph the
y would most
likely use one of these two algorithms. Less detail will be described about these algorithms
because they are less relevant to the A* algorithm, which is the focus of this paper.


The first example of such an algorithm we are discussing is the

Floyd
-
Warshall algorithm.
The
calculations the algorithm itself carry’s out
is
complicated, using matrices to store the data of the
calculations. The result of the algorithm is the length of each path from every node to every
other node. If one wishes to
know the data of the path, additional elements must be added to
the algorithm itself. The algorithm also allows negative weights for edges but it assumes that
there are no negative cycles. Additionally this allows the algorithm to detect the presence of
ne
gative cycles if used in a certain way.


Peter Dixon


2943013


Interactive Mobile Application to Teach A* Algorithm

COM Project 2012/13


Page
11

of
47

Uses for the Floyd
-
Warshall algorithms cover a wide range of problems. Examples include
finding the shortest paths in directed graphs, finding regular expressions denoting a regular
language, optimal routing and fin
ally finding the widest paths/maximum bandwidth paths.


2.3.4

Johnson’s Algorithm

Johnson’s algorithm
solves the shortest paths from every vertices to every other vertices in a
sparse directed graph. A sparse directed graph is a graph which has a minimal amount

of
edges in it.
As with the previous algorithm, edge weight can be a negative value as long as no
negative cycles exist.


The algorithm itself uses the Bellman
-
Ford algorithm to transform the graph into a graph with no
negative weights. This allows Dijks
tra’s algorithm to be used on the transformed graph,
calculating the length of the path between all pairs of vertices.


The uses for Johnson’s algorithm will be similar to Floyd
-
Warshall’s algorithm, however the
graph being calculated must be sparse. If t
he graph is sparse then Johnson’s algorithm can
solve the problem in a shorter amount of time.


2.3.5

Comparisons

Comparisons between the A* algorithm and Dijkstra’s algorithm are extremely easy. This is due
to one half of the A* calculation is exactly the same
as Dijkstra’s algorithm. There is very little
research on this topic because of that fact. This leads to a situation where A* is very clearly
more efficient due to the fact
that Dijkstra

is

only

one half of the calculation.
Therefore we can
conclude that D
ijkstra’s algorithm should be used instead of the A* algorithm when you cannot
estimate the remaining path reliably. If this issue arises, the A* algorithm becomes a less
efficient version of Dijkstra’s algorithm.


Comparing the A* algorithm becomes
increa
singly easier as we move to the Bellman
-
Ford
algorithm and beyond. As the Bellman
-
Ford algorithm is very similar to Dijkstra’s algorithm in its
execution, it is
less efficient than the A* algorithm
for
similar

reason
s
.


As Floyd
-
Warshall’s algorithm and Jo
hnson’s algorithm are designed to solve all
-
pairs shortest
route problems, the comparisons are slightly unfair.

Both these algorithms are undoubtedly less
efficient but they also solve a very different set of problems. It would however be very interesting
to attempt to use the A* algorithm to see if it can compute all
-
pairs shortest route more
efficiently than eith
er Floyd
-
Warshall or Johnson’s algorithm.


2.4

Mobile Technologies

When developing software for mobile devices one of the first steps is to decide which platform
you will develop for. The market right now is dominated by Nokia, Samsung and Apple (
All
Things D
2012
). The first two making Android based handsets and Apple making the

iOS based

iPhone. Both these operating systems run functionally similar phones, but wi
th a very different
style. Apple adopt a “Walled Garden” approach which has its benefits such as keeping out a lot
of unsavoury or inappropriate content. But as with anything else it also has its downsides
(
Business Insider 2013
).


Android on the other adopts the opposite approach where almost everything is open to the user
if they try hard enough. This certainly solves a lot of the problems with Apple’s app market, but
Peter Dixon


2943013


Interactive Mobile Application to Teach A* Algorithm

COM Project 2012/13


Page
12

of
47

can have ser
ious downsides too. Such as an extremely large piracy problem which is leading a
large amount of developers to favour the iOS platform (
Gamasutra 2012
).


With pros and cons on both sides, for this

project the best approach would be to develop the
application for both platforms. This is because students will have a range of different devices. If
the application is limited to one platform then it could alienate a large portion of a class,
rendering t
he application useless. Additionally the larger issues with both platforms do not effect
this project. This project
will not be sold

and has no inappropriate

material i
n it.

Therefore

we will
be

attempting to develop for both platforms.


2.5

Programming Tools
for Mobile Applications

When researching
the tools available to complete the project, two distinct categories were
found
. The first category is the standard programming environments that are used for each
mobile platform. For example this would be Xcode fo
r iOS devices and Eclipse for Android
devices. Using these platforms would have the advantages of having a lot of support as both of
these platforms are very well documented. They would also allow for full control over the project
which could be lost by us
ing third party software. Finally these tools are already familiar to the
development team so it would
be easier to start work on the project
.


The biggest downside

to

using

these
platforms would be the lack of portability. Xcode uses
Objective
-
C as its la
nguage which is Apple’s own version of C. Eclipse however uses Java and
porting from one language to the other would take a significant amount more work. Due to the
small development this would require
development to take place

on one version at a time.


The second category of tools would be third party development tools. There are a variety of
these but the most interesting and useful for this project would be game development kits.
The
reason for this is the rapid prototyping that the tools provide. Game
s require fast prototyping, in
order to find an idea that works and is fun. While my project is not a game per se, it has similar
interactivity so can easily be built this way.


Two of the most popular game engines right now is the Unreal engine (
Epic
Games, Inc 2013
)
and Unity game engine

(
Unity Technologies 2013
)
. The Unreal engine is built by a company
called Epic Games (
Epic Games, Inc 2013
). They have a free and a paid version of their
engine, the paid version of which is for large companies. The engine is award
winning and
widely renowned

as one of the best engines in the market
. Unity on the other hand is an open
source develo
pment kit which is well supported by its community. Once your application is built
you can export the application to multiple different devices, some of which you have to pay for
the license for.


Weighing the pros and cons of each of these tools it was d
ecided to develop using the Unity
game engine. This is because of the large portability the engine provides means that only
money blocks the development of the application to a variety of devices. This is a much better
position to be in than attempting to
rewrite the application for each platform. Additionally, the
engine is open source which will reduce the barrier to entry. The community around Unity is
very strong and there are a large number of tutorials which will teach everything from the very
basics
to the advanced techniques.


Peter Dixon


2943013


Interactive Mobile Application to Teach A* Algorithm

COM Project 2012/13


Page
13

of
47

2.6

Educational Applications

Educat
ional Software is not a new development, it has been around for a long time.
There are
fantastic examples of educational software and computers such as the BBC Micro (
Nesta 2012
).
The only thing that has changed is how and where we use our devices. With touch devices
becoming so prominent in today’s society (
Tech Crunch 2013)

it is foolish to believe th
ese
devices will not become a large part of teaching and learning in the future.


These devices are already affecting our classrooms for younger students. Lists of the “Best
educational iOS apps” like this one (
Tech Learning 2013
) are common place. However the state
of the app store is changing every single day as new apps get released and old ones become
obsolete. Websites which curate this information for parents and teac
hers
are increasingly
important, the best example of this is ap
po L
earning (
appo Learning 2013
). It is a website which
reviews educational apps based on different age groups. If you have a child in “High School”
you

can use the website to find out what the best apps are for each subject for that age group
for example. It is an extremely powerful tool for teachers and parents.


What makes a good app

though?
This article (
The Next Web 2011)

discusses what goes into
mak
ing a good application. While the suggestions are based on applications for mobile devices,
most of them are true for any piece of software. Good user interface design and filling a gap in
the market are true for all software design. Knowing your market is

potentially much more
difficult in the mobile market right now. The market is constantly shifting and
changing that it
could be difficult to know what a good idea is by the time your app is developed.


One thing is clear, the mobile application market is
still a new and emerging market. It has only
been five years since Apple launched the “App Store” on the iPhone (
Tech Crunch 2008
). Since
then so much has changed, incl
uding the way we consume content. No matter how much the
market shifts though
,

basic software design principles will always remain true.



Peter Dixon


2943013


Interactive Mobile Application to Teach A* Algorithm

COM Project 2012/13


Page
14

of
47

3

Methodology

3.1

Why

Scrum M
ethodology

The methodology being
employed for

this project will be the agile methodology,

Scrum.
This

methodology is based around the idea of spending as much time as possible working on the
actual product, instead of excessive planning, designing or spending time in meetings. One
member of the team is designated the Scrum Master and it is the
ir job to ensure that
his Scrum
team has everything they need to complete their work and prevent anything from interfering with
the team.
Over the recent years Scrum has become
increasingly popular

and t
here are many
reasons for this; it’s flexibility, foc
us on the customer’s needs

and

the focus on creating a
working product first and foremost instead of just planning it
.


Additionally, this particular methodology is
extremely

popular in the

video

game development
market.
Game developers were using waterfal
l type models for development for a long time, but
as the price of making video games went up the margin for error became
significantly less
.
The
main problem with the waterfall model in
game development

is that the product will not be
tested until the very end of development. Thus leading to a situation where the team will not
discover if the product they have been working on for two to three years is fun.

T
he current state
of the market

is such

where th
e big blockbuster video games (E.g. Call of Duty, Halo) cost
a lot
of money

to make

(Crave Online
2013)
.
To ensure that every game published makes a
profit;

publishers are concentrating on s
equels and established brands
. This is stifling innovation,
ensuri
ng less value in the product and deteriorating work environments

(
Keith, C
2011: 10
).
Scrum is helping to alleviate this with the principles of agile development such as:



Ensuring that employees have direct contact with any other employee they need to
disc
uss a problem with.



Continually producing working software.



Working with customers to produce software that they want to use.



When problems arise, change is embraced.


3.2

How
it is I
mplemented

Since scrum methodology

is designed

to help a team
contribute to

a

software development
project more efficiently, when applying it to my project some changes had to be made.

These
changes ranged from small changes for example the length of my sprints, to large changes that
will be discussed in more depth later. With this

tailored approach to scrum methodology,
greater
efficiency will be achieved throughout the project.



The first major part of scrum

that was
impossible

to
complete in its current form

was the

daily
stand
-
up meetings

with the team
, this is

because
there is

o
nly

a single

member on

the team. So
to keep the work completed

in the days previous in perspective

and generally keep a log of
work completed,

a log was kept
of
stand
-
ups from days where

work

was completed
on the

project.
This proved useful on several oc
casions simply for that perspective look over the
project. The stand
-
ups also provided enough information to create a project burndown chart
which gave further perspective over the progress of the project itself.


Additionally, sprints for this project we
re only one a week long, this is due to the limited
complexity of the project. A typical scrum project would be such that a team would be required
to complete, hence the complexity of the project is much greater. My project is less complex so
reaching a mi
lestone in the project will take less time and effort.


Peter Dixon


2943013


Interactive Mobile Application to Teach A* Algorithm

COM Project 2012/13


Page
15

of
47

Finally, elements of the methodology like the idea of a scrum master were not used during this
project as they served no purpose. The project owner was an idea that was already in place
from the
begi
nning

of

the

project. The meetings carried out with the supervisor of the project
typically fit this role. These meetings often contained discussion of
the
best

way

to implement
the project from the view of a
lecturer
.


3.3

Sprints

With the methodology chosen
and reasoned the sprints that will be completed during the project
must be planned. There will be three main sprints that have a fixed length of a week. The time
they are completed is unable to be locked down due to other pieces of work occupying time.
The

third sprint may need to be completed multiple times, if testing shows it is required.
However, this will only be the case if time is permitted.


3.3.1

First Sprint

The
feature
s

to be completed in the first sprint will be to create the grid

and implement the
interactivity
.

This
requirement

can be split into separate tasks;
create the objects, Set them up in
a grid, organise the colours of each cube, set up the camera,
and finally implement interactivity
into the cubes. The time frame for this sprint will be a
week.
The task cards for this sprint look
like this:


Figure
7

-

Sprint 1 Task Cards

3.3.2

Second Sprint

The features that require completion in this sprint are based on implementing the A* algorithm
into the application. These can split down into the
following tasks; implement the A
* algorithm
into a class/function, implement an agent which can move through
the grid,

and

connect the
algorithm and the agent
. There may be fewer tasks

in

this sprint but the effort required for the
tasks is larger.
The time frame for this sprint continues to be a week and the task cards look like
this:

Peter Dixon


2943013


Interactive Mobile Application to Teach A* Algorithm

COM Project 2012/13


Page
16

of
47


Figure
8



Sprint 2 Task Cards

3.3.3

Third Sprint

The only feature for the third and final sprint is the educational components of the application. It
can be split down into these tasks; Add F, G and H to each cube used by algorithm, implement
pop ups, incorpora
te algorithm data into pop ups. It is anticipated that these tasks will take the
most time to complete so far. However, the sprint length is still one week. The task cards for the
sprint are:


Figure
9

-

Sprint 3 Task Cards

3.3.4

Additi
onal Sprints

Additional sprints may be required due to feedback received during testing. In this case the
sprint would contain task cards created by the feedback itself and the project burndown chart
amended.


3.4

Burndown Chart

Now that

the sprints are plann
ed out
,

we can

estimate

the amount of effort required for

each
task
, in order

to project an ideal line of progress throughout the project. We can then use this
estimate against our actual completion rate, to see if we are on schedule or not.

This will only

take into consideration the first three sprints for the project. The additional sprints will need to
Peter Dixon


2943013


Interactive Mobile Application to Teach A* Algorithm

COM Project 2012/13


Page
17

of
47

update the burndown chart as required.

Figure 10 shows the projected burndown chart for this
project.


Figure
10

-

Projected Burndown Chart



0
5
10
15
20
25
30
35
40
Day
0
Day
1
Day
2
Day
3
Day
4
Day
5
Day
6
Day
7
Day
8
Day
9
Day
10
Day
11
Day
12
Day
13
Day
14
Day
15
Day
16
Day
17
Day
18
Day
19
Day
20
Day
21
Projected Hours Left

Peter Dixon


2943013


Interactive Mobile Application to Teach A* Algorithm

COM Project 2012/13


Page
18

of
47

4

Requirements

Gathering

The system outlined in this report is a simple idea so the requirements needed to complete the
project
are not as detailed as with other systems
.
To gather these requirements one
-
on
-
one
interviews were completed with a couple of
lecturer
s. Both the questions that were asked and a
transcribing of one of the interviews with
Peter Every are

in Appendix J
. The goal of these
interviews was to understand
whether my views on what the application should be aligned with
the opinions of professionals. In certain cases they were similar and in other cases
they
brought
to light a different perspective
.


The best example of this was with the interview with Peter
Every
shown in Appendix J,

when he
explained how students are exercising their long term memory less because of things like the
internet and mobile devices.
This could lead to programming being more difficult to teach due to
an important part of learning p
rogramming is remember large blocks of code and manipulating it
properly. This is a view
not considered before and the main point

t
a
k
en
from
it

is short and to
the point will be the most beneficial way to surface information inside the application itself.


The other main point gained from the interviews is
that the application should be an addition to
the classroom instead of replacing it. The interviewees expressed concerns over trying to
replace that element of interaction between students and
lecturer
. H
owever Peter Every also
raised having a diverse range of teaching methods as an important element. This allows all
different types students who learn in different ways to be tailored too. So the application
being
proposed can fill this gap in the market
.


With these points
the design was

reinforce
d

through analysis of these interviews and
the
research conducted earlier in the report
. This
is
shown in the following sections.



Peter Dixon


2943013


Interactive Mobile Application to Teach A* Algorithm

COM Project 2012/13


Page
19

of
47

5

Analysis

5.1

Introduction

After completing the requirements gathering and
investigation the next step is analysis of the
data gathered. This analysis will be shown by laying out both the functional and non
-
functional
requirements of the system. Each requirement will also be explained in detail along with the
description of whe
re

this requirement originated.


5.2

Functional Requirements

5.2.1

System Must Visualise the A* A
lgorithm

Navigating a G
rid

Perhaps the most important requirement for the application. If the user cannot effectively see
the A* algorithm navigating a grid then they will

encounter difficulty both interacting and learning
anything from the application.
This will be achieved by programming a grid and an A* agent
which will navigate that grid avoiding the obstacles. To measure this requirement the grid must
be tested to see
if it is effective or if it is confusing.

5.2.2

System Must Accept User Input to M
anipulate the
G
rid

Accepting user input
is important to the application functioning correctly. If it cannot accept the
users input then the system will not react to it either, thus

breaking the interactive portion of the
application. This requirement will be measured when the system is tested on how it responds to
user input, which is the next requirement.

5.2.3

System
Must React to Use Input on G
rid

The system must respond to the user’s
inputs, which will be limited to clicking or pressing on the
squares in the grid. The correct response to this action will be deactivating the square if it is
already active, in order to prevent the A* agent navigating that particular square, or vice versa
. If
this action functions as intended the user input is working correctly.

Additionally any clicks or
presses on anything other than the grid should result in no action taken.

5.2.4

System Must Contain Elements W
hich

E
fficiently

H
elp
Teach the A*
A
lgorithm

This

requirement is left intentionally vague as the exact method of teaching is as yet undefined.
Ideas for how the system should be taught were gained from the investigation and requirement
gathering, but whether these idea work completely is yet to be seen.
At every stage of
implementation of the teaching aspect of the project testing will be done. Testing will be
completed to check the current effectiveness of the application as a teaching method. It will be
up to the quality of the testing as to how measura
ble this requirement is.

5.2.5

System W
ould
Be Functional on M
obile
D
evices

The focus of this project is to have a working application for mobile devices. This cannot be
completed in the scope of this project for a variety of factors. Exporting the project from
Unity
onto iOS devices requires a licence that costs around £260. Exporting to Android would cost an
additional £260

(
Unity Technologies 2013
)
. This
exceeds

the budget of the project itself and the
only alternativ
e is to rewrite the application which would take too much time.


Peter Dixon


2943013


Interactive Mobile Application to Teach A* Algorithm

COM Project 2012/13


Page
20

of
47

5.3

Non
-
functional Requirements

5.3.1

System Shall B
e
R
eliable

In this case this requirement pertains to the educational portion of the application as being
reliable. It is of course important that the

application not crash or break in any way.

However,
more important is that the application reliably educate the user on the A* algorithm. If the user is
prevented from learning at any point the application rapidly loses value. This will be measured
during

testing along with other elements relating to the educational aspect of this application.

5.3.2

System Shall B
e
A
ccessible

The barrier to entry for this application must be very low.
Users with many different types of
devices must be able to use the application

itself. Additionally many different types of users with
a variety of disabilities or special needs must be able to use the application. With the variety of
students at any given university it is important that accessibility be in place. This will not be
m
easured during the scope of this project as it is an issue that requires more resources
including time and money than is possible.

5.3.3

Syste
m Shall B
e
E
ffective

When the application is teaching it should be as effective as possible. What this means is that
th
e amount of items on the screen should be as little as possible to gain the largest
performance in terms of learning. The application would be very inefficient if it was covering
most the screen just to teach the user
what it needs to teach. This will be m
easured when
testing is completed. If the tester likes the user interface and is also being taught then the
system is effective.

5.3.4

System Shall B
e
T
estable

The application could take a significant amount of testing before it is finished. This is due to the
t
eaching aspect of the application being so difficult to get right without testing to see what
works. This me
ans the application must be easily

testable so the barriers to trying something
new will be as low as possible.

5.3.5

System
Shall Be U
sable

Usability is
a key factor to any application. The application must be easy to pick up for a variety
of different users and have as little barriers to entry as possible.
The ease of use for the user to
interact with the application must also be very high. Otherwise thes
e factors would get in the
way of the user learning anything from the application itself. This will be discovered through the
testing of the system.

5.3.6

System Shall Be P
ortable

A factor determined from my interviews was that the system will need to work on all types of
systems, to prevent anyone from not being able to experience it. The system will more likely be
adopted in a classroom if the
lecturer

can assume that every one of

their students can use it.
This means the application will need to be portable so it will take minimal effort to run the
application on many different devices. This will be measured at the end in the retrospective to
see how difficult it would be to port
the final product.



Peter Dixon


2943013


Interactive Mobile Application to Teach A* Algorithm

COM Project 2012/13


Page
21

of
47

6

Design

6.1

Introduction

In this section, the functional specification will be described along with a brief description of the
design of the interface for the system. The functional specification will simply state the
requirements that are
needed for this project. These requirements will contain some detail but
will not be exact, this is due to various reasons such as the potentially shifting

design of the
application. In the interface design section, prototype designs for the project will b
e shown in
addition to highlighting HCI issues in the design.


6.2

Functional Specification

6.2.1

When the User Clicks an Active B
lock

When the user clicks an active block, the block changes visual style to denote that it is inactive
and is removed from the grid of