SCORE Contest Project

madbrainedmudlickΤεχνίτη Νοημοσύνη και Ρομποτική

20 Οκτ 2013 (πριν από 4 χρόνια και 24 μέρες)

79 εμφανίσεις



SCORE Contest Project

Building a Public Transportation System Product Line




Team members:



Augustin Petrović (
augustin.petrovic@fer.hr
)



Uma Shankar Subramani (
newshanuma@gmail.com
)



Hafiz Umer Waqar (
umer_waqar@yahoo.com
)



Siva Chaitanya Nayak Eslavath (
shiva.eslavath@gmail.com
)



Manish Kungwani


(
manishkungwani@yahoo.com
)



Pratik Bapurao Barkade (
pratik.barkade@gmail.com
)



Omar Tawffeeq Jaradat (
ojt10001@student.mdh.se
)


Mälardalen University, School of Innovation, Design and Engineering

&

University of Zagreb, Faculty of Electrical Engineering and Computing


This project was performed as a part of Distributed Software Development course “DSD” led by
Professor
Ivica
Crnković

and Professor Mario Žagar, under supervision of
Severine Sentilles



Table of Contents

1.

Executive Summary

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

1

2.

Problem Statement

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

2

3.

Document review

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

2

4.

Scope o
f the Project and Main Challenges

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

3

5.

Development Process

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

3

6.

Project plan

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

4

6.1.

Activity plan

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

4

6.2.

Management Plan

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

5

7.

Requi
rement Specifications

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

7

7.1.

Design story

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

7

7.2.

Use cases

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

8

8.

Architectural Design

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

10

9.

I
mplementation

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

14

9.1.

Product Line Core Implementation

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

14

9.2.

Instance Implementation

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

15

9.2.1.

Västerås PTS

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

16

9.2.2.

Lausanne PTS

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

16

9.2.3.

P
TS on Cloud

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

17

10.

Verification and Validation

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

17

10.1.

Design verification and validation

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

17

10.2.

Testing

approach

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

17

11.

So
mething out of the Box

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

17

12.

Outcomes and lessons learned

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

18

13.

Summary
................................
................................
................................
................................
....

19

14.

References

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

19

15.

Appendix A
: The Umple language

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

20

16.

Appendix B


PTS PL Instance on Cloud

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

21



1


1.

Executive Summary

Public Transportation System Product Line is a SCORE project

[3]
which aims to create a software
product line in the public
transportation domain. The main goal is to design a product core
implementation, on which multiple software products could rely on. Additionally, three software
products (instances) had to be developed to demonstrate the reusability of the product core
im
plementation.

All the transportations systems in the

world have common domain logic
. Therefore we have
introduced the shared characteristics of those systems into one extensible (core) module


Product
Line Core. The implementation for each product (a spec
ific transportation system) then uses this
core, and extends it with additional required functionalities based on the
Customer’s specific

requirements. We have developed several such instances, each having a different set of
requirements.

This project was
led by a group of students enrolled in
Distributed Software Development course
(DSD)

which is executed in cooperation between
Mälardalen University


Västerås

and the
Faculty
of Electrical Engineering and Computing


Zagreb
. The course has

a successful history in leading such
projects, despite the geographical separation between the team members. The team working on the
project has four members from
Västerås

and three members from Zagreb.

Model Driven Development, Test Driven Development, a
s well as the use of Umple language

and
Agile methodology, were made mandatory by the SCORE project definition. Of all the Agile
methodologies, we have found that Agile Unified Process (AUP) would best suite our (distributed)
development environment.

Development using Umple language, which is a modeling language, enabled complete use of Model
Driven Development. Taking into consideration that Umple is still under development, the restriction
of not changing Umple generated code led to quite a few compl
ications. The customer intends to
improve Umple by analyzing and studying the software being developed by the SCORE participants.
We were using Umple to the maximum extent and we aimed to use as many features of Umple as
possible without wavering from our
designed solution and intended result. The whole
implementation has been done using Umple.

Using Test Driven Development, we wrote tests for each and every code
-
able entity that we have
produced. We have successfully written and tested the whole of the Pro
duct Line core with all the
requirements specified by the customer.

The reason behind developing Product Line instances is to verify and test the practicality and the
reusability of our Product Line Core. The instances have their own user interface and may

have an
independent persistent storage module. To allow for persistent storage, we have developed a Data
Access Layer, which was not a part of the core requirements.

Using Umple during development, we have found many key missing features (essential) and
bugs.
We have included these into the bug reports and duly submitted them to the Umple team with a
detailed description of the issue, the environment and how we overcame the hindrance to continue
development.


2


2.

Problem Statement

The Public Transportation Sy
stem Product Line is a system which can
instantiate the core
infrastructure for any public transportation system.

Model Driven Development, Test Driven Development, as well as the use of Umple language and
Agile methodology, are mandatory by the SCORE proj
ect definition.

There have to be at least three instances derived from the Product Line Core. Each instance must
have most of the major functional requirements valid in any public transportation system identified,
such as the following:



Core elements/Doma
in Atoms: The system shall have the core elements of a Public
Transportation System such as stops, lines and runs (A vehicle when actually operating on a
line is called a run). The timing of runs has to be taken into account.



Schedule Management: To allow
creation and management of Schedules for the System. The
System should also allow modifying Schedules. This includes handling exceptional situations
like emergencies, holidays, etc. A particular schedule should be modifiable to accommodate
new runs or modi
fied runs.



Passenger Assistance and Real
-
time tracking: The system should be able to generate time
-
tables for usage by commuters and also give them assistance, such as information about
lines between two stops, the runs between two stops, the lines and run
s on one particular
stop, etc. Real
-
time tracking shall include the location and arrival times of a vehicle on a run.
We shall predict the arrival time for a stop and use it for passenger assistance along with the
actual arrival time observed.



Vehicle Trac
king and Management: The system should be able to manage the vehicles owned
by the customer. It includes keeping a track of the vehicles, dealing with encountered issues.
It shall also assign particular runs to vehicles, and monitor when a vehicle is opera
ting on a
run.


In addition to the four major functional requirements above, the instances must differ from each
other and at least one of them must represent a real public transportation system used by a real city
or country.

Extended Requirements include

factors as information persistence, optimization and intelligent
prediction of timings.

3.

Document review

This report has been written to cover mainly and not exclusively our
project scope and challenges
,
project requirements
,
used architecture
,
implementat
ion
,
project and management plans
,
validation and verification

and

lessons learned
. The development process is explained in Chapter 5.
Project and management plan is described in Chapter 6. In Chapter 7 we specify the functional and
non
-
functional requirem
ents. “The big picture” of our system and how it all fits together is described
in Chapter 8. In Chapter 9 it is explained how we have managed to put model design in executable
code. Used methods for testing and validation are described in Chapter 10.


3


4.

Sco
pe of the Project and Main Challenges

The purpose of the project is to create a sustainable Product Line and test its practicality with few
instances. While doing so, we have to utilize Umple as much as possible and contribute to its
development in a posit
ive way.

Implementation had to be Model Driven Development and this surely required us to model first.
Here, Umple seemed to be very useful due its ability to generate code from the model defined in
UML
-
like form. This was a time saving factor in the early

stage of development.

But t
he fact that
Umple is still under development has been the biggest challenge in the development process of the
project. Sometimes we had to limit our options to Umple and we could not use some essential
language features (like s
upport for abstract classes and Generics) which would have made our code
more robust, efficient and the development process more time
-
effective. The challenge was
amplified

by the fact that we must

not edit the code generated by Umple.

Having a distributed

development environment, we have faced a lot of challenges like cultural
differences and huge gap in knowledge distribution which have led us to some conflicts. Thankfully,
we have managed to overcome those challenges although it cost us valuable project
time.

5.

Development Process

Because of a quite short period available for learning required Umple language and the fact that
Agile approach incorporates test
-
driven development and incremental release
-
based development,
we have found the Agile approach to b
e the one most suitable for us. The Agile Unified Process (AUP)
proved to be effective in all regards.

Figure 1 explains our development process. Based on the project proposal
document we have
defined requirements and assigned them to increments and the basic system architecture. Each
iteration slightly changed architecture, which is explained in section 8. Each system was validated via
testing.

PTS product line development proc
ess was restricted by the course “Distributed software
Development” conditions and rules to have at least 4 main and mandatory presentable iterations as
milestones


Alpha, Beta, and Release Candidate and Final Product release.

Figure
1
: incremental release
-
based development [4]


4


6.

Project plan

Our sevenfold m
ulti
-
cultured team came together with this project to fulfill all the requirements of
“Distributed Software development” course and to compete in the SCORE contest. This required
rigorous planning and effective implementation. This section describes the pr
oject plan.

Project development has been divided based on weekly work, allowing short measurable task
divisions. The work was divided based on skills and abilities. Each one of us was obligated to work at
least 12 to 14 hours weekly to complete the tasks w
ith definite commitment.

6.1.


Activity plan

Being a continuously iterative process, we developed the functional requirements gradually. In the
middle stages of the product line, we started working on the instances.

Activity

W39

W40

W41

W42

W43

W44

W45

W46

W4
7

W4
8

W4
9

W5
0

W5
1

W5
2

W0
1

W0
2

Project preparations

























Requirements analysis &
definition

























Requirements Prototype

33

















Design System Architecture
























Product Line Implementation

























Instances Implementation

















Testing

























Documentation

















System Delivery

















Table
1
: PTS activity plan [5]

After personal discussions and skill
assessment,

the members were given the roles:

Name

Initials

Responsibilities

Augustin Petrović

AP

Model and Java Developer, SCORE representative and
Technical writer

Uma Shankar Subramani

US

Java Developer

Hafiz Umer

Waqar

HU

Java Developer, Database Developer

Siva Chaitanya Nayak Eslavath

SC

Technical writer

Manish Kungwani

MK

Model and Java Developer, Technical writer and Team Leader

Pratik Bapurao Barkade

PB

Graphic designer and
SVN

Manager

Omar Tawffeeq
Jaradat

OJ

Database developer, Technical writer and Project Manager

Table
2
: PTS Project Group [5]

Sneaky risks could be fatal for the project, so we have taken precautionary actions by defining
expected risks and effective preventive actions in case of event occurrence. The following table
represents the risks that we were expecting during the developm
ent process [5]:


5


Possibility

Scenario

Risk

Preventive action

High

The
Umple language

is still
under the development

so

the
re might be o
ccasional
bugs.

Waiting for

the
bug
-
fixes or
finding workarounds

could

delay

the whole project
workflow.

Manual
ly

editing the
Umple
generated
code, with

the
p
ermission of the SCORE
customer.

High

The
Umple language

is still
under the development

so

there might be some

missing or incomplete
features.

Not following best practices
for coding will result in
reduced
performance and
reliability of the solution
.

Additionally, refactoring or
redesign might induce delay.

Finding workarounds for missing
features in a way that quality
doesn’t degrade.

Medium

Some team members
could have problems in
communication.

Team is
scattered or conflict
arises, due which the
development or any other
process might be delayed.

Expand
ing

Communications Plan

or helping team members to
improve their communication
skills. In a case of conflict, the
resolution must be achieved as
soon as po
ssible.

Low

U
nexpected technical or
non
-
technical

issues
.

Exceeding the estimated
timeline.

Timeline should be reviewed
weekly or at least evey two
weeks by the Project Manager
and the Steering group.

Low

SVN troubles.

Losing the contents or bad
subversion actions.

Making backups without
redudancy limitations.

Low

Sickness absence.

One or more members get
sick
because of which they

quit the project for a while
.


Increas
ing

the working hours for
the rest

of

team members
.

Table
3
: Risk management table

6.2.

Management Plan

PTS team consists of two sub
-
teams, one in Croatia consisting of three members and another in
Sweden consisting of four members. P
roject management was not correlated only to the project
man
ager, but it was, in order to make every member contribute effectively, collaborated tasks from
the work perspective by two team leaders.

The geographical barrier forced alternative ways of communication. The communication strategy was
easy to establish,
but practically hard to follow. Formal communication structure was set to facilitate
communication strategy to keep chaos at bay. Please see Figure 2.



6


This structure treats the local students as
one

team
.

One team member on each side is defined as a
“Team Leader” who represents the local team.


The team leaders are the primary point of contact

between the local teams
, but random inter
-
member communicatio
n occurred as per need basis.

All team meetings, except some sub
-
team internal meetings which were in person, were voice
conferences using the Skype application (VoIP). Frequency of scheduled team meetings varied from
week to week, approximately once or tw
ice per week. Emergency issues were handled by
unscheduled voice conferences or by text
-
chat, again using Skype, or by an announcement on the
Google group.

To manage the

portfolio and
source code
,

we have used versioning control system, in particular SVN.

This
allowed the

team member
s

to collaborate without allowing content
-
conflicts to bubble up. The
University of Zagr
eb also hosts a page on its web
site to allow team members

to store the

documents
related to the project
.

Project specific announcements wer
e also listed on the University of Zagreb
website.

Meetings with project supervisor were held as a Skype conference, usually with whole team, or in
person, usually with the project leader.

For customer and SCORE communications we have been using only e
-
mai
ls.



Figure
2
: PTS communication structure [5]


7


7.

Requirement Specifications

PTS product line functional requirements are considered to be the core and the main infrastructure
requirements for any planned instance.

7.1.

Design story

Being a Product Line, the solution must fulfill basic and shared set of
requirements by common Public
Transportation System.

The solution requirements were obtained by collecting the data from the public transport
companies, discussions with other project groups and brainstorming sessions. We narrowed down
the options by gaugi
ng their importance, usability and essentiality and implementation effort.

We have contacted the customer, public transportation companies and interacted with other project
groups and colleagues. Although the response from Public Transport companies was no
t enthusiastic
and very limited, we took into the consideration their views and needs. The Questionnaire about the
technicalities and emergency handling was sent to Västmanland Local Traffic Co. (VL) in Västerås,
Sweden.

Based on a real public transportati
on study, there should be full support for defining core public
transportation elements such as vehicles, stations, lines and particular runs together with the time
extension that enable predefining change of lines and particular runs.
These are the domain

atoms.
For every atom there should be a full support of creating, editing, deleting and linking them to other
atoms in form of associations. For example, line can have more than two assigned stations etc.

The Product Line Core must have full support of de
fining schedules for every line, runs and particular
runs. Every vehicle on lines should have a time of start, and expected time of arrival at every station
or stop. Every schedule can be manually changed or there can be predefined change to schedule,
base
d on days, months, special events etc.

Changes of schedules are made of a collection of predefined changes of lines, stations or runs,
therefore all rules that are applied to predefined changes are applied to changes of schedules. One
run, line or station
cannot be changed more than once per change of schedule.

Conflict resolution between predefined changes is based on priority and time of occurrence. Event
based predefined changes have greater priority than periodical predefined changes. If two
predefined
changes have same priority, predefined change with later time of occurrence will be
chosen (FILO style).

Satisfaction of passengers is of most importance for companies providing the public transportation.
Therefore, there should be support for the passenge
r assistance such as timetables and (prediction
of) actual timing of arrival of vehicles on specific line to wanted station.
Additionally, guidance from
one station to another (with line transfers) should be available.

Tracking actual position of each vehi
cle is a key to successful resolution of unexpected problems such
as vehicle breakdown and for successful prediction of actual arrival time. Therefore the system
should have support for tracking of vehicle position. A vehicle, will through exposed APIs inf
orm the

8


system about its position. Implementation of a vehicle's position tracking and how vehicle should
connect to an instance’s APIs is not concern of the system and is not part of the solution. Every
instance maker should take care of it based on the a
vailable technology, budget and specific
conditions.

Such functionality can be used to predict actual arrival times for runs. The system should have full
support for generating real
-
time timetables which can be used by any system component or any
instance.

Every transportation system should have support for solving problems due to unexpected events
such as vehicle breakdown, obstructed route etc. The system should provide functionalities for
rerouting vehicles (dynamic line changing) and for vehicle replace
ment. When breakdown occurs, the
system should find available replacement and put it to use. The system should be able reroute
vehicles on a run which is along a route which is obstructed in a way that the vehicle is still able to
come to the next reachabl
e station in reasonable time.

7.2.

Use cases

The use case diagrams show some of the usage scenarios of the product derived from Product Line
Core. The following are the actors in our system:



PTS<<
User

>>

-

The Public Transportation Company using the instance is the User.



PTS<<
External
User

>>

-

The commuters who query the system for travel assistance are the
external users.



PTS<<
System

>>

The system uses some of its own modules, thus it is also a user in our
solution.


Use case diagram (Figure 3) describes the scenarios in which the system will be used for managing
the core elements namely (Stops, Lines, Vehicles and Runs).




Figure
3
: Core entities


use case [6]


9


Use case diagram (Figure 4) describes the scenario of creating and managing schedules, tracking the
vehicles on real
-
time runs and predicts the arrival times according to the
information gathered. Also,
the case of generating timetables for use by passengers is included. Passenger queries regarding the
possible (quickest) lines between two stations and which runs are suitable for travel.

Use case diagram (Figure 5) covers the special occasions and emergencies to be handled by the
system. It also includes the scenario of replacing the vehicles which are not fit for runs.



Figure
4
: Timetables and passenger assistance


use case [6]

Figure
5
:
Emergency handling


use case [6]


10


8.

Architectural Design

The archite
cture that we have designed is multi
-
layered. Each of the instances has to be multi
-
layered. It has to have core domain logic layer, user interface and may have data persistence layer.
Layers can be added based of the complexity of the instance.

Layered ar
chitecture decision is largely based upon the fact that one of the project requirements is
Model Driven Development. Thus architectural design has been a key point of the development
throughout the whole project. Having AUP as our process, we have divided
model development into
iterations. During each of the iterations we have expanded or modified the model.

Having architectural design divided in iterations, we have decided to first model information holder
classes which we can use in modules which were cre
ated later.
Since

we need to separate the
management and storage of

the information holder classes
,

we decided to use the repository
pattern. We have created repositories for each entity information holder class, like
StopRepository
for

Stop

entity.

Notice

that the entity classes have direct control only over itself, thus they belong to
the information holder class grade. Usage of repository pattern showed to be useful in later
iterations, as expected.

Each entity class implements
IEntity

interface which de
fines default behavior of entity classes. Having
it defined like that, we could have defined generic repositories. In the end, the usage of generics was
dropped as unachievable (more in section 9).

Not having full control over the domain entities, we decid
ed to introduce entity managers which will
take control over entity definition and collaboration. Building a product line, we had to ensure
that
all

the instances must have the ability to define
their

own control behavior, thus we decided to use
factory pa
ttern. It enabled us to define the functionalities mandatory for each manager. Due to the
same reason, we have built a default manager class for each of the core entities which enables faster
instance making and dispersed control.

Having the concept defined, we could easily add or expand any module. During

the

second iteration
,

we introduced actual timing and passenger assistance
. F
or
this,

we had to define non
-
domain
modules such as math

module
having

support for defining a directed graph and neural network.

Figure
6
: Directed graph

-

class diagram


11


The d
irected graph, as a mathematical representation of a “map

schema” defined by lines, is used for
quickest route optimization, either using scheduled or actual timing.
A

g
raph form

seemed to be the
most suitable solution, due to the fact that a large number of algorithms exist for searching the
shortest path in a graph.

The actual timing module is one of the required modules for emergency handling and passenger
assistance. Both of t
he modules need information about the delay, which is why we have defined
information holders and managers for them. Gathering information about
the
arrival time of a
vehicle to a certain stop is a design decision that has to be done by the instance develo
per.
The
s
ystem presents transparent APIs for that. Vehicle position tracking systems, such as GPS, would
narrow
down the
product line possibilities and reusability.

Prediction of
the
vehicle arrival time to a stop is a good choice and

a

widely used feature in
passenger assistance. Therefore we have decided to put it as a product line shared asset. Neural
network was found to be the best solution for approximation of arrival time functi
on. To ensure
reusability, neural network implementation was not
restricted

to the domain.


During the third iteration, which included instance making, the need for a data persistence module
arose. Thus we have provided a data access layer for storing information about entities. For each of
the core entities, singleton storage class is created wi
th ability to synchronize data between an
instance and a database. To be able to define multiple repositories for the same entity, while using a
Figure
7
: Neural network
-

class diagram


12


database persistence layer, proved to be a problem. Therefore we have decided to narrow down the
data layer cla
sses to a single instance per entity using singleton pattern.

Instance development introduced the need for

a

local
ly

centralized control, which was lacking in the
solution. We had to disable the possibility of making multiple controllers over the same core

entity
which we had achieved by using a singleton pattern over managers.

Figure 8 shows our architecture design in a single class diagram. State
-
chart and sequence diagrams
were not introduced due a limit of pages for initial report. Reader can send requ
est for some
collaboration and behavior diagrams. The figure is divided in sections defined by a color to introduce
control area of a certain class grade. Control includes communication with other entities of its grade
in term of a complete graph, meaning
that each component can collaborate with another at the
same or lower level.

Access points to the domain are managers and should be used for every action over the domain
because they have overall control over the system. Although each class is public, inst
ance should be
using only managers for its activities over the domain. If an instance developer wants to implement
additional functionality, he should add it by overriding closely related manager.


13


-
Information holder classes

-
Repository influence

-
Manager influence


-
Non
-
domain classes




Figure
8
: Product line implementation


class diagram


14


9.

Implementation

This section introduces the methods used, the problems faced and the overall implementation
process. Due to
the
separation of concerns, we have divided
the
Implementation section into two
sections namely,
the
Product Line Core Implementation and Instance I
mplementation.

9.1.

Product Line Core Implementation

Umple can generate executable code either in Java or PHP. Also,
the
Product Line Core had to
(except project requirement fulfillment) fulfill Software Product Line kernel requirements like
reusability, scalab
ility and infrastructure independency.
Keeping

all these in mind, Java was found to
be more suitable by its definition.

The s
trict definition of
language
f
or

code generation enabled us full usage of it
s

language power with
no hesitation on usage of third party solutions. Although narrowing the solution to one language
directly influences its reusability, the embedded code is more understandable, optimized and
powerful.

Umple being

a

modeling language (cl
osely, UML programming language) enabled us to directly code
drawn UML models with the same level of abstraction. It was proven to be very time efficient. For
the whole Product Line Core implementation we have used the Umple language. Having the
restrictio
n that we must not modify Umple generated code, and Umple being under development, in
some cases we had to find workarounds for situations like
a
missing feature for defining generics or
abstract classes.

Following
the
Model Driven Design philosophy and ha
ving
a
powerful modeling

language we could
say that
implementation of
the
Product Line Core is heavily related to architecture designing in a
form of bijection. The realization is done through code generation.

Collaboration and message passing was all crea
ted by Umple’s code generator defined by
associations or as embedded methods. Complexity of embedded methods varied from simple
(object) instance making to complex algorithms such as the quickest route finding. Due to space
limitation
, we will only explain

complex method
s,

namely, a

run generation
and directed graph
implementation (quickest route finding). Manager interaction will be presented on simple example.

Manager collaboration will be shown on a run generation example. Run generation is
a
method (in

RunManager)

used for automatic creation of a collection of runs for a single line
,

based on defined
minutes between consecutive runs, start time, end time and expected duration time. Each run is
created iteratively by calculating start time, which had off
set equal to defined minutes between
consecutive runs (1), and end time based on start time and expected time duration (2). Calculation
formula for each run during iteration:





(

)


{
















(



)











(1)





(

)





(

)









(2)

Figure 9 shows
the
sequence of message passing for creating a single run by
ScheduleManage
r.


15


Finding the q
ui
ckest route

was based on usage of a direct
ed

graph as representation of (current) map

schema. Vertices are stops and
the
edges are rout
es between

two consecutive

stops
. The edge

weight
is
equal to

the

scheduled or actual timing between
the corresponding vertices defined by
stops
.

When
a
request for calculation is received,

a

graph is made out of the current schedule or collections
of on
-
going actual runs. On

the

generated graph
, the

following shortest route finding algorithm
(depth search) was used:

list
of passed vertices and total wei
gh
t

findQuickestRoute
(fromVertex ,
toVertex)


return findQuickestRoute({}, 0,fromVertex, toVertex)


list of passed vertices and total wei
g
h
t

findQuickestRoute
(passedVertices, currentWeight,currentVerex , toVertex)


if( currentVertex == toVertex)


return {passedVe
rtices, currentWeight};


quickestRoute = null


foreach(outgoingVertex)


if(outgoingVertex not in passedVertices)


calculatedQuickestRoute =


findQuickestRoute(passedVertices +
outgoingVertex, currentWeight + weight, outgoingVertex, toVertex)


if(quickestRoute == null)


quickestRoute =
calculatedQuickestRoute


else if(quickestRoute.weight > calculatedQuickestRoute.weight)



quickestRoute =
calculatedQuickestRoute



return quickestRoute



The r
esult

obtained can either be
show
n to

the user or used

internally

by

the

system.


9.2.

Instance Implementation

The decision wa
s made to make three complete and

practically

usable applications

to show the
applicabi
lity of the Product Line Core, rather than three or four console based or dummy
applications. Two of them are desktop applications made with the same goal
s in mind
, but
using
a
different approach. The third instance was introduced to show interoperability of the Product Line
Core with other technologies, in particular .NET technologies.

Figure
9
: Sequence diagram of a single line creation from ScheduleManager


16


Both desktop applications were made using
the
Model View Presenter (MVP) pattern. Due to the
inability of usage of Observer Pattern in Umple, full usage of the MVP pattern is limited. There is no
event passing from the Product Line Co
re to the instance. The instances can only post queries (send
messages) through the managers. Due to the influence of managers and narrowed access, the
Product Line Core and the instance share the role of a presenter. The managers control the access
points
, and the instance specifies the actions to be performed. Figure 10 shows a general
architecture of an instance of the system.

In order to show the variety of possibilities between instances, we chose to use the Product Line Core
DAL for one desktop appli
cation, and the other has a custom implement
ation

of a DAL. Both cases
are working successfully, as was expected.

All three instances are using real data, with one desktop application and the .NET web application
sharing the data.

9.2.1.

Västerås PTS

Västerås PTS
, named after a real city, is an instance implemented for “imaginary” needs of Västerås
public transportation company (
Västmanland Local Traffic Co.). The instance allows the
administration to manage stops, lines, runs and vehicles which belongs to the com
pany.

9.2.2.

Lausanne PTS

Lausanne PTS, based on a real city, is an instance implemented for the supposed yet wide needs of
Lausanne public transportation company. Apart from managing stops, lines, runs and vehicles the
instance supports timetable and schedule ge
neration.

The instance also supports commuter queries
for shortest route between stops and the next available runs to reach the destination.


Figure
10
: Architecture (layered) diagram of desktop
application instances


17


9.2.3.

PTS on Cloud

We have started with the third instance based on .NET framework 4.0 and Windows Azure (Microsoft
owne
d cloud). The instance uses a transformation from the “.jar” file to “.dll” using IKVM tool. This
library is used as a core by the Windows Azure application. Currently, only a small demonstration is
available to show the viability of the instance. The inst
ance can be viewed at:
http://ptscloud.cloudapp.net
.

The idea of this instance is to show the variety of technologies which can be used to instantiate the
Product Line Core. Its purpose is to be used by commute
rs for passenger assistance or by consumers
(third party solutions) for any other the Product Line Core feature. It is using the same data as
“Lausanne PTS” instance.
Details are available in Appendix B.

10.

Verification and Validation

Requirements Verificati
on and validation examine that a software system meets specifications and
fulfills the entire requirement as demanded by the customer. There are dif
ferent approaches to
ensure
the requirement

checking,

such as user manual writing, tracing approaches, proto
typing and
inspections as well as reviews
.

T
he best way
to do this
is through checklists. Our thorough
understanding of the SCORE requirements and discussions with the supervisor verified the
documented requirements. Further clarification and approval from

the customer served as
requirement validation.

10.1.

Design verification and validation

The system

design was verified and validated thr
oughout the development process.

D
ue to our
design decisions, we were able to implement
the intended design

which
was

being o
bstructed by
Umple
’s shortcomings
. Periodic evaluation of the solution and code reviews were carried out to see
that the solution should not be affected due to the roundabout ways used for solving language
problems.

10.2.

Testing

approach

Holding good on the
requirement that the development process

should

be

Test D
riven

Development
,
the deci
sion was made to adhere to unit
testing of the Umple generated Java code as there is no
publicly available tool to test Umple. This was done with

prior

approval from the SC
ORE customer.
Our test reports and Acceptance test plan cover all the test cases.

11.

Something out of the Box

This is something we came up with
,

in the later stages of the project:

We observed that some projects look at the similar domain i.e. Public Transpor
tation, although with
a different perspective. We shared our ideas with another SCORE team
EzFare

(from University of
Zagreb, Croatia and Mälardalen University, Västerås, Sweden).
As

we are working on the same
domain, we
agreed that we
can share our resour
ces to provide computing or storage benefits to the
other project.


18


EzFare Project:
This project is developing an automatic ticketing service for the commuters using
wireless technology. They provide
the real
-
time run
data to the transport company
, and

have

an
accessible interface for the consumers
on an

“as per need” basis.

We intend to use their real
-
time data for our Arrival time predictions and
vehicle
management
purposes. This will provide us a ready source of utilizable and practical data from the fiel
d.
This will
show the reusability in a way that the system can collaborate with a third party solution.

In return,
the
EzFare

team expects us to provide a backbone appl
ication (one of our instances) for Vehicle,
Stop, Line, Run and Schedule management.

Thi
s decision from our teams is bound to lead to a better
,

practical and efficient solution for an actual
system as our features
are complementary
.

We are working together to make a usable API for either
to use each other’s applications without hindering the
working of the others’ application.

12.

Outcomes and lessons learned

To summarize the achievements of our work, we have, together with some additional features,
satisfied all the functional requirements of the SCORE customer [3]. Implemented features are the
shortest route finding, data persistence and prediction of the arrival time of a vehicle to a certain
stop. Although, the prediction of arrival time hasn’t been fully implemented (lacks sufficient data for
learning


making the neural networks). Currently,

the Product Line Core is undergoing revisions
which may result in the expansion of requirements. Three instances are being made, from which two
of them are Desktop Applications and one web application.

“Lausanne PTS” (Desktop Application) and “PTS on
Cloud” (Web Application) share the same data,
but not concerns. Desktop Application is used for the administrative purposes, while Web
Application will be mostly used by commuters (for Passenger Assistance) or consumers (third party
solutions). Currently,

Desktop Application supports the Core requirements and Schedule
management, while Web Application provides none (dummy web page which shows possibility of
combining .NET and Java). “
Västerås PTS
” (Desktop Application) only has support for Core
requirement
s, with usage of custom Data Access Layer (made by the instance developer).

The instances are still under development due to the lack of time and planned work after the
completion of the DSD course. The reader must be warned that this isn’t the final repor
t. The plan is
to finish the development, testing and final report before the SCORE final submission deadline (28
th

of February 2011).

The project was rich in various educational aspects
. Mainly, we gained
practical experience
on
Distributed Development an
d using technology still being under the development
. At the beginning
,

all of us were beginners to the offered Umple programming language
,

with

the majority
having

no
idea about

the

product line development
.
To summarize the learning from the project:



Pra
ctice and
the
understand
ing
of

the Distributed Software D
evelopment

(multicultural)
.



Conflict resolution strategies.



Model Driven D
evelopment approach.



The
Umple programming language.



The Technologies which were used
.


19


13.

Summary

Although the project is not yet complete,
this document will provide an insight

into the Product Line
Core and its three instances which can be useful reference for building a Software Product Line.


All the transportations systems in the world have
common

do
main logic
. Therefore
,

we have
introduced the shared characteristics of those systems into one extensible (core) module


Product
Line Core.

It has been completely developed in Umple modeling language, f
ollowing
the Model
Driven Design philosophy. The p
racticality of the Product Line Core is tested by making three
instances based on its features, each having a different set of requirements (subset of the complete
set). To ensure the reliability of conclusions, every instance has a different architecture,

technology
and dependency on the Product Line Core. So far, the results show that the Product Line Core is
scalable, reusable and reliable.

This project was led by a group of students enrolled in
Distributed Software Development course
(DSD)

which is exec
uted in cooperation between

Mälardalen

University,

Västerås

and the
Faculty of
Electrical Engineering and
Computing, University of
Zagreb
, Zagreb
. The team working on the project
has four members from
Västerås

and three members from Zagreb.
Although this p
roject was started
as a part of the

DSD

course
, we aim to take it further
. I
f we get sufficient results, we will look at
options to base practically applicable software on the developed solution.

While working on the project, each of the team members had
great insight into the Distributed
Software Development. Although the vast geographical, cultural and engineering perspective
difference can be found as difficult to overcome, the variety of solution for a problem results in a
better overall process.

14.

Refer
ences

[1]
Umple home page:
http://cruise.site.uottawa.ca/umple/

[2]
Umple online:
http://cruise.site.uottawa.ca/umpleonline/

[3] Building
Public Transportation System Product Line
,

Timothy C. Lethbridge


(
http://score
-
contest.org/2011/projects/Lethbridge.PubTransSysProdLine.pdf
)

[4] Agile Unified Proces
s, AUP
http://www.ambysoft.com/unifiedprocess/agileUP.html

[5] PTS Project Plan Document

:
http://bit.ly/e9mGGh

[6] PTS
Requirement definition document:
http://bit.ly/flYg09

[
7] PTS Acceptance test document:
http://bit.ly/ehweXC

[8] SCORE website:
http://
score
-
contest.org/2011/

[9] IKVM website:
http://www.ikvm.net/

[10] Windows Azure website:
http://
windows.azure.com




20


15.

Appendix A:

The
Umple language

Umple is a modeling language

derived from UML (using Umple, the user can create UML diagrams
textually [1]). It allows coding at the same level of abstraction as modeling
, while

still being able to
generate corresponding executable code. Java or PHP code can be generated. It is found

to be very
useful because it shortens time between modeling and implementation

Coding the designed architecture is still subject to mistakes, but using Umple one can be assured of
proper code in a way that it corresponds with desired design. Any additiona
l coding or usage of third
party solutions can be embedded into Umple code directly.

Umple is still under development so it lacks some of the needed features, like:



Abstract classes



Inheritance of multiple interfaces



Usage of generics



Graphic editing and c
lear error messaging

Simple example:





class Stop{


name;

}

class Line{


name;


1
-
> 2..* Stop;

}


Figure
11
: Example for Umple (
U
mple code and corresponding
Class diagram
-

from Umple Online

[2]
)


21


16.

Appendix B


PTS PL
Instance on Cloud

The instance based on Cloud Computing is not yet complete. We are shaping the final feature set and
design of the instance. The following is the planned architecture design of the solution instance:


This is a representation of the Insta
nce architecture:

1.

Umple code is the code written for the Product Line

2.

PTSDomain.jar


This is the compiled product line in a library.

3.

PTS Cloud


It is the application running on Windows Azure and based on .NET 4.0.

a.

Web Role


It is the web application whi
ch has a browser accessible HTTP interface.
It is the web application which will be used by administrators for administration and
data management. Also, the passengers will use the same application for various
passenger assistance services.

b.

Neural Network
Learning Background service


This is a background service which
will do the learning process for the neural networks which will be used for arrival
time prediction.

c.

Web Service (Background service)


This service will have and endpoint which will be
acces
sible to the EzFare SCORE project (Transport for you). This will allow them to
take the core data from our system in a controlled way and will give us real
-
time
data from their application.

The reason to use a cloud computing platform for the third instanc
e was to demonstrate the
scalability of a solution based on the system. The instance (when complete) will be ready to be
instantly deployed in a production scenario.

The system is currently accessible at
http://
ptscloud.cloudapp.net
. The current packa
ge simply
displays data from our system. Further features are being added.