\chapter{Software architecture}
\section{Packets}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{Tests}
\section{Need for tests}
We choose to use basic tests in this application for two basic reasons:
\begin{itemize}
\item It helps designing the software. We can adopt test-driven programming
and we can find lack of flexibility or functionality earlier in the project
when we are defining the tests.
\item It helps maintaining the quality of software that is likely to change in
the time.
\end{itemize}
\section{JUnit}
To test this project we chose JUnit. It provides an easy way to code, organize,
execute and collect results from tests.
JUnit tests are coded in Java classes. Its structure is the same as other java
classes, but a set of annotations define what is a test and what are the test
suites.
A test is a method containing a set of operations and assertions about the
results of the operations. We can code the test methods in the same class to
test or create different classes containing test methods. Test methods
are only differentiated from the regular tests by adding a
\lstinline[language=Java]|@test| annotation.
\section{Design of the test suites}
The set of tests designed for this application would be defined as:
\begin{description}
\item[Basic test] because they only test the classes, its methods
and its algorithms. They do not test user functionality.
\item[Black-box test] because they do not check the internal state of the
classes but only its public methods and attributes.
\end{description}
In order to keep the main code clear, the tests were designed in a parallel
package structure. A new folder named test was created in the same level than
the folder src and the packet tree was duplicated there. Then the test for each
class is stored in the same package than the tested class, but in a different
src folder. It keeps the code organized and also keeps the main code clear.
This project has only one test suite composed of all of the available tests.
This is possible due to the small size of the project. There is no need to
separate the tests in different test suites because they are all basic test,
black-box test and they can be executed relatively fast.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{New version discovery service}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{User preferences and application properties}
There is some set of variable information that the application must manage. This
information may vary during the cycle of development of the product or during
the cycle of use of the application. We will define two king of variable
information depending of who and when does it change.
\begin{description}
\item[User preferences] are managed by the user. It's original value is
defined by the developer, but then it might be changed by the user many times
during the cycle of use. This information is user-dependent.
\item[Application properties] are managed by the developer. The user cannot
modify them. They are common for every user in the system. Their value is
updated by the programmer in every version of the product.
\end{description}
\section{User prferences}
User preferences are implemented with the Java preferences class:
\lstinline[language=Java]|java.util.prefs.Preferences|. This class provides
a way to store key/value pairs the OS file system. The way the OS uses to access
and store the information is hidden for the developer.
The following are examples of user preferences:
\begin{enumerate}
\item Default output directory for the log files.
\end{enumerate}
\section{Application properties}
Application properties are implemented with the Java Properties class:
\lstinline[language=Java]|java.util.Properties|. This class provides
a way to store key/value pairs in text files. The adopter format is .properties.
A global system is provided to serve property values all along the application.
The following are examples of application properties:
\begin{enumerate}
\item Application version.
\item Application last version URL.
\end{enumerate}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{Persistence}
Applications persistence is based in a database. This way we can clearly
separate the storage location. In a first version of the program, the storage is
performed in an embedded database. In later versions, storage will be performed
in a dedicated shared database in the cloud. To effectively separate the
database from the application and simplify the implementation, Java Persistence
Api (JPA) was choosen. Direct connection with JDBC has been ruled out because
it needed for a implementation of the storage and retrieval logic.
\section{Java Persistence API}
Java Persistence API (JPA) is a Java framework that manages the mapping between
data classes and database tables and relationships in relational databases
(RDBMS).
It allows to persist objects in database and retrieve them from the tables
abstracting the programmer from the database details. Also the database
structure is created by the framework in the initialization of the program. The
configuration of the mappings between data objects and database records requires
almost no programmer intervention. The data classes meta information related
with database storage is detailed in java annotations in the java .class source
file.
JPA is a standard and it does not impose a implementation. There are several
options as JPA implementations that can be considered. Among them, here are the
most famous ones:
\begin{description}
\item [Hibernate:] Probably the most advanced one. Not too sticked to the
standard JPA. It is generally said that it is difficult to switch from
Hibernate to other providers. It requires a lot of libraries that give
complexity and overweight to the project. Its license is GNU Lesser General
Public License (LGPL).
\item [TopLink:] Too simple. It lacks from the powerful options that other
libraries have. Its license is Oracle License.
\item [EclipseLink:] It was taken from TopLink. It has been chosen to be the
JPA implementation for the GlassFish server v3.0. It guarantees that this
project is going to be stable. It is simple, powerful and well documented.
It is easy to find examples and documentation in the Internet. It is
easily integrated with the Eclipse IDE, the tool that has been used for the
implementation of the project. Its license is Eclipse Public License, Eclipse
Distribution License.
\item [OpenJPA:] Very well documented and easy to use. This project still does
not show a mature state. Frequent bugs arise and it takes long time to get
fixed. Its license is Apache License 2.0.
\end{description}
For this implementation, ease of use and lightweight was a requirement. So based
on this, EclipseLink was chosen.
\section{Database}
Regarding to the database selection, the same rule as with JPA implementation
has been applied. Ease of use and small overload of the project had been the
main constraints.
Derby database has been chosen because of :
\begin{itemize}
\item The programmer (me) already had experience on it.
\item It is embedded, what simplifies configuration.
\item It requires no installation.
\item There are examples of use in the Internet.
\end{itemize}
In future versions, the local database will be substituted (on user request) by
a centralized remote database. This future database will be a more powerful
on-line database.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{Software installers}
\section{The Windows installer}
\section{The Linux installer}
