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 of 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.
Requirement Specifications............................................................................................................. 7
7.1.
Design story ............................................................................................................................. 7
7.2.
Use cases ................................................................................................................................. 8
8.
Architectural Design ...................................................................................................................... 10
9.
Implementation ............................................................................................................................. 14
9.1.
Product Line Core Implementation ....................................................................................... 14
9.2.
Instance Implementation ...................................................................................................... 15
10.
9.2.1.
Västerås PTS .................................................................................................................. 16
9.2.2.
Lausanne PTS ................................................................................................................. 16
9.2.3.
PTS on Cloud .................................................................................................................. 17
Verification and Validation ........................................................................................................ 17
10.1.
Design verification and validation ..................................................................................... 17
10.2.
Testing approach ............................................................................................................... 17
11.
Something 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. 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
implementation.
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 specific 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, as 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 complications. 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 Product 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.
1
2. Problem Statement
The Public Transportation System 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 project 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/Domain 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 modified runs.
Passenger Assistance and Real-time tracking: The system should be able to generate timetables 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 runs 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 Tracking 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 operating 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, implementation, 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 requirements. “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.
2
4. Scope 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 positive 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 the 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 support 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 be the one most suitable for us. The Agile Unified Process (AUP)
proved to be effective in all regards.
Figure 1: incremental release-based development [4]
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 process 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.
3
6. Project plan
Our sevenfold multi-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 project 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 with 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
Project preparations
W39 W40 W41 W42 W43 W44 W45 W46 W4 W4 W4 W5 W5 W5 W0 W0
7
8
9
0
1
2
1
2
Requirements analysis &
definition
Requirements Prototype
33Architecture
Design System
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
Augustin Petrović
AP
Uma Shankar Subramani
Hafiz Umer Waqar
Siva Chaitanya Nayak Eslavath
Manish Kungwani
Pratik Bapurao Barkade
Omar Tawffeeq Jaradat
US
HU
SC
MK
PB
OJ
Responsibilities
Model and Java Developer, SCORE representative and
Technical writer
Java Developer
Java Developer, Database Developer
Technical writer
Model and Java Developer, Technical writer and Team Leader
Graphic designer and SVN Manager
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 development process [5]:
4
Possibility
Scenario
High
The Umple language is still
under the development so
there might be occasional
bugs.
Waiting for the bug-fixes or
finding workarounds could
delay the whole project
workflow.
Manually editing the Umple
generated code, with the
permission 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.
Expanding Communications Plan
or helping team members to
improve their communication
skills. In a case of conflict, the
resolution must be achieved as
soon as possible.
Low
Unexpected 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.
Sickness absence.
One or more members get
sick because of which they
quit the project for a while.
Increasing the working hours for
the rest of team members.
Low
Risk
Preventive action
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. Project management was not correlated only to the project
manager, 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.
5
Figure 2: PTS communication structure [5]
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 communication 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 twice 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 members to collaborate without allowing content-conflicts to bubble up. The
University of Zagreb also hosts a page on its website to allow team members to store the documents
related to the project. Project specific announcements were 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-mails.
6
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 gauging 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 not 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 transportation 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 defining 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,
based 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 passenger 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 vehicle 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 inform the
7
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 available 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 replacement. 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 reachable 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.
Figure 3: Core entities – use case [6]
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).
8
Figure 4: Timetables and passenger assistance – use case [6]
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.
Figure 5: Emergency handling – use case [6]
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.
9
8. Architectural Design
The architecture that we have designed is multi-layered. Each of the instances has to be multilayered. 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 architecture 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 created 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 defines 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 decided 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 pattern. 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. For 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
10
The directed 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 graph 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 the 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 developer. The
system 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 function. To ensure
reusability, neural network implementation was not restricted to the domain.
Figure 7: Neural network - class diagram
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 with ability to synchronize data between an
instance and a database. To be able to define multiple repositories for the same entity, while using a
11
database persistence layer, proved to be a problem. Therefore we have decided to narrow down the
data layer classes to a single instance per entity using singleton pattern.
Instance development introduced the need for a locally 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 request 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, instance 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.
12
-
Information holder classes
-
Repository influence
-
Manager influence
-
Non-domain classes
Figure 8: Product line implementation – class diagram
13
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 Implementation.
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, scalability and infrastructure independency. Keeping all these in mind, Java was found to
be more suitable by its definition.
The strict definition of language for code generation enabled us full usage of its 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 (closely, 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
restriction 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 having 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 created 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 methods, 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 offset 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:
𝐷𝑒𝑓𝑖𝑛𝑒𝑑 𝑠𝑡𝑎𝑟𝑡 𝑡𝑖𝑚𝑒, 𝑛 = 0
𝑆𝑡𝑎𝑟𝑡 𝑡𝑖𝑚𝑒 (𝑛) = {
𝑆𝑡𝑎𝑡 𝑡𝑖𝑚𝑒(𝑛 − 1) + 𝑜𝑓𝑓𝑠𝑒𝑡, 𝑛 > 0
(1)
𝐸𝑛𝑑 𝑡𝑖𝑚𝑒 (𝑛) = 𝑆𝑡𝑎𝑟𝑡 𝑡𝑖𝑚𝑒 (𝑛) + 𝐸𝑥𝑝𝑒𝑐𝑡𝑒𝑑 𝑑𝑢𝑟𝑟𝑎𝑡𝑖𝑜𝑛 𝑡𝑖𝑚𝑒
(2)
Figure 9 shows the sequence of message passing for creating a single run by ScheduleManager.
14
Figure 9: Sequence diagram of a single line creation from ScheduleManager
Finding the quickest route was based on usage of a directed graph as representation of (current) map
schema. Vertices are stops and the edges are routes 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 weight findQuickestRoute(fromVertex , toVertex)
return findQuickestRoute({}, 0,fromVertex, toVertex)
list of passed vertices and total weight findQuickestRoute(passedVertices, currentWeight,currentVerex , toVertex)
if( currentVertex == toVertex)
return {passedVertices, 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 result obtained can either be shown to the user or used internally by the system.
9.2. Instance Implementation
The decision was made to make three complete and practically usable applications to show the
applicability 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 goals 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.
15
Figure 10: Architecture (layered) diagram of desktop application instances
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 Core 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 application, and the other has a custom implementation 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 company.
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 generation. The instance also supports commuter queries
for shortest route between stops and the next available runs to reach the destination.
16
9.2.3. PTS on Cloud
We have started with the third instance based on .NET framework 4.0 and Windows Azure (Microsoft
owned 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 instance 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 commuters 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 Verification and validation examine that a software system meets specifications and
fulfills the entire requirement as demanded by the customer. There are different approaches to
ensure the requirement checking, such as user manual writing, tracing approaches, prototyping and
inspections as well as reviews. The 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 throughout the development process. Due to our
design decisions, we were able to implement the intended design which was being obstructed 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 Driven Development,
the decision 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 SCORE 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 Transportation, 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 resources to provide computing or storage benefits to the
other project.
17
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 field. 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 application (one of our instances) for Vehicle,
Stop, Line, Run and Schedule management.
This 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
requirements, 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 report. 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 and 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:





Practice and the understanding of the Distributed Software Development (multicultural).
Conflict resolution strategies.
Model Driven Development approach.
The Umple programming language.
The Technologies which were used.
18
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 domain 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, following the Model
Driven Design philosophy. The practicality 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 executed 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 project was started
as a part of the DSD course, we aim to take it further. If 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. References
[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 Process, 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
19
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 additional 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 clear error messaging
Simple example:
class Stop{
name;
}
class Line{
name;
1 -> 2..* Stop;
}
Figure 11: Example for Umple (Umple code and corresponding
Class diagram - from Umple Online [2])
20
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 Instance 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 which 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
accessible 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 instance 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 package simply
displays data from our system. Further features are being added.
21