Embed Size (px)
Citation preview
Studieprogram:
Post adresse: Postboks 4 St. Olavs plass, 0130 Oslo
Visit adresse: Holbergs plass, Oslo
PROJECT NR.
0920
ACCESSIBLE
Till 17.07.2009
Telephone: 22 45 32 00
Fax: 22 45 32 05
Main project for bachelor’s degree
TITLE
Battery analysis application for electric cars
DATE
29.mai 2009
NUMBER OF PAGES
/APPENDIX
119 / 3
STUDENSTS
Ali Emre Yildirim - s135573
Danh Le Cong Tran – s141712
Vibeke Askeland – s141436
Kevin Johnny Galåen - s135768
TUTOR
Eva Hadler Vihovde
EMPLOYEE
Think Global AS www.think.no
SUPERVISOR
Bente Øvsttun Ditman
SUMMARY
The object for this project was to make a prototype for a web application that could perform analysis on
batteries. Our product was developed from ground and is meant to be a good framework for further
development. An important point is that the technologies should be open source.
We chose to work with scrum method with cycles on 14 days.
According to our employee the prototype meets their expectations.
It was important for our employee that working tools should not put any limitations for further development.
Working tools we have used does have awide range of possibilities. And to our knowledge the working tools
will not make restrictions for further development on our application.
3 HEAD WORDS
Battery analysis electrical cars
Web application open sourse
Java Servlet Faces, Rich Faces
Page 1 of 119
Documentation In your hand is the documentation for the main project for the bachelor degree at Oslo
University College, group 20 springs 2009. Project is called “Battery analysis applicaton for
electric cars”. Our employee was electrical car producer Think.
Altogether this project consists of a compact disc with our prototype, this documentation
and an oral presentation. Source code for the prototype is to be found at the compact disk.
As basis, when designing this rapport, we used former teacher Ann Mari Torvatten’s
standard for writing documentation. Former bachelor Former bachelor rapports made at
HIO and rapports we goggled gave us ideas of how we could form this documentation.
Potential readers of this document
This document is made for those who want to use or evaluate our project and our
suggestions for further development. For this evaluation we assume our readers to have
basic knowledge in computer science. Engineers or system administrators may want to
install the prototype. Developers may want to maintain, modify the system and do further
development. Final, this documentation is made for tutors and sensors that want to evaluate
our work.
Think consider the collected dataset confidential information. Ideas and our findings for this
program may also be of confidential importance. Others than Think employees and trusted
employee at Oslo College, HIO, will therefore probably not read this document.
How we got this project:
Vibeke became acquainted with senior engineer Egil Piene Falck trough friends. He
suggested her to consider applying for a main project at Think.
When project came up the group called Egil.
We, the students wanted a programming task for our main project and Egil Piene Falck got
us in touch with Bente Ditman at Think. She gladly formed an idea of a project for a
prototype/software that could come in handy for Think. More information you’ll find in
process documentation section 11.
Page 2 of 119
How to read this document:
The present document is the introduction to our project. Altogether the documentation can
be read as a standalone document, but not necessarily. Some reader may want to go directly
to a desired topic. We hope we have managed to make good tables of contents and indexes
to support this whish.
There are three main themes; product-, test-, and process documentation. The appendixes
are: requirement specification, user manual and installation instruction. To oblige some
sensors whish; these four sections can be read separate or as standalone documents. Each
of these parts has therefore been given its own preface, instruction to how to read the
section and detail table of contents. When more elaborator information exists elsewhere in
the documentation references is given.
Documentation consists of 1 document and 3 appendixes. Process rapport describes the
work we have done. Required specification tells in detail what demands our employee have
for our prototype. Detailed information about the prototype you will find in the product
documentation. Test documentation is a rapport on which tests we have performed on our
prototype and test results.
We wanted to shorten down rapport and avoid too much redundancy. Therefore we made
one extended version and put it in the start of process document. Product documentation,
has been given a short version with sufficient information. References are given to process
documentation for those who want an extend version. We therefore recommend readers to
start with the process documentation. This part gives the most profound approach to the
product. Specification on how to read a document will differ for every part and it may be a
good idea to give it a glance.
Page 3 of 119
Thanks to:
First of all we want to thank Egil Piene Falck for trusting/giving us an assignment at Think.
We also want to tank to Bente Dittman for constructing an interesting project and
supervising our work.
The group also wants to thank our Teaching supervisor Eva Hadler Vihovde for guidens all
the way through the project. She booked a half an hour meeting every Wednesday curios to
see our progress in our project.
Torunn, teacher in databases is a person we also have to pay our respect. We came up with
suggestions for how to design our database. She took the time to see trough our work and
made us confident about our work. She is not our teaching supervisor and still she was
always positive and forthcoming for our questions.
-------------------- -------------------- -------------------- -------------------
Ali Danh Kevin Vibeke
Page 4 of 119
INDEX
Process documentation 5
Product documentation 60
Test report 98
Appendix A: Requirement specification 107
Appendix B: User manual
Appendix C: Installation guide
Page 5 of 119
Process documentation
Group 20:
Ali Emre Yildirim
Danh Le Cong Tran
Kevin Johnny Galåen
Vibeke Askeland
Page 6 of 119
1 Table of Contents
Documentation _____________________________________________________________ 1
INDEX _____________________________________________________________________ 4
Process documentation _______________________________________________________ 5
1 Table of Contents ________________________________________________________ 6
2 Preface _______________________________________________________________ 10
2.1 Bachelor’s degree main project ________________________________________ 10
2.2 Potential audience of this document ___________________________________ 10
2.3 How to read this document: __________________________________________ 10
3 Summary _____________________________________________________________ 12
4 About the company _____________________________________________________ 12
4.1 Norwegian company ________________________________________________ 12
4.2 History ___________________________________________________________ 13
4.3 Technical specifications ______________________________________________ 13
4.4 Free of pollution ____________________________________________________ 13
4.5 Price winning car ___________________________________________________ 13
4.6 Financial advantages ________________________________________________ 14
4.7 Today’s situation ___________________________________________________ 14
5 Background for the project _______________________________________________ 15
5.1 Desires to ease the job ______________________________________________ 15
5.2 Obstacles to overcome ______________________________________________ 15
5.3 Advantages by using bachelor’s students ________________________________ 15
6 System with and without our prototype _____________________________________ 16
6.1 System at Th!nk ____________________________________________________ 16
6.2 What Th!nk wants __________________________________________________ 17
6.3 Advantages with graphical presentation ________________________________ 17
6.4 Important for Th!nk that we should do are: ______________________________ 18
6.5 Plan for the prototype _______________________________________________ 18
Page 7 of 119
6.6 Importance of finding a good development tool __________________________ 18
6.7 Importance of good documentation on the development tools ______________ 18
6.8 Persuasion to get financed ___________________________________________ 19
6.9 Plan for the full version application ____________________________________ 19
7 User interface __________________________________________________________ 20
8 System descriptions _____________________________________________________ 21
8.1 User's perspective __________________________________________________ 21
8.2 Developers perspective ______________________________________________ 22
8.3 Frame complexity and technologies ____________________________________ 23
9 Framework conditions and technologies _____________________________________ 24
10 Selection and evaluation of tools _________________________________________ 24
10.1 Netbeans _________________________________________________________ 25
10.2 Java servlet faces ___________________________________________________ 25
10.3 RichFaces _________________________________________________________ 25
10.4 Glassfish v.2 _______________________________________________________ 26
10.5 Hibernate _________________________________________________________ 26
10.5.1 Mapping files _________________________________________________________________ 26
10.6 CSS ______________________________________________________________ 27
10.6 Table –rich: data table _______________________________________________ 27
10.7 Optimus __________________________________________________________ 28
10.8 Itext ______________________________________________________________ 28
10.9 Poi _______________________________________________________________ 28
11 Thinking process ______________________________________________________ 29
11.1 Finding a group and a project _________________________________________ 29
11.2 Project control _____________________________________________________ 30
11.3 Project is finding its shape ____________________________________________ 30
12 More thoroughly project analysis ________________________________________ 31
12.1 Pre-project ________________________________________________________ 31
12.2 Pre-project rapport _________________________________________________ 31
12.3 Working schedule, progress plan ______________________________________ 32
Page 8 of 119
12.3.1 Inspired to use Scrum __________________________________________________________ 33
12.4 The Group's areas of responsibility _____________________________________ 33
13 Requirement specifications _____________________________________________ 34
13.1 Requirements before change _________________________________________ 34
13.2 Requirements after change ___________________________________________ 34
14 Problem and solutions _________________________________________________ 35
14.1 Problems during planning ____________________________________________ 35
14.2 Understanding the project ___________________________________________ 36
14.3 The project is too big. _______________________________________________ 36
14.4 Understanding variable data from excel files _____________________________ 36
14.5 Making good statistics _______________________________________________ 37
14.6 Not good enough data values _________________________________________ 37
14.7 Could not use Th!nk’s database _______________________________________ 38
14.8 Transfer data from excel sheets to database server _______________________ 39
14.9 Connect to database with hibernate technology __________________________ 39
14.10 Display graphs with values from the database __________________________ 40
15 Possibility for expansions _______________________________________________ 41
15.1 Brilliant choice of technology _________________________________________ 41
15.1.1 Technology extendibility________________________________________________________ 42
15.2 Suggestions for explanations __________________________________________ 42
15.3 Separate interface for different users ___________________________________ 42
15.3.1 Situation for statistics in general _________________________________________________ 43
15.4 Ruff classification of different users ____________________________________ 43
15.4.1 Defining an Administrator ______________________________________________________ 43
15.4.2 Defining an Engineer. __________________________________________________________ 44
15.4.3 Definition of car owners. _______________________________________________________ 46
15.4.4 Defining Sales personnel _______________________________________________________ 49
15.4.5 Defining Finance employees: ____________________________________________________ 50
15.5 Secure login _______________________________________________________ 50
15.6 Map to monitor physically environment and driving pattern ________________ 51
15.7 Rapport system ____________________________________________________ 51
15.8 More than one Y-axis in the same diagram ______________________________ 51
15.9 Interface available for PDA’s and mobile phone. __________________________ 51
Page 9 of 119
15.10 Idea for interface _________________________________________________ 52
15.11 Battery health ____________________________________________________ 52
15.11.1 Standardize battery health for every type of battery individually. _______________________ 53
15.11.2 Long scale for battery health ____________________________________________________ 53
16 Design phase ________________________________________________________ 54
16.1 ER-modeling _______________________________________________________ 54
16.1.1 Now state ___________________________________________________________________ 54
16.1.2 Expansion possibility ___________________________________________________________ 55
16.1.3 Name Convention Database _____________________________________________________ 55
16.2 Web navigation ____________________________________________________ 56
17 Conclusion: __________________________________________________________ 57
Page 10 of 119
2 Preface
2.1 Bachelor’s degree main project
This document is a part of the main project for group 20 springs 2009 for the bachelor
degree at Oslo University College. Altogether this project consists of a compact disc with our
prototype, this documentation and an oral presentation. Source code for the prototype is to
be found at the compact disk.
As basis, when designing this rapport, we used former teacher Ann Mari Torvatten’s
standard for writing documentation. Former bachelor rapports made at HIO and rapports we
goggled gave us ideas of how we could form this documentation.
2.2 Potential audience of this document
This document is made for those who want to use or evaluate our project and our
suggestions for further development. For this evaluation we assume our readers to have
basic knowledge in computer science. Engineers or system administrators may want to
install the prototype. Developers may want to maintain, modify the system and do further
development. Final, this documentation is made for tutors and sensors that want to evaluate
our work.
Th!nk consider the collected dataset confidential information. Ideas and our findings for this
program may also be of confidential importance. Others than Th!nk employees and trusted
employee at Oslo College, HIO, will therefore probably not read this document.
2.3 How to read this document:
The present document describes our working process, one part of documentation for our
bachelor project. Some reader may want to go directly to a desired topic. We hope we have
managed to make good tables of contents and indexes to support this whish.
Page 11 of 119
Process documentation is one of the four main themes in the documentation of the project.
To oblige some sensors whish these four sections can be read separate or as standalone
documents. Each of these parts has therefore been given its own preface, instruction to how
to read the section and detail table of contents. When more elaborator information exists
elsewhere in the documentation references is given. We wanted to shorten down rapport
and avoid too much redundancy. Therefore we made one extended version and put it in the
start of process document. Product documentation has been given a short version with
sufficient information. References are given to process documentation for those who want
an extend version. We therefore recommend readers to start with the process
documentation. This part gives the most profound approach to the product. Specification on
how to read a document will differ for every part and it may be a good idea to give it a
glance
Special for process documentation is the way we have dealt with problems that occurred
during working process.
Problems we found to be of essence have been addressed. First we give an introduction to
the theme. Then we name every problem that hit the surface dealing with the theme. For
every problem we describe how we worked around the problem, the ideas, and the process
and tell why and how we ended up with our solution.
When searching for a problem read the headlines to find right theme. Then go to selected
theme and see if we have dwelt with the problem of your choice. When more elaborator
information exists elsewhere in the documentation you’ll find references.
Page 12 of 119
3 Summary
Our employer was Th!nk, they produce electrical cars. Th!nk develope their cars and
continually try to improve their products. Every cars have a Mind Box installed, a computer
that do registration of, battery charge, battery current etc. Registrations are done and sent
by GPRS technology till a database for storage.
Th!nk has a program called “Maintain server” that would show the data values from the
database, but not a program that would show these data graphically.
Th!nk wanted us to make a prototype that will show the data graphically. Th!nk wanted us
to make a prototype that would show the data graphically. Visually the data could just be
plain fact or statistic based the data from the database.
4 About the company
In this section, we will give a short presentation of the
company Th!nk which is our employee for this project. The
philosophies of a company should be reflected in every
aspect of the company. To know the business is to get a
wider perspective and understanding of its products.
4.1 Norwegian company
TH!NK is a Norwegian owned company making electrical
cars of hard plastic. Th!nk Global AS is located in Aurskog –Høland, Norway, where thay
produce the car. Engineering has offices at IT – Fornebu, Norway. Approximately 200 people
work at Th!nk. Roughly 120 employees work at the production site at Aurskog, and 80
employees at the office at IT Fornebu.
Page 13 of 119
4.2 History
Th!nk was founded in 1991 by Norwegian investors. At the beginning, the company’s name
was PIVCO, standing for Personal Independent Vehicle Company. Later the company was
given the name Th!nk. Th!nk has done development to improve their electrical cars during
18 years. Several prototypes have been made; PIV2, PIV3 or the City Bee and PIV4 which
later was given the name Th!nk. Today they have a good product named “Th!nk City”.
4.3 Technical specifications
The car can drive 180 km on a fully charged Zebra battery. Driving speed is up till 100
km/hour. Safety has been a key factor during construction. Doors have been made using
strengthened steel. Forces from a front-to-front collision will be drawn under the car do to
construction and reduce damage to drivers and passengers.
4.4 Free of pollution
Material of a Th!nk City is 95% re-usable and the el-car does not produce any toxic waste by
being used.
When batteries no longer satisfy requirements for a minimum of battery capacity on a full
charge they will be sold. Potential purchasers are people who need storage of electricity but
do not have limitation do to space.
4.5 Price winning car
Th!nk won the environment price
named “Glassbjørnen” in the category
economic design, in 2003. Th!nk won
because the car is a good alternative
to common and short trips and
contribute to less CO2 waste.
Page 14 of 119
4.6 Financial advantages
There are lots of advantages for electric cars owners. Electrical cars are exempt from taxes
like annual fee. All parking in public-parking places is free to park for owners of electrical
cars, pass toll roads is also free. Insurance of an electrical car is half the price as ordinary
small petrol driven ones. Electrical cars are allowed to drive in the bus / taxi lanes.
4.7 Today’s situation
Development takes a lot of time and money. Situation now in 2009 is that company is
looking for new investors to invest kr160 millions to start production on their latest type
approved car.
There are approximately 450 units of the model Think City worldwide. 90 % of Think City’s
currently produced have been are sold in Norway.
Th!nk has produced and sold about 450 cars of Th!nk city, about 90 % of all the cars drive on
Norwegian roads.
Page 15 of 119
5 Background for the project
In this chapter we will describe the background for this project, why this project is initiated,
and the advantage of allowing students to develop.
5.1 Desires to ease the job
Engineers at Th!nk find today’s system for data analysis awkward and want to make a new
tool that will ease the job.
5.2 Obstacles to overcome
There is not a clear idea of all the
functions that may come in handy
for data analysis, but the engineers
have an idea of some of the
functions this tool definite need.
Finance department do not see the
need of such a tool yet, therefore
aren’t they budget to get developer to make such a tool either.
The objective of this project is not to create a completed application to be put in production
at the project's expiration. The goal is however to build a comprehensive framework to
implement the functions and services to the system.
5.3 Advantages by using bachelor’s students
By letting this being a school project, students do basic analyses for a fully functional
application. Hopefully educational establishment are up to date on the newest and best
technology on the marked. Students may therefore probably find and use the best tools
Page 16 of 119
development for the project. Good support to the project is provided if the tutoring staffs
keep up to date and the students use their knowledge.
By giving someone who are outside Th!nk this project, will gives new ideas and impuls for
how the application may be. Outsiders may see things different and will therefore find other
solutions. Software development takes time. Traditionally software development burst
budget. Students may linger longer with a problem and an idea than a developer that are
paid for hours spent to produce the software. Student developers are not focused on the
financial aspect during development. Focus is to make a good application that will serve our
employees wishes in best manner.
6 System with and without our prototype
This chapter describes existing system andshow advantages with our prototype.
In this section we will therefore tell about existing system and show the place for our
prototype in that same environment.
6.1 System at Th!nk
Th!nk gather battery information. Engineering have a web interface called “Maintenance
server”, to show the data from the database. The web interface does not offer any statistic
presentation or graphical presentation of the data.
To do statistics and show statistics or data display it graphically, engineers use the web
interface to do a selection of the data, Then the selected data are putted in a dump file. The
dump file is imported to excel. Statistics and graphical presentation are done by the tools
offered by the excel software. Below is a figure that shows the current system per today.
Page 17 of 119
6.2 What Th!nk wants
Th!nk engineers wanted us to make a prototype that will show gathered data graphically.
They want to simplify today’s procedure to show data graphically. A way to achieve this is to
make a new web application that work directly on the data from the database. All desired
functions put into one application. This will ease the work for engineers, sales personnel,
and finance employees. See requirement specification appendix and suggestion for
expanding the prototype. There you’ll find more details on what Th!nk wants and what may
come in handy for Th!nk.
6.3 Advantages with graphical presentation Engineers at Th!nk believed that graphical presentation would make the data easier to
monitor. They believed that a human mind to not get the whole picture by scanning
numbers only. Use of graphic will point out several aspects on the same data.
Here are some examples on the different effects engineers believe that a visual analysis will
give; better help to monitoring the batteries, give scientists different ideas for further
development, find better ways to take care of the batteries so they will last longer and
improve battery service.
Page 18 of 119
6.4 Important for Th!nk that we should do are: - Find good open source tool for development
- Make good documentation on those tools
- Make a prototype that allows for easy expansions in the future
- Make good documentation for this prototype
- Make good documentation of our ideas for further development.
6.5 Plan for the prototype
First of all engineers at Th!nk wanted a prototype they can show to financial employees. A
concrete application that they can see, will easier convince them to finance a project to
make a full version of the application. A prototype will also give engineers ideas of what they
want and what they don’t want for the application.
6.6 Importance of finding a good development tool
Second it is important to find a good development tool for the application. Definition of a
good tool for development is a stable and well-arranged framework. The framework must
provide possibilities for expansion rather than limitations. It may be easy to learn, but it has
to be easy to use once you’ll learn the software.
6.7 Importance of good documentation on the development tools
Open source software is not as good documented as software you pay for. We have spent
much time to acquire how to integrate our development tools and how to use them. To ease
apprenticeship for engineers at Th!nk good documentation will be helpful. This is why we
have documented software we have used, how to install and hove to use the software.
Page 19 of 119
6.8 Persuasion to get financed
We have made a prototype so that non-engineers can see the depiction of the potentials of
such of application. An engineer can use our prototype and our ideas to convince finance
employees/ owners at Th!nk, to find further development of this program. And we have
made a report on functions that may come in handy in a future project.
6.9 Plan for the full version application
This is a figure to illustrate how our prototype. By comparing with the figure in Section 6.1.
We’ll see that it is much easier and faster with our application for doing the same job. For a
more detailed description of the application, see Section 8.
Page 20 of 119
7 User interface
The graphical user interface (GUI) has been emphasized when designing, making it user-
friendly. Few colors are used to make a tidy expression. Navigation is made as simple as
possible. Buttons are given intuitive names that will give the user an idea of what to expect if
button is pushed. We believe we have managed to organize the different topic well. The
technologies involved should be relatively easy to learn. See user manual for more detailed
information on navigation and the use.
Page 21 of 119
8 System descriptions
This is an introduction to the process. If you have read the product documentation you’ll find
that this introduction is very similar. We did use similar introductions so that the users could
read these documents as individual documents. This process documentation focuses on
our working process and a sense of how applications work.
We have chosen to introduce the reader to the application in this first part, then we
describe the structure and thereafter the technologies involved, including examples and
explanations.
8.1 User's perspective
It is said that a picture is worth a thousand words, something that is very true especially
when it comes to graphical display of data. It can be very difficult to analyze a collection of
data and form a mental image of it if there isn’t a model or a chart available that can ease
the process. That is why TH!NK wanted a tool to that could generate charts to help their
engineers predict battery life, among other things. They gave us some excel sheets
containing some database raw dump and the task of creating an open-source application
that could create charts so that the data could be displayed graphically.
The application we created will help users to retrieve data from database(s), display those in
different charts and generate basic statistics. It is also possible to view raw dump from the
Which of these
would give you
the most
analytical
value?
Page 22 of 119
tables and export results to PDF and Excel files. In addition, we have developed the
application using only well-know and well documented open-source technologies for the
fundamental parts. This is because we don’t want other developers to have a hard time
improving the application.
The application is an emphasis on user friendliness, a simple design with neutral colors and
self-explanatory text.
8.2 Developers perspective
We have chosen technologies and developed the
application with extendibility and developer-
friendliness in mind. We have separated the
different tasks in the application as much as
needed in order to achieve what we believe gives
the most “developer friendliness”. For instance,
Facelets provide the content for the web-pages,
XML files configure the applications technologies,
navigation etc. Our CSS files define the pages’
layout, Java beans contain the Java code and
Hibernate takes care of database connection and
querying.
We want developers
to see this…
…Instead of this
Page 23 of 119
8.3 Frame complexity and technologies
First of all, TH!NK told us to use open-source technologies exclusively. We used lots of time
researching technologies that could meet the needs and picked them with care. Our product
was developed from ground-up by use of those technologies and is meant to show how
things can be done using these. It is supposed to be very accessible for other developers who
want and/or must improve it in the future. That is the reason we chose well-known and well-
documented technologies like JSF, Hibernate, RichFaces and Facelets as a fundament for the
application. The figure below shows the technologies involved and is a simplified model of
the “layers” that they are used in.
Java Server Faces (JSF) is the framework of the application and takes care of the
fundamental things like managing pages, beans, technologies, libraries, page
navigation etc.
Hibernate is powerful database querying service, that most importantly (for TH!NK)
lets the user query and swap between databases with ease. It currently connects to
our Derby and MySQL test databases.
Facelets is the ViewHandler (Which is Java Server Pages by default, but we switched
to Facelets) that is used to “view” the other components mentioned below
Page 24 of 119
Richfaces provide the “main-components” of our application, such as tabs and panel
bars
Chartcreator provides the charts using datasets created from Hibernate querying
Itext, Optimus and Primefaces are currently used for saving to PDF and Excel.
For a more detailed description of the technologies, read Section 10 in the process
documentation and Section 6 in product documentation.
9 Framework conditions and technologies
They would not limit us by using of specific technologies or solutions as long as it is open
source.
We went for Java servlet faces as framework, with richfaces coponent, hibernate database
connecting with mySQL language, and java as programming language because it satisfies the
requirement from the employer that it should be open source.
Frame conditions are further defined in requirements. Given technologies are described in
the product documentation section 5.
10 Selection and evaluation of tools
In this chapter we present the tools that have been used during the development of the
system. Then, we approach and justify the selection and evaluation of technology tools.
Page 25 of 119
We had to choose open source solutions; this is common feature for all of the technologies
mentioned below. In any case it was a more tricky option using open source software than
using a well-documented pay-solution from par example Microsoft.
10.1 Netbeans
NetBeans is a framework for developing Java applications, among others. A development
tool that has some useful plugings. NetBeans is compatible with most platforms. We used
different pluging features glass fish, java server faces, facelets, hibernate. The purpose of
NetBeans is to create an easy environment for developing software. NetBeans has project
management, version controls and supports the integrated debugging which is very
important for us in connection with testing and debugging.
10.2 Java servlet faces
(JSF) is a Java-based Web application framework intended to simplify development of user
interfaces for Java EE applications. Unlike request-driven MVC web frameworks, JSF uses a
component-based approach. The state of user interface (UI ) components is saved when the
client requests a new page and restored when the request is returned. Out of the box, JSF
uses JavaServer Pages (JSP) for its display technology, but can also accommodate other
technologies (such as XUL and Facelets).
10.3 RichFaces
RichFaces is a rich component library for JavaServer Faces built on the open source
framework Ajax4jsf. It allows easy integration of Ajax capabilities into enterprise application
development.
RichFaces enriches the Ajax4jsf framework in two ways. First, it expands the number of
visual ready-to-use components. Secondly, it implements the skin ability feature of the
Ajax4jsf framework including a large number of predefined skins. Using skin ability, it is
easier to manage the look-and-feel of an application.
Page 26 of 119
10.4 Glassfish v.2
Glassfish is an open source application server project led by Sun Microsystems for the Java
EE platform. The commercial version is called Sun GlassFish Enteprise Server.
GlassFish is free software, dual-licensed under two free software licenses: the Common
Development and Distribution License (CDDL) and the GNU General Public License (GPL) with
the class path exception.
It uses a derivative of Apache Tomcat as the servlet container for serving Web content, with
an added component called Grizzly which uses Java NIO for scalability and speed
10.5 Hibernate
Hibernate is a Object Relational Mapping (ORM), and is a framework that makes it easier to
communicate with a relational database from an object-oriented environment. Orm takes
care of storing data from objects in the database when necessary, and extract the data and
place them in the object when necessary. To save our group for a lot of unnecessary coding
in the application, we chose to use ORM-technology that makes it possible to communicate
to the database. We chose to use Hibernate because this type of ORM-technology makes it
possible to change the database easily at a later date if desired. Hibernate is one of the most
popular ORM tools for Java, and works very well with the Java server facelets Framework.
We refer to the chapter about Hibernate in the product documentation section 6.6, for a
more detailed explanation about this.
10.5.1 Mapping files
Hibernate need to know how an object from a java bean to be retrieved and stored. It was
here mapping came into the picture. A mapping document is an xml file that tells what table
Page 27 of 119
in the database is a java class to relate to and the column in the table to be used. There are
different ways to use the mapping, either save all the objects in a file or select the mapping
file for each object. Since we had not too many objects to keep track of, we went for a
separate mapping for each object. The advantage of having each object in its own mapping
xml file was that it was easier to find errors if it arose.
10.6 CSS
CSS stands for Cascading Style Sheets
Styles sheets define HOW HTML elements are to be displayed, just like the font tag and the
color attribute in HTML 3.2. Styles are normally saved in external .css files. External style
sheets enable to change the appearance and layout of all the pages in your Web, just by
editing one single CSS document!
CSS is a breakthrough in Web design because it allows developers to control the style and
layout of multiple Web pages all at once. As a Web developer can be define a style for each
HTML element and apply it to as many Web pages as wanted. To make a global change,
simply change the style, and all elements in the Web are updated automatically.
There are many reasons that made that we chose to use css. We used css because it can
saves a lots of work, paged load faster, redesign will be cheaper and more effective, Better
results in search engines. And those things meet the employer's requirements.
10.6 Table –rich: data table
The <rich:dataTable> component is similar to the <h:dataTable> one, except Ajax support
and skinnability. Ajax support is possible, because the component was created basing on the
<a4j:repeat> component and as a result it could be partially updated with Ajax. "ajaxKeys"
attribute allows to define row keys that is updated after an Ajax request. We used this
technology to show data values on a table.
Page 28 of 119
10.7 Optimus
Optimus module provides solutions to ease the development with JSF. Optimus removes the
burden of XML from JSF by providing an annotation based IOC container based powered by
Google Guide and an XML-less Navigation Handler that removes need for xml-based
declarative JSF navigations. Optimus also provides persistence support with JPA integration.
We used optimus to Excel and PDF export of DataTable contents.
10.8 Itext IText is a free and open source library for creating and manipulating PDF, RTF, and HTML
files in Java. We imported the library in our application. And used it to export graph to PDF
files.
10.9 Poi
The POI project consists of APIs for manipulating various file formats based upon Microsoft's
OLE 2 Compound Document format, and Office OpenXML format, using pure Java. In short,
you can read and write MS Excel files using Java. In addition, you can read and write MS
Word and MS PowerPoint files using Java. POI is your Java Excel solution (for Excel 97-2007).
OLE 2 Compound Document Format based files include most Microsoft Office files such as
XLS and DOC as well as MFC serialization API based file formats.
Office OpenXML Format based files include the new (2007+) xml based file formats,
including Microsoft office files such as XLSX, DOCX and PPTX.
Page 29 of 119
11 Thinking process In general the Thinking process consists of a cost-benefit analysis. Decisions that concern the
size of the project are also dwelt with and so is the system modeling.
The autumn of 2008 our group spent much time to define a self-invented project and to find
out if it was possible to accomplish. A deadline was set for when we it would be necessary to
abandon the self-invented project in favor of one we could finish in the time given. We
passed the deadline and found a new project.
Th!nk granted us a project and then they almost went bankrupt and we had to figure out
whether to find a new project or go for the project given by Th!nk
In the beginning of January all sorted out with Th!nk and we really could start the Thinking
process for the project for Th!nk.
Reading documentation in URL’s sent by employee gave us more ideas for this project
11.1 Finding a group and a project In the spring of 2008 Danh and Ali agreed that they wanted to do the main project together
and asked Vibeke to join them. We had never worked in a group before but we had attended
the same class for two years and felt that we knew each other well.
A year earlier Vibeke had meet Egil, he is a senior engineer at Th!nk who had offered her to
get in touch if she needed a bachelor’s main project. A project at Th!nk seemed quite
interesting but Vibeke already had an idea for a project. She wanted to check it out before
signing up for anything else. If possible, she wanted an interdisciplinary project involving
several disciplines. The project was to turn seawater to freshwater, transport the water fare
distances where it did not rain and produce a green field to harvest vegetables of some kind.
Special field we considered was; chemistry student for the water transformation, machinery
students for transportations trough tubes, agriculture students for choosing which
vegetables to grow and electro students for monitoring transportation. The plan was to find
Page 30 of 119
out if it was possible to realize such a project. The plan was to contact Th!nk if it doesn’t
work out.
When Ali and Danh wanted her in their group she introduced them to her idea. Danh and Ali
liked the idea and a lot of checking where done. The result was that project was too big for a
bachelor’s main project. Probably the project was even too big for a master project. Luckily
we could call Th!nk and hopefully they would give us a project.
We wanted to make software. Fortunately we were given a programming project by Th!nk.
Kevin a schoolmate and skilled programmer joined our group. He was on a group given a
project in server technology. He wanted to do pure algorithms and we wanted him to join
us.
11.2 Project control We wanted to try out the working method scrum. We decided to meet on regular basis 4
days a week. Cycles were set to 14 days in the belief that a short cycle would give us more
control.
We wanted to find out who would be the best scrum master. Every week we swapped the
job as a scrum master.
Ali made a homepage where we could put all our documentation for tutors and employees
to see.
11.3 Project is finding its shape Working with the sketch rapport was important to get the big picture of what this project
was about. We had been given a document from our employee and some links to check up,
but had not attended any meeting with Th!nk at this stage. Group had a good idea of the
project along with a bunch of questions.
Page 31 of 119
12 More thoroughly project analysis
This analysis is done on the system leverage. In this stage models of the system done shows
elements that influence the system as one unity.
Details for every part of the product are not dwelt with in this section.
Analyze was necessary in order to make the pre-project rapport. This rapport made basis for
UML Modeling and finding out where to put limit for our assignment.
12.1 Pre-project In this project the essence of problems shall be determined as accurate and precise as
possible. Key issue is whether the problem can be solved whit in the given premises like
given time and technology at hand
In our pre-project we composed a progress schedule, a plan and diagrams for working plan
in concrete actions and shown by diagrams. It was all put in a rapport called pro-project
rapport.
12.2 Pre-project rapport At our first meeting with our tutor we were advised to write as much as we knew about our
project
Much effort was spent making this rapport getting the text and contents right. Eva Vihovde
our tutor had a few remarks but in general she gave the rapport a god commendation.
Working with the rapport really gave us the clear idea what this project was all about. The
rapport gave us the basis for other rapports to be done in this project. Experience with
recycling text from the pre-project rapport started with the requirement specification.
Working thoroughly with the one rapport paid off.
Page 32 of 119
Technologies to use in this project we had to figure out on our own. A part of the project
was to find open source software for developing our application. This took a lot of time. We
wanted to find the best product; a software that was easy to learn, easy to use and did not
set limitation for the application. We compared different working tools, searched the net
and asked tutors for guidance before we made our choices. See section 6 in product
documentation page for more thoroughly working process.
12.3 Working schedule, progress plan The goal of scrum is ”… to harness creativity, the joy of work, the pleasure of teamwork into
extraordinary productivity in building complex products”
Scrum is an agile development process. In scrum success of product is the primary goal.
Individual success is secondary. Scrum master
Page 33 of 119
12.3.1 Inspired to use Scrum
This figure illustrates how our group prioritized and distributed tasks. It also shows how
many hours we spent on the project of the week and the group's regular meetings as well as
agreements with the tutor and Financed Th!nk.
The group chose to work with Scrum method. We chose to divide work up in different
sprinter. Each consisted of a sprint planning meeting where we selected a theme that we
worked with at the next sprint. In the beginning of each sprint meeting, said each team
member what it has worked with from the previous sprint, and the challenges it may have
had. The group participates in community 3 to 4 times a week at school and had frequent
contact via msn messenger. This was to ensure the quality of progress in the project.
Moreover, we met our tutor once a week and made appointments with Th!nk as needed.
The group has also created a Sprint backlog which we have made a list of things that have to
do with respect to the employer's needs and requests.
12.4 The Group's areas of responsibility We have chosen to let the leadership positions rotate among group members. This means
that each of us headed for a week.
We distributed programming snippet, so that all could program a little. But it was Kevin and
Ali who stood for the most part.
The final documentation was written in the community at the end of the project period.
Page 34 of 119
13 Requirement specifications "The construction phase consists of many iterations, each iteration contains all the usual
lifecycle phases as detailed analysis, design, implementation and testing - albeit at a detailed
level " (Gurholt and Hasle 2003)
Our group wrote the requirements ourselves. Our employer was quite open about how we
could solve the task, but they came with some recommendations. We chose to use the
Scrum process model as this is a model that maintains progress according to the tasks. This is
described in more detail in Section 12.3.
13.1 Requirements before change
We should basically find ingenious solutions to the statistics. And display them graphically on
a graph in a web-based application. After a period of work, the main requirements were
changed by solicitation from an IT employee at Th!nk. This happened during a meeting with
Th!nk. IT employee supposed that the requirements of Th!nk's side was too much for us ..
Faults in instruments registering and faults in collected data prevented us from making
desired statistics. This is described in section 14.6.
13.2 Requirements after change During the meeting we agreed to change the requirements. They specified that they would
have a good framework. Functionality earn is not important. Application should basically
connect to the databases, and extract data values, to display graphically on the graphs.
We refer to the final requirements in the attachment.
Page 35 of 119
14 Problem and solutions We were used a lot of time to agree how we would produce the project. And then we
worked hard to learn the various technologies through the tutorials and examples on the
Internet.
It proved to be a challenge to get the various technologies to work to together. As there was
little expertise to find the area was used a lot of time to find solutions to the problems that
arose. It was time to search online and read the books for us to acquire the necessary
expertise. One result of this was that we were supplemented with lots of new facts that
helped us to enhance our technical competence. This project came to the good when the
error messages and technical problems were resolved more efficiently and faster.
14.1 Problems during planning
Problem: Th!nk almost went bankrupt during Christmas holiday 2008
Working process: We had to find out our chances of having a project at Th!nk. Finding out if
consequences for our project at a bankrupt company. Based on findings decide whether stay
with Th!nk or find another project elsewhere.
Solution: It was easier to stay than to find a new potential project.
How: We talked with tutors who had experienced similar situations and therefore could tell
us what we would face. We tried to reach our supervisors at Th!nk to get an idea of our
expectations from them as supervisors.
Why: Finance crisis hitting the marked. We had no guarantee that another firm not would go
bankrupt.
Project did not loose its value as a project over the night. To see our application in use was
our whish. The chance for this to happen with a bankrupt company would be like none.
Seeking another project would steel much time from a working process and our chances of
getting a good degree.
Page 36 of 119
14.2 Understanding the project Problem: We weren’t sure what the project at Th!nk was all about.
Working process: Several themes where goggled to get an understanding for the project;
battery technology, battery health, Th!nk history. Requirement specification from Bente
with some technologies. These technologies to where googled
Solution: We had to meet Bente and Egil to ask them.
How: First we tried to get an idea on our own what this project was all about.
Why: Egil and Bente did not want to answer question via email. They wanted us to gather
our questions and launch them at a face-to-face meeting. They believed this would be time
effective for them.
14.3 The project is too big.
Problem: Amount of work was too much. We had to refine the magnitude of the task
Working process: We read trough the draft and tried to get an idea of what Th!nk required
for the project. We had a meeting with our supervisors at Th!nk to sort out what was the
most importance to do.
Solution: We had to cut down on requirements and let the rest on expand elses
requirements.
How: In the requirement specification, required functions marked R should be implemented.
Desirable functions marked D might not be implemented
Why: The project's scope is too large to carry out during the working time we have at our
disposal.
14.4 Understanding variable data from excel files
Problem: Understanding variable data from excel files
We are not specialists in battery analysis; it was difficult to understand what variables
accounted for.
We got excel documents from Bente with data from the database. It contained 12 variables
form a lithium battery.
Page 37 of 119
Some of the values was not correct and made the data hard to understand. One example
was the variable temperature of the battery more than 4000000 degrees in some of the
entities. We found that fact very hard to understand.
Working process: We studied the different variables in the excel document and tried to
figure out what they report. For the next meeting with Th!nk we announced the questions
we had about the variables.
Solution: We had to meet Bente and Egil to ask them to explain the variables.
Why: To create good statistics, we need to understand the variables from the excel sheet.
How: Bente and Egil explained the different variables thoroughly. Some of the variables had
wrong values. We were asked to make algorithms that cut out variables with wrong values.
14.5 Making good statistics Problem: Hard to decide what statistics to make
We were not specialists in battery-analysis or specialists in statistical-analysis. It would take
the whole semester and than some to learn these subjects.
Working process: We found what variables we needed in order to construct desired
statistics desired by Th!nk. We also tried to figure out what functions and statistics that
would come in handy for employees at Th!nk .
Solution: We did an analysis on what statistics we needed
Why: Th!nk had asked us to give them our suggestion for statistics and functions
How: We had to study the variables, using our knowledge of statistical analysis to make
good statistics.
14.6 Not good enough data values
Problem: Hard to make good statistics based on data we received
Excel dump file we were given had few variables only 12 variables. The time series on
collected data was less then 6 mounts. This made it difficult to produce good statistics based
on the data we got from excels sheets. Lack of important variables led to that we could not
produce meaningful statistics. An important variable that was missing was the mileage.
Working process: We tried to figure out what statistics given data could construct.
We tried to get more information from Bente. We were promised to get more information
but did not receive any.
Page 38 of 119
Solution: We had to meet Bente and Egil and ask them what to do. Our employee wanted us
to consecrate on making a good framework for further development. Specified requirement
had to be changed do to this problem. See 13.3 changes in specified requirements
Why: We had to generate some statistics in order to get something displayed graphically.
How: We made a few statistics based on the data in the database. In order to be able to give
more illustration on what graphs the application could make we made a short cut.
Some of the graphs are generated in the source code.
14.7 Could not use Th!nk’s database Problem: Connecting to Th!nk’s database
Th!nk did not want us to connect directly towards their database in the preface. They got
sensitive data, and it is risky to working directly to their database, because if anything could
go wrong, like deleting data, or crashing the server.
Working process: It exists many database languages and several technologies for database
connector. We tried to find out how Th!nk’s web system connect to the database and which
database language Th!nk use. Th!nk uses PostgreSQL, but did not want to tie us to one
specific database language. They wanted us to choose a solution that would make it easy to
swap from one database to another, par example change from sql to posgreSQL database.
Solution: We had to make our own database, and load it with information in the excel dump
files we got from Th!nk (excel sheets).
Why: We wanted to connect to database server from our web application, to retrieve data
and display graphic.
How: We had to find out how to transfer data into database, and how to connect to the
database from our application. See product documentation for how we did it
Page 39 of 119
14.8 Transfer data from excel sheets to database server Problem: As describe above, we had to find out how to transfer from excel sheets to
database server.
Working process:
We tried to find out which solution we should use. Either try to import in Netbeans, or
making a script (perl) to getting excel sheets with those variables and then transfer to our
databaseserver at school.
Solution / Why:.We decided to use the last one, because this method is the most resemble
way who Th!nk did use today. Also connect to a database and get the information and show
the data on a maintain server.
How: We opened excel-file and convertet it to a textfile. Now we wrote a perlscript.
Problem: There was problems using microsoft excel to convert to textformat, because
windows has hiding characters. The perls script didn’t work, and we used lots of time to find
out of this problem.
Solution: We had to use openOffice to open the excel file, and convert to a text file (cvs.file),
and then run the perl script with the csv-textfiles as argument.
We run the perlscript with the textfile as argument.
14.9 Connect to database with hibernate technology Problem: We had to make our application work with hibernate technology.
Working process: This is a new technology for us. We know that it is hard to set up the
framework, but easy to use. It’s true… We tried lots of tutorials to try to understand how
hibernate works. How to set up, how to map, and how to connect to the database from the
application.
Solution: We connected to our database server with hibernate mapping in our application.
We made a java file, in this file we declared all the variables from the database, and the
getter and setter methods.
We made a hibernate mapping file, in this file, we map the java class, also the object we
have created..
Page 40 of 119
Finally we made a hibernate configuration file, in this file, we wrote what dialect it should
use, (database language), and set up the connection url, username and password to connect
to that database.
Why: We chose hibernate mapping with sql language, because it is the language we are
most familiar with. As we have wrote, it is very easy to change the database language. It can
be done in configuration file, just three lines.
How: In our application, we made hibernate configuration file, and hibernate mapping file.
More specifically is described in the documentation under section Hibernate.
Problem: We got this error message:
org.hibernate.MappingException: Repeated column in mapping for entity:
persistence.Battery2 column: LogID (should be mapped with insert="false" update="false”)
We used many days to find out of this error message.
Solution: We set insert="false" update="false” in the hibernate mappingfile, we
declare it under id column. And didn’t know why it still failed. After some days, suddently we
found out that it should be set under property column=”LogID”, not id column=”LogID”.
This problem is described in more detail in the product documentation in section 6.6.
14.10 Display graphs with values from the database
Problem: We had to display different type of graph, with values from the database were we
created by Th!nk’s data from the excel sheets.
Working process: We had to find out what kind of data we should display on the graph. We
used the requirement specification to decide it.
Solution: We had to make a java bean that can be manipulated visually in the webpage. In
this class we wrote the methodes to do query towards the database.
Why: JavaBeans are reusable software components for Java that can be manipulated visually
in this application.
How: We create a session query towards the database with sql language, and then return
the values by the query.
Page 41 of 119
15 Possibility for expansions
In this section we stress how crucial it was to choose right technology for this project.
Appendix B, the requirement specification, lists desirable functions to expand the
application. Here we dwell with some of the explanations the prototype could need. The
suggestion is explained. Thoughts done around a suggestion is presented. One of the
suggestions is to define a different user interface for different users based on what job they
do at Th!nk. Every user interface is defined and suggestion on what data and statistics they
should contain is listed. Ideas why and why not a statistic should appear are given.
15.1 Brilliant choice of technology
The technology, the tools for development, we have chosen for this project support a range
of possibilities when it comes to further development. Most important is that it supports
every addition our employee wish for. Half of our work was to find a technology for
development and the other half was to make a framework for further development, a
prototype, using that tool. The technology had to be free of charge and it should not bring
any limitations for further development. Limitation for development would make our
prototype less interesting for our employee. It would probably have become a prototype of
no interest at all. Open source software is free of charge. Often it can compete with the best
tools at the marked, but generally there is a lack when it comes to documentation. Video
illustration of how to solve problems is hard to find if it exist at all. Written documentation
you will find, but quality is rarely as good as documentation for licensed software. The open
source constructing tools we have found is competing with the best-licensed software on the
marked. References are given to the tutorials that served us best in process of learning the
working tool. Hopefully these references and our documentation will contributed to
stepwise the learning curve for this technology for our employees.
Page 42 of 119
15.1.1 Technology extendibility
List of some the technologies we recommend for further development
Application that run on mobile phones
Application that run on PDAs.
Additional Java script functionality (improve charts)
Additional Ajax functionality
Flash functionality (which will give much better charts)
See also technology information in the product document section 6 and se the process
documentation section 10 for further information
15.2 Suggestions for explanations
Here is a list of the explanations we dwell with.
Separate interface for different users
For every interface: Define selection of data and statistics.
Making the interface available for PDA’s and mobile phone.
Secure login for every user.
Map to monitor physically environment and driving pattern
Battery health
Rapport system
15.3 Separate interface for different users
Different users have different needs of information. Different users have different
classifications do to security and integrity of data. What facts Th!nk gather is a business
secret. Information on owners of Th!nk vehicles has to be handled with integrity. Therefore
we have defined some of the different users. In order to do a job the different users need a
Page 43 of 119
set of information. We have defined this different sets based on the job a user is supposed
to do. It is possible to define several user interfaces. We made a ruff classification.
15.3.1 Situation for statistics in general
A professor in statistics should be consulted in order to choose the best connections of facts,
the best statistics to monitor. By best we mean choosing statistics that best will reveal the
pattern that takes best care of the battery.
For every user interface we have listed the data and statistics that probably would be of
importance for that user interface engineer to monitor. Comment is to be found for every
statistics. Thoughts and evaluation we have done considering these statistics are reported.
When constructing this project some statistics presented here was not possible to make do
to lack of or faults in gathered information in the database.
15.4 Ruff classification of different users
1. Administrators
2. Car owner
3. Engineers
4. Finance employees
5. Sales personnel
15.4.1 Defining an Administrator
An administrator is the person who is going to add or exclude users. When adding users the
administrator decides what the new user should and should not access. Administrator may
also give clearance to developers on further development or do maintenances.
Administrators possess the highest clearance of security and have access to every part of the
application in order to perform his/her job. We have not made a suggestion for the
interface for an administrator.
A system administrator must have full access to every user interface.
Page 44 of 119
15.4.2 Defining an Engineer.
An engineer has several tasks to perform.
For an engineer the primary goal for monitoring the batteries is to find out what to do to
make a battery last as long as possible. Secondary target is to find users who dissent from
the best way to preserve a battery and guide them to do right.
Here it is possible to define several interfaces based on the job to be performed. Not all
engineers need to know who the owner of car they are monitoring is.
15.4.2.1 Get battery to last as long as possible
Th!nk own the batteries and then it’s given that Th!nk want the batteries to last as long as
possible. New batteries coast a fortune. When Th!nk makes a battery last as long as possible
the creation of new batteries is postponed. Therefore this is also contributing to
conservation on the environment.
Based on laboratory tests scientist does have an idea of which elements that preserve a
battery. Monitoring battery information from cars used in their real habitat will give a more
accurate idea of how to take care of a battery in best manner.
Collected data will reveal the pattern of how each car owner take care of their car.
Surveillance of car data stretches only 6 months back in time. Due to the fact that a battery
lasts for 4 till hopefully 10 years result is yet uncovered. In 6 till 10 years from now scientists
will know which pattern that will give the best result.
15.4.2.2 Give guidance to car owners
Car owners that do follow the instructions for taking care of their car will change the battery
perhaps even after four years. By setting up the right statistics to monitor these car owners
may be found and contacted. Hopefully they’ll try to follow given instructions and give the
battery a chance to last longer. If they do not take a hint and start giving the car a better
treat it is possible to charge them different than other car owners. Lower rent on the battery
Page 45 of 119
for car owners who do right may be a decoy. Better interests for insurance for those who
treat their car with care. It is important put a carrot in front and not threatens clients.
Guidance can be automatically generated in the interface for car owners. See further down
on interface for car owners.
If generated messages do not lead to improvement on driving and charging pattern owners
may be contacted manually.
15.4.2.3 List of what to statistics an engineer should monitor
There are several facts and connections of facts to monitor in order to find the best way to
take care of a battery.
Functions to seek for rapports in the archive, weekly, monthly and year reports.
Number of battery cycles (average per day, week, month, year, total)
Chart that can display Y values selected by the user; example: x=time, y=KWh and a
graph that displays usage, other values.
Possible to show more than one graph in the same chart, preferable on top on each
other.
Battery capacity (Current capacity, initial capacity)
Number of complete discharges
Number of complete charges
Top speed
Different owner categories (A,B,C,D, driver categories so that their influence on
battery life can be monitored)
Average speed
Driving time
Info about how much energy that is transferred to the different parts of the car
(heating, air conditioning etc) in order to give more precise information about
battery usage.
Page 46 of 119
Driving distance (average per day, month, year, and total)
Ability to detect whether the battery quality is good or crappy, so that TH!NK, in the
latter case, could contact the owner find a solution to the problem.
Total leasing income so far compared to battery price.
Lifetime so far compared to expected lifetime.
15.4.3 Definition of car owners.
A person who buys an electrical car from Th!nk is defined as a car owner.
15.4.3.1 MyTh!nk: Cost effective and still provide good service
To keep customers satisfied is important. Providing good information and service to
customer is a way to keep them satisfied.
Efficiency is important. In these days when talking of financial crisis it is important to keep
the coast as low as possible. Good service is to provide good information and give the
customer a follow up. Traditionally this consumes working hours of employees, a lot of
hours. Giving the car owners a web interface, the MyTh!nk, can reduce costs and still
provide good service.
Information based on collected data from a car can automatically be generated. Owners
thereby will always be up to date on facts, faults and improvements to be done with their
car. An application could pas on information about approximately anything concerning the
car. MyTh!nk is the working title and perhaps the names of the application that support the
web interface for the user.
Page 47 of 119
15.4.3.2 Advantages with MyTh!nk
Coasts can be kept to a minimum. Car information is generated automatically.
Do to the fact that most of the monitoring is generated automatically faults can be
discovered at a much earlier state. An answer on what to do will also be generated Owners
will therefore be informed what to do immediately.
Brochure and other information material on the car can be found in the application always
being available.
15.4.3.3 List of what to statistics an car owners could monitor
battery status
driving distance
driving time
top driving velocity
average driving velocity
top acceleration
battery cycles
Electricity cost compared to gasoline cost over the same distances
How much CO2 would have been emitted if a gasoline engine did the job?
15.4.3.4 Positive presentation of information
Designing this application one has to carefully select what data to present and how data are
to be presented.
Choosing the right presentation of the car facts will make car owners confident that buying
an electrical car was a good investment. Choosing the wrong way to present the same data
Page 48 of 119
may lead to dissatisfactions. To keep an owner happy MyTh!nk should show facts that point
out what a good investment the Th!nk car was, rather than presenting how good it could be.
15.4.3.5 A statistics that will append a positive welcome
MyTh!nk can present a statistic that shows how economical a Th!nk car is compared to use
of an ordinary car. Variable facts that can be used are how much the owner has used his/ her
car and the oil price and price of electricity in that same period.
How much the car has been driven multiplied with the price of the electricity will tell
accurate how much money spent on driving. This can be compared with how much a petrol
driven car would have spent on the same driving length. These kinds of facts may be
interesting and amusing to know for an owner.
15.4.3.6 Two examples that may lead to dissatisfactions:
Every battery is expected to last for a certain amount of time. It may not bee a good idea to
show an owner a statistics on how battery are doing compared with their expectations. This
may be a no good idea especially if their battery is below expectations.
A car with a Zebra battery is expected to drive 180km on one fully charged battery. Over
time this will not be the case. Cells in the battery die. Then the battery is no longer able gain
enough power to take a car 180 km on one fully charged battery. How to present this fact
has to be thought trough carefully. Heavy announcing that the Th!nk car can take you 180km
on one fully charged battery Th!nk will confronted the minute it is not the fact anymore. It’s
all about keeping the car owners happy. How this information is given in sales material and
how it is presented in the MyTh!nk make the foundation on expectations.
Page 49 of 119
15.4.3.7 Functions/ statistics for a car owner
battery status
driving distance
driving time
top driving velocity
average driving velocity
top acceleration
battery cycles
Electricity cost compared to gasoline cost over the same distances
how much CO2 would have been emitted if a gasoline engine did the job?
15.4.4 Defining Sales personnel
A person who sells cars they may also be in charge of advertising the cars.
The person is in direct contact with potential buyers.
15.4.4.1 What sales personnel needs:
A salesman needs information about the different types of cars and what batteries they
use/used. Faults and advantages on both cars and batteries are important. The better
he/she knows the product the better he can serve a possible customer.
Sales personnel need to know facts on why a Th!nk car is a better buy. Facts like who owns a
car is of no significance to their sales job. Such information should be classified do to
integrity and security.
Page 50 of 119
15.4.4.2 Statistics for a salesman
How many cars have been sold last month, last year
How many cars have been sold in total
top driving velocity
top acceleration
Electricity cost compared to gasoline cost over the same distances
How much CO2 would have been emitted if a gasoline engine did the job?
15.4.5 Defining Finance employees:
Employees working with finances have the responsibility to keep the business running. Task
can be calculating what project that would be profitable and which that would not. Sales
campaigns are a task for this department as well. In order to set up budget for the business
they need different facts to , decide what to calculate what to
15.4.5.1 Statistics for Finance employees
How many cars have been sold last month, last year
How many cars have been sold in total
Average life time of a battery
Effects of car owner campaigns “How to take care of your battery” (have average life
time of a battery improved)
15.5 Secure login
Every user should have an account for access to one or a combination of the user faces. Data
in the database are business secrets. Personal information on car owners has to be handled
with integrity. Limit the number of people who have access to certain data will increase the
security and the integrity of the data.
Page 51 of 119
15.6 Map to monitor physically environment and driving pattern
The physically environment the car “lives” in affect the battery information. A car driving up
hill uses more power than a car driving on flat ground if driving distance is the same. Here
there is an ethical question. It is not allowed to monitor and save information on people’s
whereabouts. If a solution could be found on this ethical issue information could be
collected.
15.7 Rapport system
Every week, every month and every year there can be generated battery-rapports. These will
be put in an archive. Users of the system must be able to search for these rapports.
Generated rapports are pre defined, but the settings may be changed if necessary.
15.8 More than one Y-axis in the same diagram
In order to compare graphs it would be a good idea to show more than one graph in the
same chart, preferable on top on each other.
Chart that can display Y values selected by the user; example: x=time, y=KWh and a graph
that displays usage, other values.
It is meaningless to have other values than time as one of the values. Par example: to run
Kwh on one axis and volt on the other gives no meaning.
15.9 Interface available for PDA’s and mobile phone.
Providing an interface available for PDA’s and mobile phone will provide more service for
people on the run.
Page 52 of 119
15.10 Idea for interface
All of the user faces could be integrated in one interface. The different user faces all appear
in the same user interface. Information a user is not entitled to then being locked for that
user. If a salesman and an engineer want to discuss a graph it is important that they discuss
the same graph. If everyone has the same interface there is a less chance for
misunderstandings.
15.11 Battery health
Egil engineer at Th!nk asked us to have a look at something called the battery health and
give a suggestion for a solution.
Battery health is described this way: In theory a brand new battery has its maximum health
at the time it leave production facility. A new and fully charged battery can deliver a certain
amount of power. This amount is different for different types of batteries. This amount also
differs between batteries of same type but then at a very low scale. Over time, being used or
being stored it looses its ability to deliver maximum of power. When a battery only manages
to charge 70% of that first fully charge it is to be restored with a new one. The scale of
battery health lay between these two limits. 100% is a fully charged brand new battery and
70 % of that first charge is a “dead” battery.
A standard of how to define battery health technically do not exist.
We were told not to get into battery chemistry since this takes years to learn properly. Texas
instruments operate with a scale of 4. Egil thought that scale had too few levels.
Page 53 of 119
15.11.1 Standardize battery health for every type of battery
individually.
We gave this problem some thought and came up with this solution:
Standardize every type of battery individually.
Today Th!nk uses Zebra batteries. Technology will always improve and Th!nk will replace
Zebra when a better battery hits the marked. The amount of power a battery can deliver will
improve with new technology. A given amount of power cannot be set as a standard for
100% battery health cause this amount changes. A standard can though be set for a type of
battery individually.
15.11.2 Long scale for battery health
The scale for battery health should be long for several reasons. A short scale gives the user
the impression that it takes a long time before the battery is “dead”. A short scale may make
car owners worried or dissatisfied about the power capacity of their battery.
On a brand new and fully charged Zebra battery can take you 180 km. This can be set as a
100% battery health for a Zebra battery.
We thought about whether 0% battery health should be set at 70% of maximum power or
zero% power. A scale from zero power to maximum power gives a longer scale. Battery
health gets bad when it reaches 70% of maximum power but it does not die. It can still be
used. Still, if the scale is presented correctly 70% of the scale represents “bad” health. We
did not make up our opinion where the scale should end, but a long scale gives an illusion
that this battery has a long life.
Example of battery health scale 100%-70%
100-97% 97-94% 94-91% 91-88% 88-85% 86-82% 82-79% 79-76% 76-73% 73-70%
Page 54 of 119
16 Design phase
This chapter describes the product structure of the database with the ER model, the
navigation on the web.
16.1 ER-modeling We had to create a database with Th!nks data values. This chapter describe how our
database is today, and future model of how it could have been.
16.1.1 Now state
This is how our database looks per today. The project was to connect forward to the
database, and take out data from the database, to display it on a graph. In other words, ee
were only used the database to connect forward and retrieve data. Th!nk has its own
database, with more detailed data and values.
Our database has the values shown below, the following is an excerpt we got from Th!nk.
Page 55 of 119
16.1.2 Expansion possibility
As described earlier, this is not essential for our project. But we wanted to make it, to show
that we have thought through how the ER-model could have been, if not Th!nk had a full
pre.
16.1.3 Name Convention Database
Our group chose to use the name convention during the implementation of the database.
This means that we follow a standard and logical structure to implement the database on
the application. By using the name convention, we could all relate to standard rules to use
the case of names and attributes, and the notation and style. This prevented unwanted error
messages and extra work. By using the name convention so it will be easier for a developer
to familiarize themselves with the database and any extended system.
Page 56 of 119
This was the naming convention we followed:
- All table names beginning with uppercase letters
- We decompose name of capitalization, as this improved the readability of each name
- Primary keys always began with the id, then the table name (idBattery)
- Each column in the table began with a small letter
16.2 Web navigation The interface of the web application is as mentioned earlier, simple navigation. Below is a
figure that shows how to navigation hang together.
Page 57 of 119
17 Conclusion: After 10 weeks of implementation we feel that we have created a product that meet the
requirements TH!NK had. Data and generated statistics can be shown graphically, the
program is easy to use and the code is easy to understand. Adding a few sentence of code
does swapping between databases. Additional functionality is easy to add to the application
because everything that is needed to do so is set up. Also note that we have, perhaps with
the exception of chartcreator, used technologies widely known amongst web developers.
Hibernate is extremely flexible and makes database change and querying a dream once it’s
set up. JSF(Java Server Faces) is a Java standard, easy-to-use and highly customizable
framework that every web developer on the planet at least know about. Facelets, in contrast
to Java Server Pages, encourages templating and code reusage which makes the pages more
developer and designer friendly. RichFaces and Chartcreator provide the actual content,
with powerful, editable and good looking components out-of-the-box. These technologies
are open-source and well-documented, which makes further development on the product a
lot easier.
As far as the process goes, only two of us had some experience with JSF beforehand, the rest
was a vast unknown. We worked very hard through both euphoria and deep frustration and
met a lot of challenges. We had to find out what open source tools that was best suited to meet the
needs for our employee. The technologies we had to learn by our self. Our supervisors at Think or our
tutor were not familiar enough with the technologies to give us any support. In the end we must
admit that we are pleased with the product, especially considering the time and experience
we had when the project was initiated. Needless to say, we’ve learned a lot from it both in
terms of programming and planning. We all noticed that for every day that went by, the
easier it was to write, read and understand code and the different technologies involved. In
this constant process of learning we could complain about the lack of time, but the thing is,
very few people are so privileged that they have “enough time”. Furthermore, working
under pressure and making some compromises is something one must learn to do sooner or
later anyway.
The application structure and it’s components can be used by many different companies in
the future. The need for web-based programs that provide graphical representation of data
Page 58 of 119
is huge. Our application can provide this, with some modification, to many different
customers because of it’s flexibility. We’ll also add that this application, being an engineer
application, never had any need for a fancy graphical user interface. However, the use of CSS
files for design and the RichFaces’ skinning ability makes designing/changing layout easy.
With more time available, one could also add more JavaScript and flash technology to the
application to make it look better and to create more interactive charts.
Bente Dittman defined the needs for Th!nk and made this project possible. She is pleased
with the product we deliver. Product can be used as it was supposed to. Particular two
requirements were important. First of all it had to be an application that would give others a
visual idea of what this is and could become. Second it had to be possible and easy to
expand product. Adding functions do changes in design, or do changes in code is examples of
ways to expand the product. Once Bente gets the last version of the product and
documentation she will definitely show it to her superiors and finance employees. Financial
situation at Th!nk exclude the possibility get finances for further development straight away,
but that is just temporally. Everybody at Th!nk believes that Th!nk will outlive this financial
crisis.
Page 59 of 119
18 References
Documentation
http://www.iu.hio.no/~ulfu/hovedprosjekt/dokumenter/dokumentasjonsstandard.pdf
Thor E. Hasle Systemutvikling Applikasjoner og databaser Cappelen akademiske forlag 2008
Software and tutorials:
Frode Eika Sandnes Java for web Tynne og fete klienter Tapir akademisk forlag 2002
http://www.netbeans.org/
Information gathering:
Web application book by Frode
http://www.think.no
The RichFaces page: http://www.jboss.org/jbossrichfaces/
The RichFaces developer guide: http://www.jboss.org/file-
access/default/members/jbossrichfaces/freezone/docs/devguide/en/html_single/index.htm
l
The Chartcreator page: http://people.apache.org/~cagatay/chartcreator/docs/tld/1.2.0-M1-
M2/overview-summary.html
The JfreeChart page: http://www.jfree.org/jfreechart/
Java Server Faces: http://java.sun.com/javaee/javaserverfaces/
The Facelets page: https://facelets.dev.java.net/
The Hibernate page: https://www.hibernate.org/
The PrimeFaces page: http://primefaces.prime.com.tr/en/
The Itext page: http://www.lowagie.com/iText/
Page 60 of 119
Product documentation
Group 20:
Ali Emre Yildirim
Danh Le Cong Tran
Kevin Johnny Galåen
Vibeke Askeland
Page 61 of 119
1 Table of Contents
1 Table of Contents ............................................................................................................. 61
2 PREFACE: .......................................................................................................................... 63
2.1 Bachelor’s degree main project ......................................................................... 63
2.2 Potential audience of this document ................................................................. 63
2.3 How to read this document: .............................................................................. 63
2.4 The product documentation: ............................................................................. 64
3 Summary .......................................................................................................................... 64
3.1 About the company ........................................................................................... 65
3.2 Background for the project ................................................................................ 65
3.2.1 Why this project was initiated. ................................................................................................... 65
4 Introduction:..................................................................................................................... 66
4.1 User's perspective ............................................................................................. 66
4.2 Developers perspective ..................................................................................... 67
4.3 Frame complexity and technologies .................................................................. 68
5 The application structure: ................................................................................................ 70
6 The Technologies: ............................................................................................................. 72
6.1 Java Server Faces: ............................................................................................. 73
6.1.1 Activating JSF: ............................................................................................................................. 73
6.1.2 Page-navigation: ......................................................................................................................... 73
6.1.3 Adding & configuring technologies: ............................................................................................ 73
6.1.4 PhaseListener: ............................................................................................................................. 74
6.1.5 The JSF Lifecycle: ......................................................................................................................... 74
6.2 Facelets: ............................................................................................................ 75
6.2.1 Activating Facelets with JSF: ....................................................................................................... 75
6.2.2 The Template: ............................................................................................................................. 76
6.2.3 The Template-clients: ................................................................................................................. 78
6.3 XML: ................................................................................................................. 79
6.3.1 The Faces-config.xml: ................................................................................................................. 79
6.3.2 The Hibernate xml files: .............................................................................................................. 81
6.3.3 The web.xml: ............................................................................................................................... 82
6.4 RichFaces: ......................................................................................................... 83
6.4.1 Activating RichFaces: .................................................................................................................. 83
Page 62 of 119
6.4.2 Richfaces components we’ve used a lot: .................................................................................... 84
6.5 Chartcreator:..................................................................................................... 86
6.5.1 Creating a chart:.......................................................................................................................... 86
6.6 Hibernate: ......................................................................................................... 87
6.6.1 The hibernate.cfg.xml: ................................................................................................................ 88
6.6.2 The persistent classes: ................................................................................................................ 89
6.6.3 The mapping files: ....................................................................................................................... 90
6.6.4 Querying examples: .................................................................................................................... 91
6.7 CSS: ................................................................................................................... 93
6.7.1 cssLayout:.................................................................................................................................... 93
6.7.2 default.css: .................................................................................................................................. 93
7 Conclusion: ....................................................................................................................... 95
8 References: ....................................................................................................................... 97
Page 63 of 119
2 PREFACE:
2.1 Bachelor’s degree main project
This document is a part of the main project for group 20 springs 2009 for the bachelor
degree at Oslo University College. Altogether this project consists of a compact disc with our
prototype, this documentation and an oral presentation.
2.2 Potential audience of this document
This document is made for those who want to use or evaluate our project, TH!NK developers
and our suggestions for further development. For this evaluation we assume our readers to
have basic knowledge in computer science. Employee at Think may want to install the
prototype. Developers may want to maintain, modify the system and do further
development. Final, this documentation is made for tutors and sensors that want to evaluate
our work.
Think consider the collected dataset confidential information. Ideas and our findings for this
program may also be of confidential importance. Others than Think employees and trusted
employee at Oslo College, HIO, will therefore probably not read this document.
2.3 How to read this document:
The present document describes our product, one part of documentation for our bachelor
project. This document is mainly aimed at the TH!NK developers and requires that the user
knows at least some basic things about programming. To oblige some sensors whish this
section can be read separate or as stand-alone document. This product documentation has
therefore been given its own preface, etc. We wanted to shorten down rapport and avoid
too much redundancy. Therefore we made one extended version and put it in the start of
process document. The version in your hand has been given a short version with sufficient
introduction information. When more elaborator information exists elsewhere in the
documentation references is given. We therefore recommend readers to start with the
process documentation. That document gives the most profound approach to the project.
Page 64 of 119
2.4 The product documentation:
This part of the documentation describes the product and the technologies involved. Our
task has been to create a flexible application that is easy to extend with additional
functionality. The focus of this product documentation will therefore mainly be on describing
architecture, technologies and code so that other developers can pick up from where we left
off. This document is aimed at developers and requires that the user knows at least some
basic things about programming. However, the user-manual describes the application in
detail from the user’s perspective. Also, we have an installation guide that describes how to
run the application and how to import the project to an IDE (“Integrated Development
Environment” such as Netbeans and Eclipse).
3 Summary
Our employee is Think are producers of electrical cars. Think developed their cars and
continually try to improve their products. Every car have a mind box installed, a computer
that do registration of driving distance, battery charge, etc. Registrations are done every 6
minutes and sent by GPRS technology till a database for storage.
Think had a program that would show the different data, but not a program that would
show these data graphically.
Think wanted us to make a prototype that would show the data graphically. Either the data
could just be plain fact or statistics could be run on the data and the result shown
graphically.
Page 65 of 119
3.1 About the company
Think was founded in 1991 and is a Norwegian owned company making electrical cars of
hard plastic. Think Nordic AS settled in Aurskog–Høland, Norway, produces the car.
Engineering has offices at IT–Fornebu, Norway. Approximately 200 people work at Think.
Roughly 120 employees work at the production sight and 80 employees at the office at It
Fornebu.
Material of a Think City is 95% resalable and the el-car does not produce any toxic waste by
being used. On a fully charged Zebra battery the car can drive for 180 km. Driving speed is up
till 100 km/hour.In 2003 Think wan the environment price named Glassbjørnen in the
category economic design. In Norway electrical cars are exempt from taxes.
3.2 Background for the project
In this chapter we will describe the background for this project; why this project is initiated.
3.2.1 Why this project was initiated.
Engineers at Think find today’s system for data analysis awkward and want to make a new
tool that will ease the job. Finance department do not see the need of such a tool just yet
and therefore there are no budget to get developer to make such a tool either. A prototype
is a visualisation of the product. It will hopefully convince management to provide necessary
foundlings.
The goal was to build a framework capable to comprehending implementing functions and
services to the system.
People outside Think probably have other ideas for this project than people who work with
this every day. Using outsiders would perhaps add ideas that did not occur in the mind of
Think employee.
Page 66 of 119
4 Introduction: This is an introduction to the product-documentation. If you have read the process
documentation you’ll find that this introduction is very similar. We did use similar
introductions so that the users could read these documents as individual documents. This
product documentation focuses on further development and therefore mostly explains the
structure of the application, technologies and examples. Reading this documentation will
therefore be much more rewarding if the reader knows some basic things about
programming, but it isn’t strictly necessary.
We have chosen to introduce the reader to the application in this first part, then we
describe the structure and thereafter the technologies involved, including examples and
explanations.
4.1 User's perspective It is said that a picture is worth a thousand words, something that is very true especially
when it comes to graphical display of data. It can be very difficult to analyze a collection of
data and form a mental image of it if there isn’t a model or a chart available that can ease
the process. That is why TH!NK wanted a tool to that could generate charts to help their
engineers predict battery life, among other things. They gave us some excel sheets
containing some database rawdump and the task of creating an open-source application that
could create charts so that the data could be displayed graphically.
Which of these
would give you
the most
analytical
value?
Page 67 of 119
The application we created will help users to retrieve data from database(s), display those in
different charts and generate basic statistics. It is also possible to view rawdump from the
tables and export results to PDF and Excel files. In addition, we have developed the
application using only well-know and well documented open-source technologies for the
fundamental parts. This is because we don’t want other developers to have a hard time
improving the application.
The application is an emphasis on user friendliness, a simple design with neutral colors and
self-explanatory text.
4.2 Developers perspective We have chosen technologies and developed the
application with extendibility and developer-
friendliness in mind. We have separated the
different tasks in the application as much as
needed in order to achieve what we believe gives
the most “developer friendliness”. For instance,
Facelets provide the content for the web-pages,
XML files configure the applications technologies,
navigation etc. Our CSS files define the pages’
layout, Java beans contain the Java code and
Hibernate takes care of database connection and
querying.
We want developers
to see this…
…Instead of this
Page 68 of 119
4.3 Frame complexity and technologies First of all, TH!NK told us to use open-source technologies exclusively. We used lots of time
researching technologies that could meet the needs and picked them with care. Our product
was developed from ground-up by use of those technologies and is meant to show how
things can be done using these.It is supposed to be very accessible for other developers who
want and/or must improve it in the future. That is the reason we chose well-known and well-
documented technologies like JSF, Hibernate, RichFaces and Facelets as a fundament for the
application. The figure below shows the technologies involved and is a simplified model of
the “layers” that they are used in.
Java Server Faces (JSF) is the framework of the application and takes care of the
fundamental things like managing pages, beans, technologies, libraries, page
navigation etc.
Hibernate is powerful database querying service, that most importantly (for TH!NK)
lets the user query and swap between databases with ease. It currently connects to
our Derby and MySQL test databases.
Facelets is the ViewHandler (Which is Java Server Pages by default, but we switched
to Facelets) that is used to “view” the other components mentioned below
Page 69 of 119
Richfaces provide the “main-components” of our application, such as tabs and panel
bars
Chartcreator provides the charts using datasets created from Hibernate querying
Itext, Optimus and Primefaces are currently used for saving to PDF and Excel.
For a more detailed description of the technologies, read Section 10 in the process
documentation and Section xxx in product documentation.
Page 70 of 119
5 The application structure: Below is a model of the application from the developer’s perspective (in NetBeans)
1. The Web Pages folder contain the following:
1.1. This folder contains images that are used or have been used in the application.
1.2. A CSS folder with two CSS files, “cssLayout.css” and “default.css”. These define the
presentation of the webpage content (See CSS at xxx for details about these)
1.3. Facelets .xhtml pages. These are the actual webpage’s of the application. Currently
12 Facelets “clients” and one “template” (See Facelets at xxx for details about
templates and clients).
2. The Configuration files folder contain the following:
2.1. Faces-config.xml which mainly configures beans and actions (See XML at xxx for
details about this file)
2.2. Web.xml which configures JSF and the technologies involved. (See XML at xxx for
details about these)
3. The Source Packages contain the following:
3.1. A default package containing the hibernate.cfg.xml. This file configures Hibernate
and which database it should connect to. (See Hibernate at xxx for details about
these)
3.2. The beans package contains pure Java. Beans that communicate with the Facelets
pages and also standalone Java classes
Page 71 of 119
3.3. The login package contains a couple of login classes that are currently commented
out because they didn’t work properly when we had to stop developing (See 6.1.4
PhaseListener for details about this one)
3.4. The persistence package contains Hibernate mapping files and classes that contain
getters and setters for these (“persistence classes”). (See Hibernate at xxx for details
about these)
4. The libraries folder contains the .jar and library files we have imported to the project.
The files are separated into folders according to which task they have in the application. We
have done almost as much as we can when it comes to separating. One thing we haven’t
done though, that can be done, is to separate text-strings from code into a separate text-file.
We don’t feel that it increase developer friendliness at the moment, but if the application
expands a lot, and TH!NK hire a poet (or someone that can do the job) to write the text-
strings, then that could be an idea so that the person won’t be exposed to code at all.
Page 72 of 119
6 The Technologies:
A section for quick introduction to the technologies was requested by TH!NK. We wrote one
and placed it here as a part of the product documentation because we have used many
examples from our application in it (which also describes the program’s functionality). This
section will cover technology-specific examples and basic descriptions of each technology.
We cannot stress enough the fact that this is just a quick introduction. We can only cover so
much in a short period of time. That’s why we strongly recommend that you read the official
documentations of the different technologies if you want in-depth information about usage
and development (see references).
.
Page 73 of 119
6.1 Java Server Faces: Java Server Faces is the framework and fundament of our application. It is a framework
designed to manage “beans and views”. Part of the reason that we chose it was that it is
extremely flexible when it comes to adding other components and technologies (proven by
the list of technologies we have experimented with!). In short, a simple JSF application
consists of some web-pages, beans (“java classes”) and XML for configuration. Details about
how it used in general and in our application are found in the following pages.
6.1.1 Activating JSF:
In order to activate JSF in the project, the following code is needed in the web.xml file:
The first brick of code finds the engine of the JSF application, the FacesServlet. It is then
named “Faces Servlet” so that it can be called from other methods by name rather than the
full path. This is all that is needed for JSF specifically, though we have made many changes to
the “default” setup in order to activate all of the technologies. In-depth information about
these adjustments is found in the following pages.
6.1.2 Page-navigation:
Page navigation is done by configuring the faces-config.xml file(s). See the faces-config.xml
description in this document.
6.1.3 Adding & configuring technologies:
This can be done in the web.xml. see the web.xml description of this document.
Page 74 of 119
6.1.4 PhaseListener:
Understandig the how the different phases of JSF work is very useful when programming
applications that do more than simply setting and getting strings from a bean. For instance,
we worked on creating a login system that uses JSF’s PhaseListener. It checks whether the
user is logged in at the PhaseId.RESTORE_VIEW phase of the application. If not, it redirects
the user to the login page. This function didn’t work correctly when we had to stop
implementing, but for developers who are interested in improving it, it’s in the project under
the “login” package, deactivated.
6.1.5 The JSF Lifecycle:
We have added a picture to show the lifecycle of JSF, how it processes requests. In order to
get in depth information, see References at xxx.
Page 75 of 119
6.2 Facelets:
Facelets is a highly performant, JSF-
centric view technology. It supports
templating and therefore promotes
code reusability. It uses “Templates”
and “Template-clients” together to
define views. Permanent sections of a
page can stay the same in the
Templates, while the dynamic sections
can be extracted from their clients.
This is an object-oriented approach to
view-design that we strongly
recommend over JSP(Java Server
Pages), which is JSF’s default
“ViewHandler”
6.2.1 Activating Facelets with JSF:
JSF‘s flexibility comes from it’s Application composite, which includes: a default
ActionListener, ELResolver, StateManager, NavigationHandler and ViewHandler. The
ViewHandler takes care of the view/display, but not the actual code and calculation behind
it. Facelets is meant to be used as a ViewHandler represented by the class
com.sun.facelets.FaceletViewHandler. JSF uses Java Server Pages(JSP) by default, which
means that one must specify the FaceletsViewHandler in order to activate Facelets.
In the web.xml the following is done:
Furthermore, JSP pages use the .jsp suffix, while Facelets uses .xhtml, this must be specified
as well:
Page 76 of 119
The initial portion of a Facelets document is shown below. The 4 last sentences are so called
“tagdefinitions” that tells Facelets how to interpret them if you use <f:something> or
<h:something>. It is necessary to add this to each Facelets page (plus additional tag
definitions if other view-technologies are added to the page):
Facelets uses “Templates” and “Template-clients”. In our application we currently have:
One Template called “mainpage-template”.
10 Template-clients that define the actual “content”, which currently is the only
dynamic part of the “mainpage-template”
6.2.2 The Template:
If you’re familiar with ASP.NET the Template can best be described as a Masterpage. If
you’re not familiar with ASP.NET, the word “masterpage” will still give you an idea of what
the template is and does. It defines the static parts of the view while letting its clients take
care of the dynamic parts. These are extracted by the Template when a navigation to a
particular client happens (that’s right, the clients act like individual pages! Meaning that
there is no change in the way the faces-config.xml is used and configured)
Templates uses one or more <ui:insert> tags to inject content from another source. The
other part of the equation is the template-client. This includes documents that use
<ui:component/>, <ui:composition/>, <ui:fragment/> or <ui:decorate/> tags.
There is currently only one template in this project named “mainpage-template”. It defines
the structure of the page and whether the content is defined internally or grabbed from
external “Template-clients”. Our Template currently divides the page in three parts:
Page 77 of 119
The top and left div’s contain the static parts of the page and the content is therefore
defined in the actual Template. Currently, the “left” division of the page contains the menu,
and the top division contain the TH!NK logo. The “left_content”-div on the other hand, is
dynamic, and defined by a “<ui:insert>” tag that grab “content” from the correct Template-
client when the user navigates to a page.
Furthermore, the links to the CSS files are centralized and defined here by these two
sentences:
(For more information about those particular CSS-documents, navigate to “CSS”).
Page 78 of 119
6.2.3 The Template-clients:
The good thing about Facelets is that it promotes code reusability and maintainability by
letting the Template take care of the static parts of a page (instead of doing it the traditional
way of defining EVERYTHING in EVERY web page). The Template-clients on the other hand,
inherit the static parts of the page from the Template, while having an individual definition
for the Templates dynamic parts. Note that they act like individual pages so that you’ll have
to define page navigation in the faces-config XML (see the XML part of this document) in the
same way as one does with traditional JSF/JSP navigation.
These are the main tags of a Template-client document. The ui:composition defines which
template the client should use (in this case, the “mainpage-template”), while the ui:define
defines the content for a block named “content”. Remember that the Template defined a
space for inserting “content” from a client (with the ui:insert tags), but it could have been
named anything as long as the Template and the Template-client operate with the same
names.
Another interesting thing to mention is that you can have templates inside templates inside
templates (and so on), which means that you don’t have to limit yourself to constructing a
two level hierarchy if you feel like having more levels.
Page 79 of 119
6.3 XML: XML (Extensible Markup Language) is, in the perspective of this application, a language that
is used for configuring the technologies involved and the foundation of the application. There
are three different XML files involved at this point: The faces-config.xml file, the web.xml and
the Hibernate configuration files . For detailed information about these files, read on.
6.3.1 The Faces-config.xml:
So far in this project, the role of the faces-config.xml is to manage page navigation and beans
(Basically, the Java classes of JSF). Here’s a couple of examples:
6.3.1.1 Defining beans:
Is a standard code for defining a bean, this has to be done for every bean that is added in the
application. The details:
1. The “managed bean name” is the name that is used throughout the application for
calling the methods written in the class (as in “Battery2.getUsers()” ). This is for the
sake of simplicity, so that developers don’t have to write the whole classpath in order
to call a function. Notice that the name doesn’t have to be the same as the
classname, though it’s always a good idea to use a name that’s self-explanatory.
2. The “managed-bean-class” defines the path to the actual class (classpath).
Page 80 of 119
3. The “managed-bean-scope” is IMPORTANT when diving into the depths of JSF. At this
point, three values are available; application, session and request.
a. The application bean stays alive as long as the application does.
b. A session bean is given to each session (Typically used for login, username
and other “standard” values involved in an ordinary session)
c. The request bean opens and closes for each request, it is therefore the bean
type that is most performance-friendly.
6.3.1.2 Defining page navigation:
Page navigation in JSF is done from actions on the page where the user currently is. The
“action name”(like the “chartredirect” in the code example on the next page) may be
statically defined in the page, or dynamically by connecting a bean that returns a string to
the action attribute based on, for instance , an if-sentence. A code example from our
application is shown on the next page.
Page 81 of 119
The code above is in a Facelets page in our application. The action describes which
“outcome” the XML file should look for when finding a proper response. The XML code that
processes this response is shown below:
Each page in the application may have a navigation-rule; the “from-view-id”, and each
navigation rule may have many navigation-cases. The “from-outcome” part describes which
action that triggers navigation to another view (to-view-id). In this case, the action
“chartredirect” triggers the navigation “to-view-id” chartpage.xhtml.
IMPORTANT: In order to make developer life a little bit easier, we defined the “from-view-
id” with the star symbol, like this:
Which makes the navigation rule “global”, meaning that a developer can define one “global”
navigation-case when making a new page, rather than defining one navigation case for each
navigation rule/page.
6.3.2 The Hibernate xml files:
We decided to create a separate place for these in the Hibernate section. See section 6.6 in
product documentation.
Page 82 of 119
6.3.3 The web.xml:
The web.xml describes how to deploy a web application in a servlet container such as
Tomcat or GlassFish. In general, the more libraries one uses, the larger the web.xml will be
because of the entire configuration that’s needed. Examples of configuration:
Defining that the session will timeout after 30 minutes of inactivity..
For mapping the RichFaces filter in the servlet named “Faces Servlet” (Which in essence is
the engine of JSF, the servlet that contains the pages). The “Faces Servlet” is also defined in
the web.xml by this brick of code:
Once again, the name can be anything, but one must be consistent about the names to avoid
errors and exceptions.
Page 83 of 119
6.4 RichFaces:
RichFaces is a huge component library for JSF, with built-in support for AJAX technology (for
example rerendering a specific part of a page on request, instead of the whole thing). It
saves developers lots of time, and both functionality and look is pretty good out-of-the-box.
6.4.1 Activating RichFaces:
Basically 2 things needed, skin configuration and filter configuration in the web.xml. We are
currently using the following for skin configuration:
The first block defines which skin to be used, Richfaces comes with eight predefined skins:
Default, plain, emeraldTown, blueSky, wine, japanCherry, ruby, classic and deepMarine. We
currently use the classic skin, but this can be changed quite easily by changing the param-
value to one of the other skins. The last block, “CONTROL_SKINNING” makes the RichFaces
skin active for other HTML components in the web-application (Buttons, for instance).
This one is pretty standard, one must tell JSF that the RichFaces filter will process the
requests and where that filter is in order to make Richfaces work.
Page 84 of 119
6.4.2 Richfaces components we’ve used a lot:
Here we will give a quick introduction to the most essential RichFaces components in our
application. If you want to learn RichFaces or just know more about it, we STRONGLY advise
that you check out their official documentation (See references).
6.4.2.1 Rich:tabPanel:
These tags create a panel which can contain tabs that group content on a page. The tabs
have AJAX-functionality out-of-the-box so that one can switch between tabs without having
a full reload of the page. The tabs are created with the <rich:tab> tags. A panel can contain
many of these tags and the code/result might look like this (NB! There is no direct
connection between the pictures):
6.4.2.2 Rich:panelbar:
Very similar to the tabs, the panel is also used for grouping content on a page. The look of
the <rich:panelbar> and the <rich:panelbaritem> can be seen in the picture above to the
right. Here the <rich:panelbar> is inside the “Batteries” tab. The label is set by defining the
“label” attribute in the code. As in:
6.4.2.3 <a4j:support>:
This tag isn’t “visible” per se, but it is very useful! It provides AJAX functionality to existing
JSF/HTML tags. Below is an example of its usage.
Page 85 of 119
Here we have given a traditional <h:selectOneMenu> AJAX functionality by adding the
<a4j:support> tag to it. What it does is that it updates the <a4j:outputPanel> with id=
“graph” whenever the <h:selectOneMenu> is changed (specified with the event=”onchange”
attribute).
There is a free RIchFaces guide on the net that describes every component in detail, refer to
it for more information or additional components that we haven’t used.
Page 86 of 119
6.5 Chartcreator: Chartcreator is the technology we use for creating charts. This is done by creating so called
“datasets” from data collected from the database and specifying them in chart definitions in
the Facelets pages (see “datasource” description on this page). There are several types of
charts that can be used: pie, line, timeseries and bar to more uncommon ones. Chartcreator
uses components from the JFreeChart library, so knowledge of both technologies is
recommended for developers.
NB! See references for the official chartcreator and jfreecharts documentation
6.5.1 Creating a chart:
First of all, notice that the highlighted tagdefinition is needed in the initial portion of the
Facelets page in order to use chartcreator (The rest of those enables the use of RichFaces,
Facelets and JSF components):
When this is done the chartfunction can be specified. In the picture below some of the
attributes available are used (for full list of attributes, see documentation in references).
6.5.1.1 Datasource:
This specifies which dataset it should create charts from. It can be any method in the
javabeans that return a dataset specified in the JFreeChart library (see references for more
information!). The datasets that are mostly used are: XYDataset, DefaultCategoryDataset,
DefaultPieDataset. The XYDataset is used for “timeseries” charts (that is, any line chart that
involves the use of date or “time”). The DefaultCategoryDataset can be used for anything
that has to do with values (doesn’t show dates, though, unless you plot them in yourself).
The DefaultPieDataset can be used for creating Piecharts.
Page 87 of 119
6.6 Hibernate:
“Hibernate is a powerful, high performance object/relational persistence and query service.
Hibernate lets you develop persistent classes following object-oriented idiom - including
association, inheritance, polymorphism, composition, and collections. Hibernate allows you
to express queries in its own portable SQL extension (HQL), as well as in native SQL, or with
an object-oriented Criteria and Example API.“ (from the Hibernate homepage)
We emphasize that Hibernate “translates” queries and adjusts to whatever database you’re
currently using.It is therefore extremely flexible. An additional thing to mention is that
Hibernate, once configured, can swap between databases with almost unbelievable ease.
Though it takes some time to learn Hibernate, it’s a dream to work with when you do. The
files that we mentioned above will be explained in detail on the following pages.
As the picture shows Hibernate acts as a layer
between the application and the database to
ease the developers job when communicating
with it. Hibernate needs a configuration file
(“hibernate properties” In the picture or
“hibernate.cfg.xml in our application), XML
mapping files of the for each table in the
database plus so called “persistent objects” that
define getters and setters for the respective
mapping files.
Page 88 of 119
6.6.1 The hibernate.cfg.xml:
This is where we specify the connection information that Hibernate needs in order to access
the database of the application. If you need to change database, this file is the only file you
need to reconfigure as long as you have mapped the tables and classes correctly. Currently,
the content of the file looks like this:
The different parts of the file explained:
6.6.1.1 session_factory:
The session factory needs connection information to the database(s) so that is can create
database sessions, run queries and so forth. It follows that you need one session factory for
each database that you use. We currently use one database and therefore have one
configuration file with one session factory in our project.
6.6.1.2 hibernate.dialect:
The hibernate dialect tells hibernate which dialect it should “translate” to when running
queries. You may use whatever database you prefer as long as you have a “database driver”
(the next property in the configuration file)
6.6.1.3 hibernate.Connection.driver_class:
This is where you specify which database driver that should be used by the current session
factory. We used a MySQL driver when we used the MySQL database, and currently use
derby “ClientDriver” for the Derby database.
6.6.1.4 hibernate.connection.url:
The url to the database. We currently use a local one, but for the MySQL we used this path
jdbc:mysql://cube.iu.hio.no/s141712. Note: before the path you must specify which
Page 89 of 119
language to use, so id you’d use a postgresql database, the path must have looked like this:
jdbc:postgresql://cube.iu.hio.no/s141712
6.6.1.5 hibernate.connection.username:
The logon username to the database
6.6.1.6 hibernate.connection.password:
The logon password to the database
6.6.1.7 mapping resource:
Defines path to the mapping files (see separate section “the mapping fies” for info about
these). There are two at this point, as seen in the picture.
6.6.2 The persistent classes:
These classes are not required, but recommended design. These classes are basically a
collection of setters and getters for each property in the tables they map. As in:
We currently have two of these: Battery2.java and LoginMap.java that define getters and
setters for the tables “BATT22” and “LOGINTABLE” in our Derby database.
Page 90 of 119
6.6.3 The mapping files:
The mapping files are required for Hibernate to work. Hibernate can access fields directly
without the access methods of the persistence classes as long as the mapping files exist. Our
mapping files currently look like this:
6.6.3.1 Hibernate-mapping:
These tags define the content for mapping a table in the database, in other words, one pair
of these for each table, preferably in separate files in order to keep it tidy.
6.6.3.2 Class:
Defines the path to the persistence class of the table (in this case the Battery2 class in the
beans package), furthermore, the table is specified, “Batt22”, which is the name of the table.
6.6.3.3 Id:
Tells Hibernate which column it should use as Id, which currently is the LogId, Currently
defined as native rather than foreign, for instance.
6.6.3.4 Property:
Defines the columns that should be used and which name they are given, in other words,
which names that is used in the persistence classes for setting and getting them.
Page 91 of 119
6.6.4 Querying examples:
Querying in Hibernate can be done in HQL (Hibernate querying language) or in the native
language of the database. We have done the HQL approach and used two different methods
for getting query result. They are as follows:
6.6.4.1 Arraylist:
This is the method that is used the most. The query result is added to an arraylist: The value
from each row in the database is added to a List, each of those Listnodes contain
elements/results from each row that the query returns as shown below:
Note that Hibernate can make life easier if classes with setters and getters are defined for
each table. The result can then be retrieved by writing, for instance: list.get(i).toString
Page 92 of 119
6.6.4.2 Objectresult:
This is the second method we have used, and also the most preferable. We create a new
instance of the class that define setters and getters for the current table. And then add the
query result to it. The good thing about this is that one can type “Object.getValue()” for any
getter or setter that is defined in the class. For instance:
This was a test we wrote in the beginning of the implementation in order to understand
Hibernate. The lines are as follows:
18 & 19 are Strings to be used in the query at line 24 &25.
Lines 20-22 open a session with the database in order to execute a query.
Lines 23-25 creates a query with parameters from lines 18 & 19 (HQL syntax)
Line 26 checks if there’s a result or not (in the latter case, it out prints “No results!”
Lines 28-32 casts a unique result of the query to an instance of the tableclass (In this
case the LoginMap class with getters and setters for each value in the database). It
then tries to getUSERID() from the result, if not, an “IndexOutOfBoundsException is
thrown and cathed
Page 93 of 119
Lines 35 and 36 aren’t necessary per se, but they do insure us that the session is
flushed an closed (even though Hibernate usually do/is supposed to do this
automatically)
6.7 CSS: CSS (Cascading Style Sheets) is sent to the earth with one IMPORTANT quest, to separate
content from presentation. When one studies old HTML pages, where layout-describing
HTML tags are all over the place and the layout is made by HTML tables, one understand
why CSS files and div-tags are every web-designers blessing! CSS uses rather self-explanatory
tags, so we will not describe these in detail, just show some simple examples. We currently
separate the pages into divisions and let the CSS files describe the actual layout, while the
Facelets pages define the actual content. The layout of the pages is currently configured in
two different CSS files. The cssLayout file is responsible for the positioning of text and
divisions of the pages. The default.css on the other hand, is responsible for the actual text:
fonts, headings and text-sizes.
6.7.1 cssLayout:
The cssLayout file defines the layout of the pages. Our pages are separated into divisions by
the use of div tags. Layout configuration for every div tag is done here, where on the page it
should be placed, whether or not its content should be centered or not, etc. If you’re not
familiar with CSS, here’s an example of its usage:
In the cssLayout file defines the layout of EVERY div tag named “left_content” (found in the
Facelets files)
6.7.2 default.css:
This file describes how the content should look rather than where it should be placed. It
takes care of defining headings, fonts, text-color, font sizes etc. a simple excerpt:
Page 94 of 119
Page 95 of 119
19 Conclusion: After 10 weeks of implementation we feel that we have created a product that meet the
requirements TH!NK had. Data and generated statistics can be shown graphically, the
program is easy to use and the code is easy to understand. Editing a few sentence of code
does satabase swapping. Additional functionality is easy to add to the application because
everything that is needed to do so is set up. Also note that we have, perhaps with the
exception of chartcreator, used technologies widely known amongst web developers.
Hibernate is extremely flexible and makes database change and querying a dream once it’s
set up. JSF(Java Server Faces) is a Java standard, easy-to-use and highly customizable
framework that every web developer on the planet at least know about. Facelets, in contrast
to Java Server Pages, encourages templating and code reusage which makes the pages more
developer and designer friendly. RichFaces and Chartcreator provide the actual content,
with powerful, editable and good looking components out-of-the-box. These technologies
are open-source and well-documented, which makes further development on the product a
lot easier.
As far as the process goes, only two of us had some experience with JSF beforehand, the rest
was a vast unknown. We worked very hard through both euphoria and deep frustration and
met a lot of challenges. We had to find out what open source tools that was best suited to meet the
needs for our employee. The technologies we had to learn by our self. Our supervisors at Think or our
tutor were not familiar enough with the technologies to give us any support. In the end we must
admit that we are pleased with the product, especially considering the time and experience
we had when the project was initiated. Needless to say, we’ve learned a lot from it both in
terms of programming and planning. We all noticed that for every day that went by, the
easier it was to write, read and understand code and the different technologies involved. In
this constant process of learning we could complain about the lack of time, but the thing is,
very few people are so privileged that they have “enough time”. Furthermore, working
under pressure and making some compromises is something one must learn to do sooner or
later anyway.
The application structure and it’s components can be used by many different companies in
the future. The need for web-based programs that provide graphical representation of data
is huge. Our application can provide this, with some modification, to many different
customers because of it’s flexibility. We’ll also add that this application, being an engineer
application, never had any need for a fancy graphical user interface. However, the use of CSS
files for design and the RichFaces’ skinning ability makes designing/changing layout easy.
With more time available, one could also add more JavaScript and flash technology to the
application to make it look better and to create more interactive charts.
Page 96 of 119
Bente Dittman defined the needs for Th!nk and made this project possible. She is pleased
with the product we deliver. Product can be used as it was supposed to. Particular two
requirements were important. First of all it had to be an application that would give others a
visual idea of what this is and could become. Second it had to be possible and easy to
expand product. Adding functions do changes in design, or do changes in code is examples of
ways to expand the product. Once Bente gets the last version of the product and
documentation she will definitely show it to her superiors and finance employees. Financial
situation at Th!nk exclude the possibility get finances for further development straight away,
but that is just temporally. Everybody at Th!nk believes that Th!nk will outlive this financial
crisis.
Page 97 of 119
7 References:
The RichFaces page: http://www.jboss.org/jbossrichfaces/
The RichFaces developer guide: http://www.jboss.org/file-
access/default/members/jbossrichfaces/freezone/docs/devguide/en/html_single/index.htm
l
The Chartcreator page: http://people.apache.org/~cagatay/chartcreator/docs/tld/1.2.0-M1-
M2/overview-summary.html
The JfreeChart page: http://www.jfree.org/jfreechart/
Java Server Faces: http://java.sun.com/javaee/javaserverfaces/
The Facelets page: https://facelets.dev.java.net/
The Hibernate page: https://www.hibernate.org/
The PrimeFaces page: http://primefaces.prime.com.tr/en/
The Itext page: http://www.lowagie.com/iText/
Other potential chart plugins (these are not free)
Fusion Charts:
http://www.fusioncharts.com/?BannerSource=GoogleAdWordsFlashChart&gclid=CNWp06W
b4JoCFYoVzAodylWbBA
GlobFX:
http://www.globfx.com/store/
Page 98 of 119
Test report
Group 20:
Ali Emre Yildirim
Danh Le Cong Tran
Kevin Johnny Galåen
Vibeke Askeland
Page 99 of 119
1 Preface
In this document we describe what and how we have tested application we have
developed. The document is also evidence that our product meets the functional
requirements set in the requirements. We assume that the reader has familiarity with the
system we have developed, if not, then we refer to the report process and product
documentation.
2 Introductions We tested the application with the intent to find and correct mistakes, but also ensure that
the quality of the system is in accordance with our and the customer's expectations.
We have tested the application is constantly under development. At the completion of each
component we made a test plan and performed the systematic testing of the component.
After the components were merged together, we carried out a full application test. We have
also
use of user testing to evaluate the usability of the application.
3 Testing of functionalities Gurholt and Hasle (2003) writes that the functional testing performed by the same person
who has developed the device and that the error should be corrected at once. We have
performed functional testing on the framework and the functionality.
4 System Testing The test will determine whether the application as a whole works out in from an end user's
point of view (...) Here we checks the application to see that is will do as described in the
Page 100 of 119
requirements, ie the functional requirements. (Gurholt and Hasle, 2003)
We have even stood for system testing. We have run the application, and tested all
functional requirements specified in the requirements are met.
Page 101 of 119
5 User Testing The application is web based. It is therefore important that it is simple and easy to use. By
that, wanted we test the usability of the application.
We had, for example, only time for a thoroughfare. Based on Jakob Nielsen and Tom Lauder
research only 5 test persons is needed in order to reveal 75 % of the faults with a system.
Source (Heim 2008)
We formed a test and found 5 test persons in order to reveal faults with our prototype.
Page 102 of 119
5.1 Planning of the test First we found a goal for the test. Then we formed the tasks that test persons should do.
Further we decided what to observe, how the observations should be done and what
questions to be answered by the test person. Student friends of us were asked to be test
persons. The test was then performed. And in the end we studied the results and made our
conclusions.
5.2 The test The goal of our test: We wanted to know if our prototype was easy to learn. Test persons
were given two tasks. Test A find the Bergen on the map. Test B: Test person is going to
generate a statistic. Period has to be from 25.11 2008 to 29.11.2008 the value to monitor is
SOC. Plot the variables given and show the graph. Both test A and B had to be performed
twice. After both test was performed twice test persons were asked what they thought
about the program and if they had suggestions for improvements.
5.3 Testing methodology To avoid affecting the test result one person instructed the test persons and two did the
observations. Kevin and Danh could then observe and not interact with the test person and
affect the test. Vibeke instructed the test persons how to perform the test. They were also
instructed that they could ask her during the test if it was something they did not
understand. They were also requested that they expressed any opinion that might drop into
their head during the test.
Kevin monitored the continuums result like how long time each candidate spent doing the
test. He also noticed comments from the test person and did a subjective observation on
how the candidate behaved during the test. Danh monitored the quantitative results like
how many click a test person used before task was fulfilled.
We asked them some questions about how they experienced the application. Test persons
were tested one by one, so they could not observe each other.
Page 103 of 119
Quantitative and continues and observations were done during the test and answers were
given and they had to perform them twice.
5.4 Continuous observations Results time used to fulfill the two tests A & B twice.
Candidate Mo Younes Diyar Malick Danny
Test A1 55s 57s 34s 102s 31s
Test A2 10s 15s 9s 8s 12s
Test B1 120s 58s 50s 100 s 48
Test B2 21s 28s 30s 19s 20s
5.5 Quantitative observations Result how many clicked used to fulfill the two tests A & B twice.
Candidate Mo Younes Diyar Malick Danny
Test A1 51 48 30 44 35
Test A2 18 25 10 9 8
Test B1 50 80 41 62 40
Test B2 23 24 30 18 18
Page 104 of 119
5.6 SUBJEKTIVE OPSERVATIONS In the start we got comment on tab names that was misleading. After third candidate we
changed names on the buttons and the tabs. We did not get any more comments on the
names after that. Test persons found that the application was easy to navigate. To show
graphs was not very clear. Candidates did everything they were asked to but nothing
happened. They suggested that a message should appear when choices had been made and
button execute had been clicked. Message could be: to see graph click tab Chart.
5.7 RESULTS First time test A was performed it took in average 41,6 s to fulfill
Second time test A was performed it took in average 14s to fulfill.
In average this is an improvement of performance of 41,6/14(total) =297%
First time test B was performed it took in average 55,8 clicks to fulfill
Second time test B was performed it took in total 10,8 clicks to fulfill.
In average this is an improvement of performance of 55,8/10,8 (total) =242%
5.8 Fault with the test Unfortunate for the test the test persons were truly a homogenous group. All test persons
were students, under 30 years of age and all were students of computer science. The
application is meant for engineers and therefore the test persons can be said to be
representative. Test had given a result we were pleased with.
5.9 Changes we made after the test Names for buttons and tabs were altered based on test person’s recommendation. There
was one change we should do but not managed in times of delivery. Once the execute
button is clicked when making a graph a message box should appear. The message should
tell what to do to show the graph that just was made. This would ease navigation.
Page 105 of 119
6 Conclusion
Testing shows that the application meets the functional requirements given in the
requirements and it handles the error correctly. User testing revealed weaknesses in
ease of use in the application that has been corrected.
But we still got a big return of the user testing and testing resulted in
clear improvement of user friendliness.
Test results prove that this is a program that is easy to learn. In both tests participants
improved their result, on average with a 3 times better result.
Page 106 of 119
7 Sources
Gurholt, Gunnar og Thor E. Hasle (2003): Grunnleggende systemutvikling
Oslo: Cappelen
Heim, Steven (2008): Resonant Interface.
Person Education
Page 107 of 119
Appendix A: Requirements specification
Group 20:
Ali Emre Yildirim
Danh Le Cong Tran
Kevin Johnny Galåen
Vibeke Askeland
Page 108 of 119
1 PREFACE:
This document is a requirement specification. In detail statements it documents the
agreement between the student group and their Employees. Listed are the required
functionality for the software to be made and whishes for the projects. Tutors can use this
document for guidance and sensor to evaluate the work of the student group. Working with
this document gave a clear idea of actually how big this project was. We had to cut down
much of the ideas to be able to finish a prototype in the time given.
Page 109 of 119
TABLE OF CONTENTS
Appendix A: Requirements specification _______________________________________ 107
1 PREFACE: ____________________________________________________________ 108
2 FACTS _______________________________________________________________ 111
2.1 Project facts ______________________________________________________ 111
3 BACKGROUND ________________________________________________________ 111
3.1 School project: ____________________________________________________ 111
3.2 Employee ________________________________________________________ 111
3.3 Today’s situation __________________________________________________ 111
3.4 Whish for our project _______________________________________________ 112
4 SYSTEM DESCRIPTION __________________________________________________ 113
4.1 System Status _____________________________________________________ 113
4.2 System with our prototype __________________________________________ 113
4.3 UseCase diagram __________________________________________________ 114
5 LIMITATIONS _________________________________________________________ 114
5.1 Prototype ________________________________________________________ 114
5.2 Security __________________________________________________________ 114
6 Product overview ______________________________________________________ 115
6.1 How to read this document: _________________________________________ 115
6.2 Technologies Specification: __________________________________________ 115
6.2.1 Requirements _________________________________________________________________ 115
6.2.2 Our suggestions ________________________________________________________________ 115
Requirements outside the application: ______________________________________ 116
6.2.3 Requirements _________________________________________________________________ 116
6.2.4 Desirable functions _____________________________________________________________ 116
7.1 Implementation requirements: _______________________________________ 116
6.2.5 Required functionality ___________________________________________________________ 116
6.2.6 Desirable functionality __________________________________________________________ 116
7 Types of statistics for different designs: ____________________________________ 117
7.2 Engineering/Financial/Quality design: _________________________________ 117
7.1.1 Required statistics ______________________________________________________________ 117
7.1.2 Desirable statistics ______________________________________________________________ 117
7.3 Owner design: ____________________________________________________ 118
Page 110 of 119
7.1.3 Desirable statistics ______________________________________________________________ 118
7.4 Indexing for generated rapports ______________________________________ 118
7.1.4 Desired _______________________________________________________________________ 118
1 SOURCES 118
Page 111 of 119
FACTS
1.1 Project facts Working title: Battery analysis
Period: 5. January until 17.juni
Project number: 09-20
Group members: Ali Emre Yildirim, Danh Le Cong Tran,
Vibeke Askeland og Kevin Johnny Galåen
Teatching supervicor: Eva Hadler Vihovde
Employeer: Think Global AS
Contact persones: Bente Øvsttun Ditman [email protected] 41 44 08 49
Egil Falck Piene [email protected] 92 222 505
2 BACKGROUND
2.1 School project: The project is a part of a bachelor’s degree at Oslo University College Faculty of Engineering.
Project in short: Every Th!nk wheakle has a mindbox collecting battery information and
sending it to a database on a server . The project is to make a tool that can present gathered
information graphically.
2.2 Employee TH!NK is a Norwegian owned company making electrical cars of hard plastic. Think Nordic
AS settled in Aurskog –Høland, Norway, produces the car. Engineering has offices at IT –
Fornebu, Norway. The el-car is made of reusable material and don’t produce polluting
material by being used.
2.3 Today’s situation In every Think A306 vehicle a MindBox (RAC) unit is installed at time of production. The
Mindbox allows for remote communication with, and reporting from, the car’s systems.
Engineering have a program to show the different data, but the tool do not offer any statistic
presentation of the data.
In general the idea is to analyze collected information for different purposes.
Page 112 of 119
The history of the car’s battery performance is relevant for debugging purposes, support,
engineering, sale/marked and quality control. The battery suppliers are also seen as
potential “customers” for the battery data.
For Th!nk our project is a pioneer one. There are several problems to deal with. Best case
would probably be to hire a professor in statistics to find answer to questions like: what data
to collect and at what time rate? And question like: what statistics that would be preferable
to collect and why? If such were the story our task would be a much easier one.
Batteries have a “life-length” somewhere between four or ten years. Life-length depends on
how well the car (battery) is taken care of by its owner/user. The "life of the battery" is what
Th!nk wants to monitor. Gathering battery data started only 6 months ago. None of the
statistic we make based on the data available will show the “life of the battery” by the time
our finish. For our presentation we have to use simulated data.
Th!nk do not have a clear idée of every statistic evaluation which could come in handy. Our
employee has given us an idea of what services they want from our program, but not a
project with a complete form. In addition to given ideas for statistics they have challenged us
to figure out possible statistics for our prototype. By this Th!nk believe and "hope" that a
students imagination can be just as good as their own engineers.
2.4 Whish for our project This being pioneers project for Think. Our prototype tool must be suited for an upgrade
when new statistic formula comes along.
Th!nk wants us to make a tool which can present battery information graphically. Engineers
believe that a graphical presentation will give different effects; better help to monitoring the
batteries, give scientists different ideas for further development, find better ways to take
care of the batteries and improve battery service among others. Our project will also work as
a tool for the engineers making them financiers find money for further development. By
showing our prototype the financiers have an idea of what can be done in 4 months by
students.
Page 113 of 119
3 SYSTEM DESCRIPTION
3.1 System Status TH!NK has databases that are constantly updated with battery data from an ever increasing
amount of TH!NK cars.
Illustration 1: Think’s system today
3.2 System with our prototype The main purpose of our application is to display charts and calculate statistics from
collected data.
Illustration 2: Think’s system with our prototype
Page 114 of 119
3.3 UseCase diagram UseCase diagram: The Prototype
4 LIMITATIONS
4.1 Prototype Our work will result in a prototype. As the word prototype implies this will be a working but
an unfinished product. Do to time limits several functionalities will be described in the
documentation but not implemented.
4.2 Security To secure that only authorized persons will enter the system; the system must be entered
with a username and a password. Technology used to achieve this will be an easy one for our
Page 115 of 119
prototype. We believe that only trusted people, a small and trusted group from Think will
use our prototype. When later versions of the program is made effort must be made to
secure access to the program and the database.
5 Product overview
5.1 How to read this document: This document contains all required functions and all desirable functions. Required functions
marked R should be implemented. Do to time limit, desirable functions marked D might not
be implemented.
Both types, D and R are listed within the teams they belong. Importance of a function is
organized descending. Our ideas for implementations are marked with I. Th!nk requires that
all documentation has to be in English.
5.2 Technologies Specification: For this project we shall use the following technologies:
5.2.1 Requirements
R: Open source software
R: XML (for managing application flow)
R: Database Th!nk uses PostGreSQL among others. It has to be an easy way to change
between databases in the prototype. Good documentation can serve this request.
R: Web based application
5.2.2 Our suggestions
I: CSS to ease designer changes.
I: JSF (Java Server Faces) with Facelets rather than JSP(Java Server Pages) in order
to make the code more designer and developer friendly. JSF is an open source
software.
I: We have chosen MySQL since that is the database we have at school.
Page 116 of 119
Requirements outside the application:
Requirements
R: Detailed and structured requirement specification so that other developers can
continue where we eventually stop.
R: Use of UML and pictures for good understanding. Other developers must easily
understand the application. Ideas we have come up with but not implemented must
also be caught easily.
R: Application code shall be easy to read and understood. Unfortunately do to this
requirement our code won’t be 100% time effective. Our client prefers intuitive and
well-commented code.
R: It must be easy to change databases and database language (this requires an
abstract layer and database logic in a single part of the program).
R: Graphical user interface (GUI) has to be user-friendly.
R: Documentation has to be written in English.
Desirable functions
D: Different design for different users, primarily engineers and car owners. Other
users can be financials which can be split into investor and marketing. Engineer can
be split into developers, researchers, quality and designers. Every GUI has to be user-
friendly. GUI for car owners, only, has requirements for colors, fonts.
D: Design functions for car owners: battery/use/cost statistics, fun facts respectively
5.3 Implementation requirements:
5.3.1 Required functionality
R: Compatible with Firefox and Internet Explorer
5.3.2 Desirable functionality
D: Compatible with Opera and Chrome if we have time left
Page 117 of 119
6 Types of statistics for different designs:
6.1 Engineering/Financial/Quality design:
6.1.1 Required statistics
R: XML presentation of different statistics. Predefined statistics does not exist. Th!nk
want us to make it easy for other developers to enter new statistics.
R: Battery state of charge
R: Driving temperature
6.1.2 Desirable statistics
D: Functions to seek for rapports in the archive, weekly, monthly and year reports.
R: Number of battery cycles (average per day, week, month, year, total)
D&I: Chart that can display Y values selected by the user; example: x=time, y=KWh
and a graph that displays usage, other values………(this one is considered VERY
IMPORTANT)
D: Possible to show more than one graph in the same chart, preferable on top on
each other.
D: Battery capacity (Current capacity, initial capacity)
D: Number of complete discharges
D: Number of complete charges
R: Top speed
R: Different owner categories (A,B,C,D, driver categories so that their influence on
battery life can be monitored)
Average speed
D: Driving time
D: Info about how much energy that is transferred to the different parts of the car
(heating, air conditioning etc) in order to give more precise information about
battery usage.
D: Driving distance (average per day, month, year, and total)
D: Ability to detect whether the battery quality is good or crappy, so that TH!NK, in
the latter case, could contact the owner find a solution to the problem.
D: Total leasing income so far compared to battery price.
Page 118 of 119
D: Lifetime so far compared to expected lifetime.
6.2 Owner design:
6.2.1 Desirable statistics
D: battery status
D: driving distance
D: driving time
D: top driving velocity
D: average driving velocity
D: top acceleration
D: battery cycles
D&I: Electricity cost compared to gasoline cost over the same distances
D&I: how much CO2 would have been emitted if a gasoline engine did the job?
6.3 Indexing for generated rapports
6.3.1 Desired
D: Every week, every month and every year there can be generated battery-rapports.
These will be put in an archive. Users of the system must be able to search for these
rapports.
7 SOURCES
http://www.iu.hio.no/~ulfu/hovedprosjekt/dokumenter/dokumentasjonsstandard.pdf
