Vous êtes sur la page 1sur 14

2013

Ersin Demirtas
Claudiu Ploscariu
Teodor Zangur

10/15/2013
Prague Metro System
1 | P a g e

Contents
1. Introduction and Design ................................................................................................................. 2
1.1 Introduction.........................................................................................................................2
1.2 Design..................................................................................................................................2
2. Implementation .............................................................................................................................. 3
2.1 Graphic Design.....................................................................................................................3
2.2 Coding..................................................................................................................................5
3. Test and evaluation ......................................................................................................................... 7
3.1 White Box Testing................................................................................................................7
3.2 Black Box Testing.................................................................................................................9
3.3 Evaluation..........................................................................................................................10
4. Tutorial ........................................................................................................................................ 111
5. Contribution by each member and reflection ............................................................................ 122











2 | P a g e

1. Introduction and Design
1.1 Introduction
The report is representing the result of teamwork and understanding of data structures in Java
programming, which allowed us to create a simple but efficient application for a metro system.
The core of our application is the Dijkstra algorithm, which has the role to calculate the fastest
route a user has, based on his source and destination. Given the constraints of the requirements
we need to meet, we have been asked to use data structures and an appropriate GUI, in order to
make our application more efficient. The aim of this project is to understand how to implement
an algorithm into a programming language and benefit from it in order to create an innovative
application. Moreover, it gives us the chance to see and test the diversity of data structures we
can use and also to realise which one give use the most advantages in creating our product.
Consequently, in the following sections of this project we are describing the steps we took to
complete our coursework.

1.2 Design
The algorithm that we used to create our product has as its core the Dijkstra algorithm, which
calculates the fastest route, based on the selected source and destination. However, we adapted
its original form to our application by structuring it in different classes and methods, in order to
make it functional. Nevertheless, before starting our coding to make the project, we had created
the pseudo code of our application. Consequently, we are offering a unique insight by comparing
the initial form of the algorithm with our product, for a better contrast and understanding of the
functionality of our application.
The steps of the original form of the Dijkstra algorithm are as followed:
1. Label the start vertex with permanent label 0 and order label 1
2. Assign temporary costs to all the vertices that can be reached directly from the start
3. Select the vertex with the smallest temporary cost and make its label permanent. Add
the correct order cost.
4. Put temporary costs on each vertex that can be reached directly from the vertex you
have just made permanent. The temporary cost must be equal to the sum of the
permanent cost and the direct distance from it. If there is an existing temporary cost at a
vertex, it should be replaced only if the new cost is smaller.
5. Select the vertex with the smallest temporary cost and make its cost permanent by
boxing it.
6. Repeat until the finishing label has a permanent (boxed) cost.
7. To find the shortest path(s), trace back from the end vertex to the start vertex. Write the
route forwards and state the length.



3 | P a g e


Our assumptions were that each dot would represent 500 meters per 30 seconds. Based on the
calculations we have conducted, we got a result that the train will travel with 47 kilometres per
hour.
2. Implementation

In this section we will provide information about how we implemented and develop our
application. Our project is perfectly meeting all the requirements, being a simple but efficient
system. Moreover, during this stage of the project we took into account what a user is expecting
from the application. As our product is customer-oriented, we focused to make it user friendly to
the highest level allowed. Therefore, the effort and the assumptions we made to create our
project brings out the potential desired and the opportunity to maximize it. Due to the rich
information required in this section, we decided to break it down in two subsections in order to
provide a better understanding of the initial thoughts, the steps we followed to create our
project and the progress we made as we finished it.

2.1 Graphic Design
In this subsection of the implementation stage, we will talk about everything that is related to
the graphic design starting from the initial thoughts and assumptions to the final stage of our
progress. Some of the points we will touch here are:
the design of the GUI
the use of JFrame
objects used
layout: full explanation of their purpose
customer-oriented and user friendly choices

4 | P a g e


In order to create our GUI, we used the JFrame Form provided by the NetBeans interface, as a
matter of fact this gave us the chance to save a lot of time and effort that we focused into coding.
Moreover, this gave us a huge advantage because we had a better control of the objects used and
there were no constraints such as the ones the layouts would provide. Therefore, the management
and the arrangement of the GUI became an easier task.
The initial GUI we created was meeting the requirements but we encountered a lot of conflicts and
constraints when we tried to implement the functionality. Moreover, it was not appropriate for
being user friendly and we had to make several changes. However, in order to see the progress we
have done, I will show a comparison between the initial GUI and the final one.
In the initial GUI we decided to use two tabs that will allow the user to switch between seeing the
map or seeing the route plan. This was a good feature and we kept it because of its efficiency. We
took this decision in order to make the users life easier by sparing him of the stress to alternate
between different windows. As I stated before, one of the tabs is showing the map of the Prague
metro system. To make the map visible, we had to use a JLabel that allowed us to capture the image.
Comparing to the route plan, this was a very simple task. Consequently, we had to put a lot more
effort and time for finding and implementing a proper way of displaying the journey of the user and
its summary.
The route plan has the role to display the journey the user is choosing and also to find the shortest
path to his destination using the Dijkstra algorithm. Our initial thought for this matter was to use a
JTable which proved to be a wrong decision because of the big number of constraints that are
brought with it. One of these constrains is the way we can show the data we use which was
separated into 4 columns: station, line, time to next station and the total time of the journey. The
problem was that the text was not fitting in one cell of the row and it was squeezed in a manner that
it could not be seen properly anymore. Moreover, when we tried to show how much time the user
has to wait for the next train when he is changing the line, we had to use only on cell of the full row
of the table. That made the height of that cell really broad, giving it a bad look by leaving space out
on the right hand side. Nevertheless, a bigger problem appeared when we wanted to add colour to
text, because it could not be visible anymore without using an auxiliary colour for the background of
the cells. Furthermore, we could not display the journey summary, fact which made the JTable
undesirable. Due to all this problems, our GUI was looking awful and we had problems with the
functionality. Consequently, we had to find a different but similar way to display the information of
the route plan.
The final solution we came up to solve all of these problems was the JScrollPane, because it gives a
better control of the content and the text inside. In order to display the information required, we are
using BoxLayout to be able to add objects one under the other with no constrains. Moreover, we are
using JPanels, each of them having a GridBagLayout which separates the information in four sections
as we wished to do with the JTable. In order to avoid the colour problem we encountered with the
table, we found an alternative solution by manipulating the border of each JPanel. Moreover, we are
using two different colours for the rows and alternate between them. Consequently, this is making
the user to focus better on the information of each row and spot it easily. These innovative ideas
5 | P a g e

allowed us to add the journey summary at the end of the route plan and gave the user a better
experience with our product by having an excellent functionality and GUI.
After all the struggle and effort we put into creating a brilliant route plan, we had to start to create
the rest of our GUI. Therefore, we expanded the window of our GUI and added necessary objects to
complete our design. In order to get user inputs, we are using two JTextField for the stations and
one combo box to choose the time desired for his journey. Furthermore, we are using JLabels that
give a good sight and an easier understanding on how to use the application we created. Finally, the
GUI is providing two buttons, each of them having a different role. One of the buttons is used to
access the route plan and see the journey you have and its summary and the other is used to access
the tutorial that help you to understand how to use our application.
Overall, we can proudly say that we created an excellent GUI that is working according to the
functionality we implemented and provides an unprecedented user friendly experience. Moreover,
due to all the innovations we brought to create this master piece, we can say that the GUI has a
shade of artistic touch, which makes our product desirable.


2.2 Coding
In this subsection of the implementation stage, we will talk about everything that is related to
coding, starting from the Dijkstra algorithm to classes, methods and data structures. Some of the
points we will touch here are:
Dijkstra algorithm
Experiment mode
Peak hours
Classes and methods used
Data structures
Get the route
The first step we made regarding this matter was to implement Dijkstra algorithm, because it
represents the core of the whole system. The algorithm is starting by getting the route from the user
input and then it finds the shortest-path to every single station. Initially, we were not storing the
information accurately and we had to update the algorithm to store the stations line. One of the
reasons we had to implement this feature was the fact that a station can belong to two lines.
Moreover, we enabled the algorithm to store the stations by using array lists which gave us the
opportunity to create an array without any out of balance exception.
We added a method to the algorithm called getRoute that starts the loop of checking and storing the
information. This method finds the path between two stations based on the user input. Within this
method we are using an array list of boolean type that is storing the temporary stations into a
variable called tmpList. As soon as you visit a station, it becomes permanent and then is stored in an
array of boolean type that tracks the permanent stations.
6 | P a g e

In the while loop we are using within the algorithm, it is checked all the stations that are related to
the chosen route of the user and then will add the total weight (dots between the stations) into
tempWeight. The variable tempWeight has a structure called Solution, which is a class that stores
the weights between the stations and their Ids. We also use a variable called tmpList which stores if
a station is visited or not. As this variable is a Boolean type, when a station is visited it will e set to
true.
Finally, the algorithm is checking all the stations related to the route and add their weights and
names in a list. Afterwards, it gets the smallest weights to get the next stations that need to be
visited. The next variable we are using is keeping track of the stations visited and stores the
smallest weights. This action will be repeated until all the stations are visited.
The getRoute method is a list type with two arguments (toStationIndex, arrivingOrLeavingTime)
which is checking several things from the beginning in order to provide accurate information for the
route plan:
the time input
the line of the station
the experiment mode is on or off
peak hours service
any change about stations, lines, time or service
We are getting the arrivingOrLeavingTime as a string, but then we are converting it to date format in
order to keep track of the time in the route plan. In order to store the result list we are using, we
included a list class type called Route. To find the path from the destination to the Route you have to
use the variable called tmpWeight, to get all the stations indexes within that route. Moreover, we
have to store the line of the station, fact which is possible by checking if the station line is same as
the route line. This action can be performed by watching the next station line, because it will be
common to the previous one. Therefore, the line corresponding to these terms will be stored.
Furthermore, this method is checking if the service is during the experiment mode or the peak
hours. For the experiment mode the method is checking if the route is during the set intervals of
time and if the corresponding line is C. If these requirements are met, then the time to the next
station will be halved. The process for the peak hours is similar with the only exception that is
applied to all lines and the waiting time in case of a line change is significantly lower. In the end all
the changes and the information is added within an array list called Route, that stores: the stations
name, line, time to next station and line change.
Besides, within the method it can be observed a loop that is checking the stations required for the
route. The way this loop is checking if the station is on the line, by checking the previous and next
stations. However, the first station is checked outside the loop because it needs to check only the
next station.
In order to improve the efficiency of this algorithm, we used data structures such as array lists. The
difference between arrays and arrays lists is the level of proficiency, as a matter of fact we are
indexing only the relations between the stations and not their position. Moreover, classic array
would need to read the construction every time you need to insert every index, because you must
7 | P a g e

define the size of the array within the initialization. Whenever you make a change in the array, you
have to reconstruct it and pass the values from the previous array. However, the array lists are
easier to use, because they allow you to add index to specific values. Furthermore, they
automatically resize when you remove or add an index, fact which leads in having no out of balance
exceptions.
For the experiment mode we are using a boolean method called isInExperimentMode with two
arguments as input from the user: time and line. This method is checking if the time is within the
specific hours, which in our case are from 9:00 to 16:00 and from 19:00 to 00:00 and also is checking
if the route is on line C. If these terms are met then this method will return the value true, otherwise
it will return false.
For the peak hours service we are using a boolean method called isInPeakHours to check a specific
time within the specific hours. The only argument for this method is time, which in order to meet
the requirements has to be between 5:00 and 19:00. Therefore, if the action is performed
accordingly, then the method will return a true value, otherwise it will return false.
In order to create our project we had to implement seven different classes, each of them having its
role. When MetroGUI starts, the main method is called, action which makes the Station class to
parse and store the past information which will be passed to RouteFinder.
StationParser uses Station class, Line Class and array lists to store information about their stations
and their properties. Also the experiment mode can be enabled or disabled from station
configuration file. The Line, Route, Station and Solution classes are used for storing information
required for the route plan. In the end, RouteFinder class is using the information from MetroGUI to
apply Dijkstra algorithm and returns the list to MetroGUI which will output the route found.
Finally, to make our program more efficient, we have used the break statement within the loops, in
order to break them whenever the information we are looking for is found.

3. Test and evaluation
3.1 White Box Testing

Test No. Description Expected Result Actual Result
1. To test if all the
properties of the
stations set in
StationParser.
Show list of stations
with their name and
line.
Passed.
2. Testing RouteFinder to
get route by passing
StationParsers values
and specific stations to
find route between
two station.
Show list of stations
within the planned
route.
Passed.
8 | P a g e

3. Testing for converting
minutes to time
format.
Show minutes and
seconds in time format
of HH:mm:ss
Passed.
4. Testing if statement
for experiment mode
by disabling from the
stations file.
The experimental
mode shouldnt be
applied with in the
experiment mode.
Passed.
5. Testing experiment
mode by enabling from
the station file.
The experimental
mode should be
applied with the
experiment mode
times. So the Route
planner displayed line
C half the speed.
Passed.
6. Testing the if
statement of peak
hours for 5:30.
The route planner
should show 2 or 3
minutes randomly for
changing between
lines.
Passed.
7. Testing the if
statement for peak
hours for 19:55.
The route planner
should show 10
minutes for changing
between lines.
Passed.
8. Checking the loop for
leaving or arriving time
this is shown in
JComboBox so that the
user can select the
time of leaving or
arriving.
The JComboBox should
show time intervals of
every 5 minutes from 5
am to mid night.
Passed.
9. Testing placeholder for
both JTextField
(fromStation and
toStation).
For both JTextField
(fromStation and
toStation) when empty
is should change the
colour to light colour
and display Station
name to help user to
enter station.
Passed.
10. Testing suggestion list
for both fromStation
and toStation
JTextFields.
Should find matched
stations and show in
suggestion list.
Passed.
11. Testing suggestion box
to hide station name
that is already in use
by another JTextField.
Hide station name in
suggestion list.
Passed.




9 | P a g e

3.2 Black Box Testing

Test No. Description Expected Result Actual Result
1. Start the application. It should start without
any errors.
Passed.
2. Display the map. Show the map on the
left side of the
application.
Passed.
3. Display the route planer. Show the route planer
on the right side of the
application.
Passed.
4. Insert the name of the stations and
select the time and press Plan route
button.
It should display the
route information.
Passed.
5. Insert station name that doesnt
exist in the station file.
It should change the
colour of the labels to
red and describe the
error.
Passed.

6. Route planner test to find the
shortest path between two stations.
The tab should be
changed to route
planner and it should
display the stations
with changes and
route summary should
be displayed on the
left replacing the map.
Passed.
7. Switch between the route plan and
map tabs.
When clicking on the
map tab display the
map or click on route
plan tab to see the
route information.
Passed.
8. Background colour and line colour. Display the colour of
each line that is used
to commute; also the
background colour will
be white and grey.
Passed.
9. Peak and Off Peak hours. Add the waiting time
to the total time for
the journey.
Passed.
10. Experiment mode. It should double the
speed for the train on
line C at certain hours.
Passed.
11.

Passing intersections. Narodni trida to Hlavni
nadrazi will pass two
intersections; it should
display the correct
stations and times.
Passed.






10 | P a g e

12. Help button. When pressed it
should display the user
guide for the
application.
Passed.
13. Testing to check if the program
allows same station names for route
planner text fields.
Should display error
for the user to change
one of the stations.
Passed.
14. Pressing route plan button without
inserting station names.
The program should
not do anything.
Passed.
15. Inserting only from station name to
check if its going to show error for
to station label.
Program should
change the colour of
the label and species
to insert to station
name.
Passed.
16. Inserting only to station name to
check if its going to show error for
from station label.
Program should
change the colour of
the label and species
to insert from station
name.
Passed.

3.3 Evaluation
The project we have created is working properly, but is slightly changed from the original design we
thought in the beginning, as we encountered some difficulties. Due to this fact, we had to bring new
features to compensate our loss. Even though we encountered several obstacles during our work,
the big number of experiments and research we conducted brought the desired results. Fortunately,
in order to create our application we had to use Java programming, which we already knew.
Therefore, on this side of the problem we were fine, until we had to think what data structures will
be the best to use for our system. In the end we chose to use array lists because of the high level of
control you can have upon them.
The problem that made us change the original design was the fact that we could not display properly
the information for the journey chosen by the user. Moreover, we could not synchronize the time
between the stations to add it up to the total. This put us in a big pinch, because this part was an
essential requirement for the project. This problem aroused, when we wanted to match the
functionality of the application to the GUI. Consequently, in order to fill up this problem, we had to
find an innovative solution.
The mighty saviour solution we have found is the JScrollPane which made our life a lot easier. In
addition to, we have used both BoxLayout and GridBagLayout together with JPanels, which had as a
result an innovative table interface for the route plan. This gave us the opportunity to see the limits
of creativity for creating objects in Java. Consequently, we found an easier way to solve our problem
related to the matching of functionality with the GUI. Unfortunately, our problems were not all
solved yet.
Due to the experiment mode and the peak hours service we had to implement, our code had a lot
of conflicts when it had to choose the specific time it takes to go from one station to another.
Moreover, we had three stations that represent the intersection between two different lines.
11 | P a g e

Consequently, each of us grabbed a copy of the code and started to debug it until we found a
solution. The main problem proved to be the fact that we were running the same statement of time
convergence twice, which made the waiting time one hour when you would have to change the line.
After we detected this small inconvenience and fixed the problem, our application became desirable
as it should be.
Some improvements that we could have brought to our project would be time synchronization
between trains in the waiting point when the user would like to change the line. This feature would
have made our system more desirable and more efficient, because the user would have to wait less
for the next train. Moreover, we could have tried to create our own array list and to make it more
efficient than the existing ones. More specific, we could have created our own structure for it and to
manipulate its implementation to be exclusively for the stations. Due to the time constraint and the
difficulties we have met, these ideas were not possible to be added to our project.
All in all, the system we have created is simple but efficient and meets all the requirements without
any processing delays or any problems. Everything being said, we reached our objectives as our
teamwork was strong and we learned how useful and challenging the data structures can be.
4. Tutorial
Prague Metro Route Planner User Guide

When the application has started, on the left you will find the map for Pragues metro system, which
will include all the station for each route, as well as the ones under construction. To the right is the
route planer where you will be able to choose the station from - to where you are traveling and also
you can select the time of departure.


Map
Insert station names
Press to get
route
infomration
12 | P a g e

Once you have been through those steps for your journey planer, you can click on Plan route and it
will generate the information for the chosen route. The route will be displayed in a table format
indicating the colour of the line on the left side of the station name in the table and also the time to
next station and the total time which is displayed in HH:MM:SS forma
While viewing the route information, you can go back and check the map by clicking the tab called
Map and then go back to the route information also by clicking the Route Plan tab. Both tabs are
located in the left - top corner of the application. To exit the application just simply clicks the exit
button located on the right - top corner.



5. Contribution by each member and reflection

During this coursework we have learned the importance of data structures and also how essential
teamwork was. As I mentioned before, Dijkstra algorithm was a challenging task, especially when we
had to implement it into programming language and adapt it to our case. Due to this fact, we
realised what a strong team means, as we always worked together and helped each other.
Moreover, we had weekly meetings to complete the work that we have broken down into tasks. In
this way we could see our progress until we reach the desired result by creating an innovative
application, which gave us the drive to continue and carry on the work successfully. Furthermore, we
Tabs
Exit
Line colour
Time
13 | P a g e

divided the work into three roles that each one of us fulfilled successfully in his own way. The roles
we chose were the following: implementer, tester and debugger. As we have different strengths,
each one of us did what he was best at, even though all of us participated in every role. In the end
we were satisfied with the work we done and the cooperation that led us to create our system.
Consequently, everyone in the team ended up by putting the same amount of effort in this project.
Everything being said, we will continue by referencing the work and the contribution of each team
member:
Reflection by Zangur Teodor Ionut:
As the team leader of the team I had the role to divide the work into tasks and organize weekly
meetings to work. I had to set our goals in a manner that we would all agree. The most contribution I
did for the project was to debug the project and detect any errors, mistakes or conflicts in the code. I
also had to come up with innovative solutions, facts which forced me to use the critical thinking skill.
Moreover, like the other members, I had to participate in implementing the algorithm and creating
the structures needed for the project. Beside I decided together with the team what data structures
we should use, bringing arguments which I stated before.
Claudiu Ploscariu was an important member of our team as his main role was to test the application
and find the flaws in our code. Due to his work, we spent 5 whole days in order to remove all the
errors and conflicts we had in the code. These problems were related to the fact that the matching
of the GUI with the functionality was conflicting. Moreover, as the other members of the team he
had participated in implementing the algorithm and the structures needed to create our system. He
also had an important role in designing the GUI of our system.
Ersin Demirtas was the main implementer in our team, as he built the core of the algorithm in our
application. Moreover, he created the auxiliary class and the text file needed for our project. Due to
his work, our system became very efficient as he gave it the possibility to be expanded easily and
further developed. Moreover, he had a very important role in making our application user friendly
taking into account what he would desire from the application. Furthermore, he also helped with the
testing and debugging of the code when the situation demanded it.
All in all, I think everyone deserves full marks as we all put the same effort in this project, fact being
proved by the successful result.

Member Percentage
Ersin Demirtas 100%
Claudiu Ploscariu 100%
Teodor Zangur 100%

Vous aimerez peut-être aussi