Rewrite a message exchange system and set up its testing environment

ESPRIT / DATAPROCES 2015
Drafted by Emmanuel Padjinou 1
Executive summary
Obtaining a National Engineer Degree at higher private university of technology and
engineering in Tunisia is ruled by being involved in an end of studies project after which the student
is required to present the work done all along his internship time frame.
The objective of my internship at Dataproces in Denmark was to fulfill this goal.
Dataproces aims for increasing municipalities’ revenues through analyzing inconsistencies within
their data.
The MOX PROJECT that have been assigned to me will help Dataproces to strengthen
its relationship with Danish authorities by the mean of providing a better control of municipal water
supply.

Dedication
This work is dedicated to my parents, Jean Pierre PADJINOU and Madeleine
LEUMANI PADJINOU, without whose caring support it would not have been possible, and to my
brothers and sisters, Christelle Darlyne TCHEUGNEU PADJINOU, Serges Ronni POUYO
PADJINOU, Iddris Gabin PADJINOU PADJINOU and Ange Tracy TIANI PADJINOU.

Acknowledgements
Special thanks to the distinguished ISD team of Dataproces, for the experience sharing
that was crucial in this project progress: Mr. Michael PEDERSEN, Mr. Farhood HAKHAMANESHI,
Mr. Kenneth SOMMER, and Mr. Jens Henrik RAUFF HANSEN.
I am grateful to the teaching staff of Higher Private University of Engineering and
Technology for the quality of the studies I have been involved in 02years long, more particularly Mr.
Ali LABBEN for the constant and unconditional assistance he provided me all along the redaction of
this report.
I am greatly thanking all those who took part of near or far to my successful career as
a student at ESPRIT in Tunisia. This mainly concerns Mr. Mehdi AKROUT, who gave me this
opportunity to be part of this great experience that was studying at ESPRIT.

Table of contents
General introduction........................................................................................................................ 9
CHAPTER 1: General overview .................................................................................................... 10
Introduction................................................................................................................................... 11
I. The welcoming company ....................................................................................................... 11
II. Issue and needs .................................................................................................................... 12
III. Suggested solution............................................................................................................. 13
IV. Working methodology......................................................................................................... 13
1. Agile Methods .................................................................................................................... 13
2. Scrum Software management process [1].......................................................................... 14
3. TDD Software development method [2].............................................................................. 15
4. UML 2.0 Modeling language............................................................................................... 16
Conclusion.................................................................................................................................... 16
CHAPTER 2: Current MOX .net solution....................................................................................... 17
Introduction................................................................................................................................... 18
I. Existing solution..................................................................................................................... 18
II. Problem ................................................................................................................................. 21
III. Prior study.......................................................................................................................... 21
1. SSL mutual authentication [4]............................................................................................. 21
2. Message oriented Middleware (MOM)................................................................................ 22
Conclusion.................................................................................................................................... 25
CHAPTER 3: Needs’ analysis and specifications.......................................................................... 26
Introduction................................................................................................................................... 27
I. Unified modeling language (UML) 2.0 [6]............................................................................... 27
II. Needs analysis ...................................................................................................................... 28
1. Functional requirements..................................................................................................... 28
2. Nonfunctional requirements................................................................................................ 28
III. Use cases analysis............................................................................................................. 29
1. Use cases diagrams........................................................................................................... 29
2. System sequence diagram................................................................................................. 39
Conclusion.................................................................................................................................... 44
CHAPTER 4: Software conception................................................................................................ 45

Introduction................................................................................................................................... 46
I. Software deployment ............................................................................................................. 46
II. Class diagram........................................................................................................................ 48
III. Object sequence diagram................................................................................................... 49
IV. Activity diagram.................................................................................................................. 51
Conclusion.................................................................................................................................... 52
CHAPTER 5: Tests and realization ............................................................................................... 53
Introduction................................................................................................................................... 54
I. Working environment............................................................................................................. 54
1. Material environment.......................................................................................................... 54
2. Development environments................................................................................................ 54
Platforms............................................................................................................................ 55
3................................................................................................................................................ 55
4. Softwares ........................................................................................................................... 55
5. Technologies...................................................................................................................... 56
6. Servers............................................................................................................................... 57
II. Gantt diagram........................................................................................................................ 58
III. Implementation................................................................................................................... 58
1. Product Backlog ................................................................................................................. 58
2. Writing unit tests................................................................................................................. 62
3. Writing integration tests...................................................................................................... 64
4. Preparing the continuous integration environment.............................................................. 64
5. Installing and configuring artifactory ................................................................................... 67
6. Integrating artifactory with bamboo..................................................................................... 68
7. Unit testing results.............................................................................................................. 69
8. Statistics............................................................................................................................. 72
Conclusion.................................................................................................................................... 74
Overall conclusion......................................................................................................................... 75
Bibliography and sources.............................................................................................................. 76
Appendices................................................................................................................................... 77

Abbreviations
AMQP: Advanced Message Queuing Protocol
API: Application Programming Interface
BDD: Behavior Driven Development
CA: Certificate Authorities
DIOS: Dataproces’ Procurement Optimization System
ESPRIT: higher private university of technology and engineering
IDE: Integrated Development Environment
IIS: Internet Information Services
ISD: Information System Development
JSON: JavaScript Object Notation
MARC: Municipal Automatic Robot Caseworker
MOM: Message Oriented Middleware
MOX: Messages Oio-standards eXchange
P2P: Peer to Peer
PDF: Portable Document Format
PSI: Potentially Shippable Increment
RUP: Rational Unified Process
SQL: Structured Query Language
SSL: Secure Socket Layer
TDD: Test-Driven Development
UML: Unified Modeling Language

List of tables
Table 1: Comparison between MOM............................................................................................. 24
Table 2: Use case 1 <create database description>...................................................................... 30
Table 3: Use case 2 <cache a case file description>..................................................................... 31
Table 4: Use case 3 <remove a case file from the database description>..................................... 31
Table 5: Use case 4 <publish a registeringOutputType message description>.............................. 33
Table 6: Use case 5 <consume a registeringOutputType message description> .......................... 33
Table 7: Use case 6 <consume a laesInputType message description> ....................................... 34
Table 8: Use case 7 <consume a laesOutputType message description> .................................... 35
Table 9: Use case 8 <consume a opretInputType message description>...................................... 36
Table 10: Use case 9 <consume a opretOutputType message description>................................. 36
Table 11: Use case 10 <consume a retInputType message description>...................................... 37
Table 12: Use case 11 <read data from jupiter database description>.......................................... 38
Table 13: Use case 12 <write data on jupiter database description>............................................. 38
Table 14: Product backlog ............................................................................................................ 61
Table 15: Maven phase's and goal's description ........................................................................... 64

List of figures
Figure1: Dataproces hierarchy...................................................................................................... 12
Figure 2: Scrum process............................................................................................................... 14
Figure 3: TDD cycle ...................................................................................................................... 15
Figure 4 : Message exchange flow................................................................................................ 19
Figure 5: Old Jupiter layout........................................................................................................... 19
Figure 6: Old Orchestrator layout.................................................................................................. 20
Figure 7: Old SBSys layout........................................................................................................... 20
Figure 8: Mutual SSL authentication ............................................................................................. 22
Figure 9: Use case <manage a case file>..................................................................................... 30
Figure 10: Use case <process a case file>.................................................................................... 32
Figure 11: Use case <interact with jupiter database>.................................................................... 37
Figure 12: System sequence diagram 1 <create the database>.................................................... 39
Figure 13: System sequence diagram 2 <cache a case file> ........................................................ 40
Figure 14: System sequence diagram 3 <delete a case file> ........................................................ 41
Figure 15: System sequence diagram 4 <process a case file>...................................................... 42
Figure 16: System sequence diagram 5 <read data from jupiter database>.................................. 43
Figure 17: System sequence diagram 6 <write data on Jupiter database>.................................... 44
Figure 18: Software deployment architecture................................................................................ 46
Figure 19: Class diagram.............................................................................................................. 48
Figure 20: Object sequence diagram ............................................................................................ 50
Figure 21: Activity diagram............................................................................................................ 51
Figure 22: Gantt diagram .............................................................................................................. 58
Figure 23: Junit assertion.............................................................................................................. 62
Figure 24: Expected exception catched ........................................................................................ 62
Figure 25: Mocked object declaration............................................................................................ 62
Figure 26: Mocked object behavior customized ............................................................................ 63
Figure 27 : Maven phases............................................................................................................. 63
Figure 28: Package and source folder organization ...................................................................... 65
Figure 29: Git branching strategy.................................................................................................. 66
Figure 30: Artifacts exposed by artifactory .................................................................................... 67
Figure 31: Capabilities of the default agent ................................................................................... 68
Figure 32: Adding the Artifactory Maven 3 dependency to a job.................................................... 68
Figure 33: List of plans configured on Bamboo ............................................................................. 69
Figure 34: Stages within the Java MOX unit testing plan............................................................... 69
Figure 35: Artifacts produced by the first job “initialize artifacts”.................................................... 70
Figure 36: Plan successfully runned.............................................................................................. 70
Figure 37: Build activity diagram ................................................................................................... 71
Figure 38: Build duration diagram ................................................................................................. 71
Figure 39: Percentage of successful builds................................................................................... 72
Figure 40 : Statistics ..................................................................................................................... 73
Figure 41: Maven results............................................................................................................... 73

General introduction
The dizzying growth witnessed by information technologies has led to a consequent
raise of data online. This raw data source is analyzed, filtered and given back in order to serve
economic, politic, historic, cultural and even social interests.
Furthermore, governments are no exception to the rule. This is noticeable in Denmark
where the citizen’s information system is progressively computerized, aiming to abandon paper
documents based administration.
However, mistakes and inconsistencies are still likely to be pop up as the seizure is
done by human beings. Dataproces is precisely targeting this flaw of the system in place and offers
its services to correct those unavoidable failures.
Though Dataproces is mainly concerned by big data gathering and analyzing, the task
we are going to fulfill is not related to this field of study. We will have to set up a system as well as
its testing infrastructure. The software in instance should be able to handle water supply reporting in
the community of Hjørring. This realization will be titled: “Rewrite a message exchange system
and set up its testing environment”.
This documentation is split up in 5 main sections. The first one aims to give a general
overview of the company, the project we were involved, the context of this project as well as the
working technology we have opted for.
The second part goal will be to study the current MOX system and therefore the
technologies that it is made up by in order to explain more thoroughly, why was it necessary to
consider rewriting the entire project. This will also be an opportunity to shed more light about the
focal points of this achievement which are the consumer-producer paradigm and the unit testing
programming practice.
A study of functional and non-functional requirements will be displayed and compiled
in the third section. The next section shall relate the conception phase of this implementation
throughout UML diagrams that are going to guide us all over the application development.
The starting point of the fifth and last section will be presenting the architecture of MOX,
afterwards, the material and software working environment and finally screenshots of the plain
functional software.
The report will be closed by a general conclusion composed by a synthesis of the work
that has been done and what this can lead to as forthcoming prospects.

CHAPTER 1: General overview

Introduction
This chapter will be dedicated to the welcoming company and this will lead us to the
context of our project and finally the problematic that triggered the need to implement it.
I. The welcoming company
Since its creation on 2011, Dataproces has built a very strong position and platform for
processing and analyzing large volumes of data. Its ability to manage, sort, clean, merge and analyze
millions of data lines crisscrossing various online sources is particularly pertinent to the local
economy and administration which made the company a privileged partner when it comes to deal
with data inconsistencies.
A large set of software helps Dataproces in its efforts of supporting municipalities. The
Danish public sector faces several major issues, amongst other of them, we can cite: municipal data
access to the shopping area, control of water supply in municipalities and the collect of data from
municipalities. Those problems are respectively handled by DIOS (Dataproces’ Indkøbs Optimerings
System) which means “Dataproces’ Procurement Optimization System”, MOX (Messages OIO-
standards eXchange) and MARC (Municipal Automatic Robot Caseworker).
DIOS is a clever and user-friendly software platform based on the ZK framework and
SQL request which facilitates operations like filtering, sorting and printing on a huge dataset of
Danish citizens. MOX is a standalone message exchange system aiming to provide a real-time
reporting system for water supply in Danish municipalities. Finally MARC is a highly sophisticated
robot working on its own also, gathering data automatically from specific web pages and saving them
on Dataproces servers for later analysis and treatments.
Besides those main software, Dataproces is also responsible for other applications
which have a more negligible impact economically for the company.
During this period of time at Dataproces, I was entirely deemed to be an active and
committed member of the IT department, more precisely, the software development division. I was
expected to resolve issues which were raised according to the business’ needs, as well as coming
up with suggestions in an effort to enhance the company’s productivity. Those goals where plotted
throughout biweekly meetings hold with the Software Development team and monthly gathering with
all the colleagues.

Below is a representation of the company’s hierarchy.
Figure1: Dataproces hierarchy
II. Issue and needs
Keeping a clear and up to date record of operations has always been a concern in
information technology and most of the time is wrapped under the term reporting. The Danish
government provides water to municipalities all over the country, the point of the MOX software is to
always been able to check which volume of water has been sent to which municipality and when has
it been done. The objective is to provide a real-time reporting system handling municipal water
supply.
The MOX project will be our main focus all the way long, more specifically, enhancing
the results we actually get from the software already released and setting up a testing environment
for the project.
The current MOX software is entirely designed with Microsoft components: agents are
wrapped inside windows services, the programming language is c# and the development platform
MICROSOFT VISUAL STUDIO 2013 EXPRESS WINDOWS DESKTOP.

An agent can be considered as a standalone and self-handling continuous thread
which is constantly running up on the computer executing the MOX project, listening for specific type
of messages and triggering actions according to the type of message that it catches.
However two critical flaws have been noticed while exploiting the software on the field:
- The restrictions that might be faced in term of further development of the software,
since c# is a proprietary development language.
- The high latency witnessed when transporting messages is the most glaring factor
influencing this need of evolutionary maintenance (Processing a single case file on
the system could last up to 20 seconds).
III. Suggested solution
After a thorough analysis of those minor but impactful limits of the current MOX system
two solutions have been set up, each one palliating to one of the flaw previously mentioned upper:
Problem Solution
Restrictions in term of further
development of the software
Reverting the software to the java environment which will provide
a better degree of liberty regarding the software enhancement.
High latency Dealing with the delay in messages transmission will be handled
by changing the Message oriented middleware technology that
had been used. This implies using the lighter and more
purposefully oriented ZeroMQ instead of the complex and heavy
RabbitMQ.
Once the solutions to these two issues implemented, a testing campaign will be carried
out to check whether we effectively achieved our goals. A comparison between the amount of time
that the new solution needs in average to process a single case file and the 20 seconds observed
with the old system will help us in this regard. However, a final statement can only be pronounced
when the new software will be set for production, since the testing environment will not access
remote services.
IV. Working methodology
1. Agile Methods
Agile methods are a group of software development methods in which requirements
and solutions evolve through collaboration between self-organizing, cross-functional teams. It
promotes adaptive planning, evolutionary development, early delivery, continuous improvement, and
encourages rapid and flexible response to change.

Agile methods due to their flexibility and their constant adaptation to the system
evolution seemed to be the most obvious solution for Dataproces concerning the MOX project.
Coupled to the scrum management process, we will deploy the agile oriented Test Driven
Development sustained by UML 2.0 as modeling language.
2. Scrum Software management process [1]
Scrum is a management and control process that cuts through complexity to focus on
building software that meets business needs. Management and teams are able to get their hands
around the requirements and technologies, never let go, and deliver working software, incrementally
and empirically.
Scrum is based on three main actors cooperating in order to serve the progress of the
software development.
- Product owner : represents the stakeholders and is the voice of the customer
- Development team : responsible for delivering potentially shippable increments
(PSIs) of product at the end of each sprint (the sprint goal)
- Scrum master: accountable for removing impediments to the ability of the team to
deliver the product goals and deliverables. The scrum master is not a traditional
team lead or project manager, but acts as a buffer between the team and any
distracting influences
A representation of the life-cycle of a scrum project is below:
Figure 2: Scrum process
The emergence of new terminologies related to the scrum management process can
be noticed.
- Product backlog: ordered list of requirements that a scrum team maintains for a
product
- Sprint Backlog: the list of work the development team must address during the next
sprint (refined version of a part of the product backlog)
- Sprint: A time period (typically 1–4 weeks) in which development occurs on a set
of backlog items that the team has committed to

- Daily scrum: Meeting held between the members of the scrum team daily which
goal is to summarize what has been done, what is still to do, what are the possible
obstacles
- Sprint review: occasion to review the accomplishments towards the current sprint
and presenting the work to the stakeholders
- Sprint retrospective: the scrum team assesses the previous sprint and distinguish
what went well and what has to been addressed.
3. TDD Software development method [2]
Test-driven development (TDD) is a software development process that relies on the
repetition of a very short development cycle: first the developer writes an (initially failing) automated
test case that defines a desired improvement or new function, then produces the minimum amount
of code to pass that test, and finally refactors the new code to acceptable standards.
Test-driven development is related to the test-first programming concepts of extreme
programming which is an agile software development methodology.
A diagram displaying the process flow of test driven development can be find below:
Figure 3: TDD cycle

4. UML 2.0 Modeling language
Aiming to provide a more structured view of the components within the project, the
UML 2.0 Modeling language shall be used. A more detailed explanation of this modeling language
can be accessed in the first paragraph of the chapter 3.
Conclusion
At the end of this chapter, we have got a general overview of both working
methodologies and project itself, as well as all the choices that have been made to drive the project
to completion. The next chapter will be focused on studying the existing MOX solution for the sake
of underlining its flaws and breaches.

CHAPTER 2: Current MOX .net solution

Introduction
A prior study of the MOX project exploited by the clients on the field is a beforehand to
get a full understanding of the MOX system, since the old and new version are more or less similar.
This chapter will be written in a bid to achieve this. The structure we will stick to all along this section
is the following: study the existing MOX solution, looking for the major problem raised by this software
in its current state, explaining more deeply the concepts on which the software architecture is based.
I. Existing solution
MOX is merely a succession of message exchanges between three agents (Jupiter,
Orchestrator and SBSYS) permitting to handle water supply in a municipality. The system fetches
the files summarizing the water supply state compiled on a web service online, then process each
of those files and generate reports regarding each of them which will be uploaded to the Jupiter
database.
The Jupiter database [3] is GEUS (Danmarks og Grønlands Geologiske
Undersøgelse / Geological Survey of Denmark and Greenland) nationwide database of
groundwater, drinking water, raw materials, environmental and geotechnical data. The database is
the joint public database in the area and is part of Denmark's Environment Portal. The database is
publicly available.
Even though accessing the Jupiter database is public for reading purposes, it is
necessary to be granted the right to write inside this database.
We have got this right through a Danish municipality that has created an account in
behalf of us. Nevertheless, we still have to prove that we are the ones trying to access the Jupiter
database. The assertion is done through SSL mutual authentication based on the SSL protocol.
Each incoming case file is exchanged and altered 6 times, following the flow depicted
below:

Figure 4 : Message exchange flow
The case Pooler of SBSys retrieves the data each 10 minutes and the message
exchange operations can start.
A full version of the MOX project is already deployed and fully functional. It is composed
by three core processes called agents:
- Jupiter agent: is a process reading and writing information such as the amount of
water supplied, the address and contact of the municipality in instance, the date
and time of the operation and the pdf document related within the Jupiter database.
Figure 5: Old Jupiter layout

- Orchestrator agent: illustrates the link between Jupiter and SBSys and aims to
make the two entities as independent as possible
Figure 6: Old Orchestrator layout
- SBSys agent: Pull out the case files locally and initiates the exchanging process, It
is also the agent that terminates the exchange by confirming that the case file has
been persisted in the Jupiter database.
Figure 7: Old SBSys layout

II. Problem
The solution described over is fully functional. However a lot of misbehaviors alongside
with lack of efficiency have been discovered and raised as issues to work on. Since this will serve
the interest of the Danish government, there is no room for approximation. The issues to address
are:
- The development platform was so closed that it constrained the development team
regarding forward development and evolutionary maintenance
- Agents were wrapped within windows services, which is obliging users to use
computer with windows operating systems to run them and furthermore, windows
services are not reliable as they highly depend on the underlying windows operating
system.
- The message oriented middleware solution that was deployed, in instance
RabbitMQ, is far too heavy and complex for the use we want to make of it.
III. Prior study
A knowledge to get prior to explain our work is a general overview of what we are
working on and for what sake is it done. Some concepts that are critical to explain are the Jupiter
database, the mutual authentication through SSL and the message oriented middleware.
1. SSL mutual authentication [4]
Mutual SSL authentication or certificate based mutual authentication refers to two
parties authenticating each other through verifying the provided digital certificate so that both parties
are assured of the others' identity. In technology terms, it refers to a client (web browser or client
application) authenticating themselves to a server (website or server application) and that server
also authenticating itself to the client through verifying the public key certificate/digital certificate
issued by the trusted Certificate Authorities (CAs). Because authentication relies on digital
certificates, certification authorities such as Verisign or Microsoft Certificate Server are an important
part of the mutual authentication process. From a high-level point of view, the process of
authenticating and establishing an encrypted channel using certificate-based mutual authentication
involves the following steps:
- A client requests access to a protected resource.
- The server presents its certificate to the client.
- The client verifies the server’s certificate.
- If successful, the client sends its certificate to the server.
- The server verifies the client’s credentials.
- If successful, the server grants access to the protected resource requested by the client.

This is schematized by the picture below:
Figure 8: Mutual SSL authentication
2. Message oriented Middleware (MOM)
The worst failure which a message oriented middleware as MOX can undergo is to
lose messages. Understand, not to achieve deliver an expected message. Though this is always
likely to happen, due to the unreliability of network communication. Whatever is the communication
protocol on which we rely, there are always unexpected events which can occur: unavailability of the
other end (even momentarily), network overload, or even power cut.
In order to minimize the risks of dropping down messages and in an attempt to nullify
them, it is advised to interpose a message-oriented middleware between the communicating
softwares.
A Message-oriented middleware (MOM) is a software or hardware infrastructure
supporting sending and receiving messages between distributed systems. Most of the MOM
softwares implement the AMPQ protocol.

Advanced Message Queuing Protocol (AMQP) is an open standard application layer
protocol for message-oriented middleware. The defining features of AMQP are:
- Message orientation: only focused on handling messages
- Queuing: holds a queue of messages to process later
- Routing (including point-to-point and publish-and-subscribe): guides a message all
along the transportation phase
- Reliability: Ability of a computer program to perform its intended functions and
operations in a system's environment, without experiencing failure (system crash).
- Security: Defines how safe the software is from attacks initiated either from the local
network or from internet
RabbitMQ is the MOM that Dataproces formerly opted for. It was the intermediate
between the 3 agents of MOX (SBSys, orchestrator, Jupiter). If a message was to be processed,
from SBSys to orchestrator, it would have to go through those steps:
- SBSys wraps the case file object within a JSON object and joins the header
“RegistreringoutputType” to the object
- SBSys serializes the JSON object
- SBSys publishes the serialized JSON message to RabbitMQ
- At the meantime, a thread started on orchestrator is waiting to intercept all the
messages published on RabbitMQ with the header “RegistreringoutputType”
- Orchestrator therefore intercepts the serialized JSON message
- Orchestrator deserializes the serialized JSON message
- Orchestrator converts it back to a JSON object
- Orchestrator fetches the case file object from the JSON object
The process will be exactly the same with ZeroMQ.
Unfortunately, an intolerable delay in transmission was noticed with RabbitMQ. Which
led us to ZeroMQ which is deemed to be the fastest MOM [5] available on the market according to
a study compiled by M. Kuntal Ganguly, a popular Indian software engineer on his blog. Moreover,
this fact is also supported by many MOM users on several forums.

A comparative study [5] between ZeroMQ, RabbitMQ and other MOM like ActiveMQ,
Kafka, IronMQ, and Apache Qpid is below:
Table 1: Comparison between MOM

ZeroMQ is designed for fast and real time domain like the financial one where as
RabbitMQ tends to prioritize the integrity of a message to its processing time.
Message-oriented middlewares are based on the Producer/Consumer design pattern.
Conclusion
Presenting the current MOX project as well as its limitations, alongside with explaining
some major terminologies which are conducting it were the main concerns of this section. At the end
of this analysis, we can deduct that beside the basic duty of sending and receiving a message from
one entity to another, the project is also about ensuring a mutual authentication based
communication and securing the message transfer all along the process. A step forward can be
initiated by moving to analyze the needs and specifications of the project since we have a plainly
knowledge of what it is about.

CHAPTER 3: Needs’ analysis and
specifications

Introduction
Developing a software is a complex task which requires to take all the necessary
precautions before writing a single line of code. It is highly recommended amongst other things to
analyze the needs identified throughout the software preliminary study phase and to define a proven
conception methodology as the plinth of our coding implementation. This chapter will aim to depict
the features of the old MOX project which are also similar to the new implementation. A prior deep
study of the project had to be carry out in order to write this down.
I. Unified modeling language (UML) 2.0 [6]
The Unified Modeling Language (UML) is a general-purpose modeling language in the
field of software engineering, which is designed to provide a standard way to visualize the design of
a system.
UML is divided into two general sets and includes fourteen basic diagram types:
- Structural Modeling Diagrams: depicts the elements of a specification that are
irrespective of time
 Package Diagrams: Shows how model elements are organized into packages
as well as the dependencies between packages.
 Component Diagrams: Depicts the components that compose an application,
system, or enterprise. The components, their interrelationships, interactions,
and their public interfaces are depicted.
 Class or Structural Diagrams: Shows a collection of static model elements such
as classes and types, their contents, and their relationships.
 Deployment Diagrams: Shows the execution architecture of systems. This
includes nodes, either hardware or software execution environments, as well
as the middleware connecting them.
 Composite Structure Diagrams: Depicts the internal structure of a classifier
(such as a class, component, or use case), including the interaction points of
the classifier to other parts of the system.
 Object Diagrams: Depicts objects and their relationships at a point in time,
typically a special case of either a class diagram or a communication diagram.
 Profile Diagrams
- Behavioral Modeling Diagrams: depicts behavioral features of a system or business
 Use Case Diagrams: Shows use cases, actors, and their interrelationships.
 Sequence Diagrams: Models the sequential logic, in effect the time ordering of
messages between classifiers.
 Activity Diagrams: Depicts high-level business processes, including data flow,
or to model the logic of complex logic within a system.
 Timing Diagrams: Depicts the change in state or condition of a classifier
instance or role over time. Typically used to show the change in state of an
object over time in response to external events.

 State Machine Diagrams: Describes the states an object or interaction may be
in, as well as the transitions between states. Formerly referred to as a state
diagram, state chart diagram, or a state-transition diagram.
 Interaction Overview Diagrams: A variant of an activity diagram which
overviews the control flow within a system or business process. Each
node/activity within the diagram can represent another interaction diagram.
 Communication Diagrams: Shows instances of classes, their interrelationships,
and the message flow between them. Communication diagrams typically focus
on the structural organization of objects that send and receive messages.
Formerly called a Collaboration Diagram
We will stick to the most important of those diagrams in order to document our project:
use case diagrams, class diagram, sequence diagram, activity diagram, and deployment diagram.
II. Needs analysis
1. Functional requirements
Those requirements describe what the user expects of the software in term of
functionalities. They can be compiled in seven main needs:
- Publish a message to ZeroMQ : stores a JSON message within ZeroMQ
- Consume a message from ZeroMQ: retrieves a JSON message from ZeroMQ
- Avoid to publish the same message to ZeroMQ twice: if a case file is retrieved
more than once from the searching Web service, it should be published on the first
iteration and ignored later.
- Search for case files : retrieves the case files from the Searching Web Service
- Search for documents : retrieves the documents related to the case files from the
integration Web Service
2. Nonfunctional requirements
This second category of requirements represents technical features which are
essential throughout the implementation of the new version MOX project ordered by importance.
- Response-time: refers to the specific ability of a system or functional unit to
complete assigned tasks within a given time. ZeroMQ which is the fastest Message
oriented middleware system will address it.
The response-time between should be less than 1 minute for 38 case files
processed
- Security: Defines how safe the software is from attacks initiated either from the
local network or from internet. It is ensured by the mean of a file based user
authentication and SSL certificates.
Running the software should be subject to acquiring an authentic certificate.

- Reliability: Ability of a computer program to perform its intended functions and
operations in a system's environment, without experiencing failure (system crash).
It is ensured by the usage of ZeroMQ as intermediate between the softwares.
The using time observed in average between two crashes must be of at least 168
hours
III. Use cases analysis
UML utilizes uses cases in order to describe the functionalities that a system can
achieve. It provides a simple and meaningful overview of the different actions that can be performed,
as well as who can initiate them, disregarding the sequence in which they occur.
1. Use cases diagrams
For each main feature of the system, a use case diagram will be provided along with a
description to facilitate the comprehension.
The notions of case file and cache database must be introduced at this point. A case
file is a simple java structure which compiles information about a single water supply operation.
The cache database will assist us in avoiding to publish a case file twice. When a case
file is to be published, the system checks if the case file already exists in the database. If not, the
case file is processed and saved in cache; else it is merely skipped. The cache is refreshed each
day as well as the pooling method of case files.

Figure 9: Use case <manage a case file>
Use case 1 Create the database
Trigger SBSYS wants to create the caching file to store already published
casefiles in
Primary actors SBSYS
Secondary actors Cache.db
Preconditions The database doesn’t exist yet
Steps in the process 1) SBSYS checks whether the file "cache.db" exists
2) SBSYS creates a file called cache.db
3) SBSYS creates a data table (Casefiles) within the database
Exceptions
Alternate flow 1) a) SBSYS exits the creating process
Post conditions
Table 2: Use case 1 <create database description>

Use case 2 Cache a case file
Trigger SBSYS aims to add or modify a casefile in the database
Preconditions The database is already created
Steps in the process 1) checks whether the case file already exists
2) add the case file to the database
Exceptions 1) a) The executed request is not well written
Alternate flow 1) a) the status of the case file is updated in the database
Post conditions
Table 3: Use case 2 <cache a case file description>
Use case 3 Remove a case file from the database
Trigger SBSYS wants to remove a case file that it has already published from the
database
Preconditions The database is already created
Steps in the process 1) Delete the case file from the cache
Exceptions 1) The case file in instance is not saved in the database
Alternate flow
Post conditions
Table 4: Use case 3 <remove a case file from the database description>
In the MOX project, we do have 2 main types of messages regarding the flow direction:
- Output messages: messages leaving an agent for another
- Input messages: messages coming in an agent
It is necessary to point out that to each output message corresponds an Input message
which constitutes the response to the Output message.
Moreover, 3 types of messages can be enumerated when considering the content:
- Laes (lading): It creates and process documents between SBSys and orchestrator
- Opret (create): messages exchanged between orchestrator and Jupiter
- Registrering/ ret (registration): in this case “registrering” is used for outgoing
messages, whereas “ret” is for incoming messages. They represent the starting
and final states of messages exchanged
Case files are encapsulated within JSON messages and therefore need to be
processed by this mean. JSON (JavaScript Object Notation) is an open standard format used to
describe an object consisting on pairs of keys and values.

Figure 10: Use case <process a case file>

Use case 4 Publish a registeringOutput type message
Trigger SBSYS wants to process a new case file retrieved from the searching
web service
Secondary actors Search web service, cache, ZeroMQ
Preconditions SBSYS has retrieved a list of case files from the searching web service
Steps in the process
1) SBSYS converts each full case file into a registeringOutputType from
the case domain.
2) SBSYS wraps the outcome into a registeringOutputType from the case
domain.
3) SBSYS inserts this registeringOutputType into the body of a JSON
message, attaches the proper headers, and then publishes the message
to ZeroMQ exchange.
4) SBSYS caches the published case file so that it doesn't publish a
certain case file more than once.
Exceptions 1) a) the full case file to convert is not well formatted
Alternate flow
Post conditions
Table 5: Use case 4 <publish a registeringOutputType message description>
Use case 5 Consume a registeringOutput type message
Trigger Orchestrator wants to consume a registeringOutputType message
Primary actors Orchestrator
Secondary actors ZeroMQ, cache
Preconditions SBSYS has published a registeringOutputType message
Steps in the process 1) Orchestrator picks the RegistreringOutputType message that was
published by the SBSys agent.
2) Orchestrator extracts the RegistreringOutputType object from this
message.
Then for each post in the RelationListe of the RegistreringOutputType,
the Orchestrator:
3) Orchestrator creates a new LaesInputType from the
GenerelleOperationer domain.
4) Orchestrator sets the ID of this LaesInputType to the reference ID of
the post.
5) Orchestrator inserts this LaesInputType into the body of a JSON
message.
6) Orchestrator inserts the case ID into the body of a JSON message.
7) Orchestrator attaches the proper headers.
8) Orchestrator publishes the message to ZeroMQ exchange.
Exceptions 1) a) The deserialization of the message retrieved from ZeroMQ fails
Alternate flow
Post conditions
Table 6: Use case 5 <consume a registeringOutputType message description>

Use case 6 Consume a laesInput type message
Trigger SBSYS wants to consume a laesInput type message
Secondary actors ZeroMQ, cache, integrationWebService
Preconditions Orchestrator has published a laesInput type message
Steps in the process 1) SBSYS picks the LaesInputType message that was published by the
Orchestrator agent.
2) SBSYS extracts the LaesInputType object from this message.
3) SBSYS retrieves the document from SBSys based on the ID in
the LaesInputType object.
4) SBSYS adjusts the RelationListe of the retrieved document.
5) SBSYS wraps the document in a LaesOutputType from the Dokument
domain.
6) SBSYS creates a file entity to encapsulate the document name,
extension and content.
7) SBSYS inserts the LaesOutputType and the file entity into the body of
a JSON message.
8) SBSYS attaches the proper headers.
9) SBSYS publishes the message to ZeroMQ exchange.
Alternate flow
Post conditions
Table 7: Use case 6 <consume a laesInputType message description>

Use case 7 Consume a laesOutputType message
Trigger Orchestrator wants to consume a laesOutput type message
Preconditions SBSYS has published a laes Output type message
Steps in the process 1) Orchestrator picks the LaesOutputType message that was published
by the SBSys agent.
2) Orchestrator extracts the LaesOutputType object from the message.
3) Orchestrator extracts the document from this LaesOutputType object.
4) Orchestrator extracts the file entity from the message.
5) Orchestrator creates a new OpretInputType1 from the Dokument
domain.
6) Orchestrator sets the RelationListe of this OpretInputType1 to
the RelationListe of the document.
7) Orchestrator inserts the OpretInputType1 and the file entity (only if it's
a PDF file) into the body of a JSON message.
Alternate flow
Post conditions
Table 8: Use case 7 <consume a laesOutputType message description>

Use case 8 Consume a opretInput type message
Trigger Jupiter wants to consume a opretInput type message
Primary actors Jupiter
Preconditions Orchestrator has published a opretInput type message
Steps in the process 1) Jupiter picks the OpretInputType1 message that was published by the
Orchestrator agent.
2) Jupiter extracts the OpretInputType1 object from the message.
3) Jupiter extracts the file entity from the message.
4) Jupiter creates a water supply report (vandforsyningsrapport) from the
text of the PDF file. The report adheres to the latest version of the water
supply report template that is used by Hjørring commune (see below).
5) Jupiter inserts this report into the Jupiter system using the Jupiter write
service.
6) Jupiter creates a new OpretOutputType from the Dokument domain.
7) Jupiter sets the RelationListe of this OpretOutputType to the
RelationListe of the OpretInputType1.
8) Jupiter inserts the OpretOutputType into the body of a JSON message.
9) Jupiter attaches the proper headers.
10) Jupiter publishes the message to ZeroMQ exchange.
Alternate flow
Post conditions
Table 9: Use case 8 <consume a opretInputType message description>
Use case 9 Consume a opretOutput type message
Trigger Orchestrator wants to consume a opretOutputtype message
Preconditions Jupiter has published a OpretOutput type message
Steps in the process 1) Orchestrator picks the OpretOutputType message that was published
by the Jupiter agent.
2) Orchestrator extracts the OpretOutputType object from the message.
3) Orchestrator creates a new RetInputType from the Sag domain.
4) Orchestrator sets the case ID in this RetInputType from the
RelationListe in the OpretOutputType.
5) Orchestrator sets the progress code type (FremdriftStatusKodeType)
of the case in this RetInputType to completed (afsluttet).
6) Orchestrator inserts the RetInputType into the body of a JSON
message.
Alternate flow
Post conditions
Table 10: Use case 9 <consume a opretOutputType message description>

Use case 10 Consume a retInput type message
Trigger SBSYS wants to consume a retInput type message
Preconditions Orchestrator has published a retInput type message
Steps in the process 1) SBSYS picks the RetInputType message that was published by the
Orchestrator agent.
2) SBSYS extracts the RetInputType object from the message.
3) SBSYS obtains the case ID from this RetInputType object and assigns
it to a new UpdateCaseFileRequest.
4) SBSYS obtains the progress code type from this RetInputType object
and assigns it to the same new UpdateCaseFileRequest.
5) SBSYS updates the case file with the progress code type by invoking
the SBSys integration service.
Alternate flow
Post conditions
Table 11: Use case 10 <consume a retInputType message description>
Figure 11: Use case <interact with jupiter database>

Use case 11 Read data from Jupiter database
Trigger JUPITER wants to read an information from the jupiter’s database
Primary actors JUPITER
Secondary actors jupiterDB
Preconditions
Steps in the process 1) Jupiter logs into the Jupiter database
2) Jupiter reads the data
Exceptions 1) a) The logging to the database fails
Alternate flow
Post conditions
Table 12: Use case 11 <read data from jupiter database description>
Use case 12 Write data on Jupiter database
Trigger JUPITER wants to write an information on the jupiter’s database
Primary actors JUPITER
Secondary actors jupiterDB
Preconditions
Steps in the process 1) Jupiter logs into the Jupiter database
2) Jupiter writes the data
Exceptions 1) a) The logging to the database fails
Alternate flow
Post conditions
Table 13: Use case 12 <write data on jupiter database description>

2. System sequence diagram
A system sequence diagram displays the flow of message exchanges between the
actors and the system over the time. It clearly draws a picture of the sequence in which the exchange
is done and therefore prioritizes time oriented operations.
For each sequence diagram below, a brief description will be provided.
Figure 12: System sequence diagram 1 <create the database>
The need to avoid publishing a case file on ZeroMQ twice leads to the implementation
of a caching mechanism.
The first action to accomplish here is to check if the caching file has already been
created.
If not, proceed to those actions sequentially:
- Create the file
- Create the table
Else, terminate the ongoing operation.

Figure 13: System sequence diagram 2 <cache a case file>
To cache a case file is typically to register it as already processed in the system.
Two operations can be achieved by caching a casefile, either the case file’s status is
updated; in which case there is no new line added to the table. Else, a line is added to register the
newly published case file.

Figure 14: System sequence diagram 3 <delete a case file>
Each day, case files from the day before are removed from the caching file in an
attempt not to overload the file in instance.
Removing a case file from the cache consists in:
- Checking if the case file exists
- If yes, the system will send us back the case file number
- Then we can delete the case file by the mean of the case file number
- Otherwise, if the case file is not found, the entire operation is cancelled

Figure 15: System sequence diagram 4 <process a case file>
This sequence diagram summarizes the process that a case file has to go through
within the MOX project.

Figure 16: System sequence diagram 5 <read data from jupiter database>
The Jupiter database is accessible by almost each third desiring to retrieve information
from it. However, within the Jupiter project, it is necessary to log in the system in order to get data
from it.
If something goes wrong, the whole operation will be aborted. Otherwise, the Jupiter
agent will get the required information.

Figure 17: System sequence diagram 6 <write data on Jupiter database>
It is also obligatory to log in to the Jupiter database in order to write in it. Contrarily to
the reading process, which is optional out of the Jupiter project, logging in is not optional for the
writing one.
If something goes wrong, the whole operation will be aborted. Otherwise, the Jupiter
agent will save the information in the Jupiter database.
However, it is pertinent to notice that some of the actions performed on this message
flow are achieved asynchronously, in other words, the gap of time between those messages cannot
be accurately determined. Anyway, the action following another cannot be reached as long as the
previous action is not completed for a specific case file.
Conclusion
The current chapter was intended to shed more light on our system’s functionalities. A
clear observation is the message exchange oriented architecture that the MOX project is based on.
Reached this point, a particular attention should be brought to model our system.

CHAPTER 4: Software conception

Introduction
The conception of a software is this phase of its development cycle where all the
decisions are taken regarding all the aspects of its implementation (architecture, tools, development
language, IDE, process). The decisions taken are represented throughout diagrams according the
modeling methodology which had been put in practice.
The following main UML diagrams will be displayed on this section: Class diagram,
Object sequence diagram, Activity diagram. A software deployment diagram, which is pretty close
of the UML deployment diagram will be presented and deeply explained also.
I. Software deployment
A representation of the architecture of our MOX system, enlightening the different
actors as well as the interactions which are initiated between them can be seen below:
Figure 18: Software deployment architecture

Before proceeding to the explanation of this architecture, it is first of all essential to
point out two facts:
- The arrows representing interactions are either unidirectional or bidirectional:
indeed, the directions are set according to the sense in which the flow of message
is moving, therefore if messages can be moving two ways, those arrows will turn to
bidirectional ones.
- The numeration purpose is to ease the explanation of the message exchanges, it
doesn’t accurately describe the sequence in which messages are exchanged
Now that every ambiguity is cleared about our representation, we can move to explain
what it is about:
1 – Case files are sent from the searching web service to the SBSYS agent
2. A – SBSYS agent sends information to the integration web service
2. B – SBSYS agent receives information from the integration web service
3. A – SBSYS agent publishes JSON messages to ZeroMQ
3. B – SBSYS agent receives JSON messages from ZeroMQ
4. A – SBSYS agent add, update or delete case files in the cache
4. B – SBSYS checks whether a case file is already cached
5. A – Orchestrator agent publishes JSON messages to ZeroMQ
5. B – Orchestrator agent receives JSON messages from ZeroMQ
6. A – Jupiter agent publishes JSON messages to ZeroMQ
6. B – Jupiter agent receives JSON messages from ZeroMQ
7 –Notes: Each message exchange with the Jupiter web service requires a beforehand
authentication
7. A – Jupiter agent retrieve information from the Jupiter web service
7. B – Jupiter agent insert information in the Jupiter web service
8. A – Jupiter web service gather information from the Jupiter database
8. B –Jupiter web service update the Jupiter database
9 – Case files are transported from the Jupiter database to the searching web service

II. Class diagram
Figure 19: Class diagram

An attempt to provide a meaningful globalizing explanation of the structure of this diagram is
obvious due to its complexity.
What we should keep in mind is that the main objective of developping the MOX project is
merely to exchange messages on a text format, those messages are following the JSON structure.
In the MOX project, a JSON message is encapsulating either case files or documents. Another
remark to point out is that a JSON message is composed by a header and a body. The header is meant to
assist zeroMQ to route the message to the appropriate client.
All those operations are processed by three agents SBSYS, orchestrator and jupiter which are
all extending a parent class "agent".
However the jupiter agent has a more crucial influence on the whole system, since it is
supposed to generate reports and publish them on the government database. Therefore, the jupiter agent
generates and publishes Vandforsyningsrapport by the mean of a JupiterWriter class. This same agent can
access the database for reading purposes using the JuputerReader class.
III. Object sequence diagram
Unlike the system sequence diagram presented in the previous chapter, an object sequence
diagram pays more attention to list up all the actors exchanged in message exchanges, even the minor ones.
Thus there is no more system actor but instead, actors which represent a specific entity of the system by
themselves.
An object sequence diagram which will summarize all the scenarios that have been described
upper will be realized.

Figure 20: Object sequence diagram

IV. Activity diagram
Activity diagrams [7] are graphical representations of workflows of stepwise activities
and actions with support for choice, iteration and concurrency. In the Unified Modeling Language,
activity diagrams are intended to model both computational and organizational processes (i.e.
workflows). Activity diagrams show the overall flow of control.
Figure 21: Activity diagram

Conclusion
At this point, you would have definitely get the whole picture of MOX in term of process,
how the software is organized and why is MOX a so well rounded oiled machine. Nevertheless, there
is still a remnant doubt about how did we achieve this and what does it looks like. The next chapter
will address it.

CHAPTER 5: Tests and realization

Introduction
The current chapter will be entirely devoted to clarify the tools that helped us to build
the MOX system, a subdivision of those items will be done according to their main purpose, which
will lead us to 4 different kind of tools: Material environment, Development environments, Platforms
and servers. The second part of the chapter will reply to the question how did we organize our work
over this period of 6 months, and finally a preview of our final result alongside with a thorough
explanation of each screen capture will be provided.
I. Working environment
1. Material environment
Dataproces is equipped of LENOVO laptops which characteristics are:
- Tactical touch screen
- Windows 7 professional service pack 1
- Intel(R) Core(TM) i7-4712MQ CPU @ 2.30 gHz
- 8 GB of RAM
- 64-bit.
2. Development environments
ECLIPSE is the most popular java development environment and will
therefore be the one we are going to write our code with. The advantage of
eclipse is its integration of several external libraries and plugins created by
an extended and active community of freelance developers.
Since the first version of the MOX project is written in C#, the need of
deploying this version on our development computer has been raised.

3. Platforms
Stash is our versioning server. It is storing versions of our code and allows us
to browse previous versions and if needed, restore files to a previous state in
case of unexpected incident.
Bamboo is our continuous integration server, it is listening to each change
committed on Stash an triggers the tests within stash repositories.
Furthermore, you can get statistics and code coverage metrics.
Jira assists us in organizing our work and assessing our pace as a scrum
team. It generates diagrams which display in a simple manner measures like
fixed issues over a period on time, scrum team involvement, the sprint
burndown.
Confluence is a set of web documents edited by employees themselves. It is
meant to help the different departments of the company to share information
together as well as reinforcing the cohesion within a department.
4. Softwares
Edraw is a lightweight and easy to use designing software. The unicity of
Edraw comes from its large capacities in term of diagrams as it allows
users to create customized diagrams without following any predefined
formalism.
PowerAMC is a powerful UML designing software
SmartGit is a GIT client software. Its goal is to help us to manage our local
repositories and also the synchronization with the remote one (on stash).

5. Technologies
The eight version of java is the most complete and stable release of the
language. It integrates a lot of built-in features and programming extensions
such as lambda expression which was so far proper to the .net platform.
Since the first version of the MOX project is written in C#, a prerequisite to
work on this project was to have a good knowledge of the .net programming
language.
Git is a distributed revision control system with an emphasis on speed, data
integrity, and support for distributed, non-linear workflows.
(JavaScript Object Notation) is an open standard format that uses human-
readable text to transmit data objects consisting of attribute–value pairs.
JUnit is a unit testing framework for the Java programming language.
Apache log4j is a Java-based logging utility.
ØMQ is a high-performance asynchronous messaging library, aimed at use
in scalable distributed or concurrent applications.
RabbitMQ is open source message broker software (sometimes called
message-oriented middleware) that implements the Advanced Message
Queuing Protocol (AMQP).
Maven is a build automation tool used primarily for Java projects
SQLLITE is an in-process library that implements a self-contained, server
less, zero-configuration, transactional SQL database engine.

The Java API for XML Web Services (JAX-WS) is a Java programming
language API for creating and consuming web services.
Mockito is an open source testing framework for Java released under the
MIT License. The framework allows the creation of test double objects
(mock objects) in automated unit tests for the purpose of Test-driven
Development (TDD) or Behavior Driven Development (BDD).
Artifactory will be our repository management server
6. Servers
Internet Information Services (IIS) is an extensible web server created by
Microsoft for use with Windows NT family

II. Gantt diagram
The Gantt diagram depicts how the project’s tasks are scattered over the time frame
of the project life-cycle. Our internship lasted 5 months and the tasks fulfilled are below:
Figure 22: Gantt diagram
III. Implementation
This part of our report will consist in a sequential summary of the task that were
achieved along with a clear explanation of the purpose of each of them as well as how they have
been proceeded. However, I would like to point out that some of them were obvious, were as others
have been deducted according to various constraints.
1. Product Backlog
The agile product backlog in Scrum is a prioritized features list, containing short
descriptions of all functionality desired in the product. During our internship, the features’ list to
ensure where:
ID Summary Assignee
Story
Points
Status Priority
1 Read up documentation for SBSYS
Emmanuel
Padjinou
13 Closed Major
2
Create and deploy test case for first behaviour of the
first phase of the mox project
Emmanuel
Padjinou
13 Closed Major
3
Identify the components that need to be tested for the
first behaviour of the first phase of the mox project
Emmanuel
Padjinou
13 Closed Major

4
Create fake locals .net web services for the sake of
testing envirronment
Emmanuel
Padjinou
8 Closed Major
5
Provide the testing environnment with dummy data
from the .net project
Emmanuel
Padjinou
8 Closed Major
6
Test the access to the integration and searching web
services locally
Emmanuel
Padjinou
8 Closed Major
7
Implement SagRetInputMessageHandler(SBSys) of
MOX phase1 using Java/zeroMQ.
Emmanuel
Padjinou
13 Closed Major
8
Implement
DokumentOpretOutputMessageHandler(Orchestrator)
of MOX phase1 using Java/zeroMQ.
Emmanuel
Padjinou
13 Closed Major
9
Fake the behaviour of the method
SearchForCaseFilesInSbSys inside
CasePollingBahaviour
Emmanuel
Padjinou
8 Closed Major
10 Test the method create cache in DBCache
Emmanuel
Padjinou
5 Closed Major
11
Test the method
RemoveCahedCaseFilesBeforePeriod in DBCache
Emmanuel
Padjinou
5 Closed Major
12 Test the method IsCaseFileCached in DBCache
Emmanuel
Padjinou
5 Closed Major
13 Test the method CacheCaseFile in DBCache
Emmanuel
Padjinou
5 Closed Major
14 Test the method getConnection in SQLLite
Emmanuel
Padjinou
5 Closed Major
15 Test the method createTable in SQLLite
Emmanuel
Padjinou
5 Closed Major
16 Test the method executeQuery in SQLLite
Emmanuel
Padjinou
5 Closed Major
17 Test the method executeScalar in SQLLite
Emmanuel
Padjinou
5 Closed Major
18
Fake the behaviour of the method
GetCaseFileFromSBSys inside
CasePollingBahaviour
Emmanuel
Padjinou
8 Closed Major
19
Check whether the Poller removes only obsolete
casefiles from the cached db
Emmanuel
Padjinou
3 Closed Major
20
Check whether the poller retrieves only casefiles of
the current day from the cached db
Emmanuel
Padjinou
3 Closed Major
21
Check whether the poller publishes the casefiles to
zeroMQ
Emmanuel
Padjinou
3 Closed Major
22
Check whether the poller avoids publishing the same
case file to zeroMQ twice
Emmanuel
Padjinou
3 Closed Major

23
Check whether the poller adds the casefile to the
cached db after publication
Emmanuel
Padjinou
3 Closed Major
24
Test the method convert in
CaseFileResponseConverter
Emmanuel
Padjinou
13 Closed Major
25
CaseFileStatusCodeConverter
Emmanuel
Padjinou
5 Closed Major
26
DokumentResponseConverter
Emmanuel
Padjinou
5 Closed Major
27
FremdriftStatusKodeConverter
Emmanuel
Padjinou
5 Closed Major
28 Test JSON serialization
Emmanuel
Padjinou
2 Closed Major
29 Test JSON serialization for table of bytes
Emmanuel
Padjinou
2 Closed Major
30 Test the method FromCase in CaseHeadersBuilder
Emmanuel
Padjinou
8 Closed Major
31
Test the method FromDocument in
DocumentHeadersBuilder
Emmanuel
Padjinou
8 Closed Major
32
JsonMessageToOioConverter
Emmanuel
Padjinou
3 Closed Major
33
Move the unit tests of the SBSYS_test project to the
SBSYS project testing directory
Emmanuel
Padjinou
1 Closed Major
34 Delete the SBsys_test project from stash
Emmanuel
Padjinou
3 Closed Major
35
Does the orchestrator receive a
SagRegistreringOutput Message from SBSYS
Emmanuel
Padjinou
8 Closed Major
36
Does the orchestrator send a LaesInputType
Message to SBSYS
Emmanuel
Padjinou
8 Closed Major
37
Does SBSYS receive a LaesInputType Message from
orchestrator
Emmanuel
Padjinou
8 Closed Major
38
Does orchestrator receive a LaesOutputType
Message from SBSYS
Emmanuel
Padjinou
5 Closed Major
39
Does SBSYS send a LaesOutputType Message to
orchestrator
Emmanuel
Padjinou
5 Closed Major
40
Does orchestrator send a OpretInputType Message
to Jupiter
Emmanuel
Padjinou
8 Closed Major
41
Set the jupiter project READY for the testing
environment
Emmanuel
Padjinou
13 Closed Major

42
Does Jupiter receive a OpretInputType message from
orchestrator
Emmanuel
Padjinou
3 Closed Major
43
Does Jupiter send a OpretOutputType message to
orchestrator
Emmanuel
Padjinou
3 Closed Major
44
Does orchestrator receive a OpretOutputType
message from jupiter
Emmanuel
Padjinou
3 Closed Major
45
Does Orchestrator send a SagRegisteringType
message to SBSYS
Emmanuel
Padjinou
3 Closed Major
46
Investigate why are some case files lost in the
process
Emmanuel
Padjinou
13 Closed Major
47
Make junit able to assess the rate of success when
processing case files
Emmanuel
Padjinou
3 Closed Major
48
Does SBSYS receive a SagRegisteringType
message from orchestrator
Emmanuel
Padjinou
3 Closed Major
49 Setting up MOX testing project in Bamboo
Emmanuel
Padjinou
13 Closed Major
50
Change the publisher subscriber architecture model
on zeroMQ
Emmanuel
Padjinou
13 Closed Major
51
Investigate why are some tests failing through maven
whereas they run well on junit
Emmanuel
Padjinou
13 Closed Major
52 Reorganize the package structure of MOX
Emmanuel
Padjinou
5 Closed Major
53
Create a development and release branches for the
Java MOX project
Emmanuel
Padjinou
5 Closed Major
54 Fix the maven jar dependencies issues on Bamboo
Emmanuel
Padjinou
5 Closed Major
55
Set up a server repository management on my
machine
Emmanuel
Padjinou
5 Closed Major
56 Document the new git branching strategy
Emmanuel
Padjinou
1 Closed Major
57 Document the new mox project package structure
Emmanuel
Padjinou
1 Closed Major
Table 14: Product backlog

2. Writing unit tests
Unit testing is the software testing level in frame of which individual units of source
code are tested to determine whether they are fit for use. A unit here can be a single method, or
even a whole class.
Testing a method consist in furnishing a set of different parameters in input and
predicting the output that we will get back in return. It is important to remember that what matters the
most about unit testing is more the pertinence of tests than the number.
Two strategies will be implemented to assert whether the tests were executed
successfully.
- Junit assertion : permits to check whether a final result corresponds to what we
were expecting
Figure 23: Junit assertion
- Catching exceptions: verifies if a specific scenario throws an exception as intended
Figure 24: Expected exception catched
An inevitable notion in testing is Mockito, the tool was mostly used to simulate the
reaction of the client’s web service within the testing environment.
Figure 25: Mocked object declaration

Figure 26: Mocked object behavior customized
The shot screen upper shows how is the method “getCaseFile” of the integration Web
Service mocked.
The naming pattern chosen for unit tests is *Test.java, where * represents any
character or sequence of characters; it is also the default built-in pattern of Maven 3.
Apache Maven (Maven 3) is a software project management and comprehension tool.
It executes a sequence of goals in order to build a project, where each goal upper on the chain
encapsulates and triggers by default the goals under it. A goal is simply a Maven’s step.
A representation of the maven steps associated to their respective plugins is below:
Figure 27 : Maven phases

A summary of maven phases as well as their related goals and purpose [8] will be
provided below:
Phase Goal Description
Generate-sources Validate Validate the project is correct and all necessary
information is available
Compile Compile Compile the source code of the project
Test-compile Test-compile Compile the test code of the project
Test Test Test the compiled source code using a suitable unit
testing framework. These tests should not require the
code be packaged or deployed
Package Package Take the compiled code and package it in its
distributable format, such as a JAR.
Integration-test Integration-test Process and deploy the package if necessary into an
environment where integration tests can be run
Install Install Install the package into the local repository, for use as
a dependency in other projects locally
Deploy Deploy Done in an integration or release environment, copies
the final package to the remote repository for sharing
with other developers and projects.
Table 15: Maven phase's and goal's description
Executing those unit tests will require to execute the goal “test” of Maven 3. This goal
will, not only launch the previous ones (Validate, Compile, and Test-compile) but also trigger its
specific reaction which is explained in the table above.
3. Writing integration tests
Contrarily to a unit test, an integration test is not only limited on an individual unit but
rather on the interactions between those units. An interaction can include two or more units and is
often aiming a larger testing scope that unit tests.
In our case, the integration tests interact with the logging file and the cached database.
Therefore, those components should be reinitialized prior to any integration test.
The pattern chosen for integration tests is *IT.java where * represents any character
or sequence of characters.
Executing those tests will require to execute the goal “integration-test” of Maven 3.
4. Preparing the continuous integration environment
Running unit tests and integration tests side by side is a risky initiative. Indeed, unit
tests are self-dependent whereas integration tests can depend of one or more external components.
Whenever one of those external components misbehaves, if the unit tests and integration tests are
launched together, the whole build will fail.
In our case, a different repository has been allocated for each testing phase. The
picture below depicts the organization of our folders:

Figure 28: Package and source folder organization
The major point of a revision control system is to facilitate the development process by
offering a reading and writing access to previous versions of the source code scattered on different
branches. A branch can be defined as a sequence of versions of source code wrapped within a label.

Figure 29: Git branching strategy
Each branch is meant to serve a precise goal:
- Release: final tested and approved version of our source code, ready for delivery
- Master: the main branch, which ensures that we keep a history of all the versions
of the code. Each crash can be palliated by cloning the appropriate version of the
code on the master branch
- Java: coding branch, all the increments of coding are done here
- CI: monitored by the continuous integration server and triggers jobs at each
modification. It contains a version of the code which can be tested by the
continuous integration server.

5. Installing and configuring artifactory
Installing artifactory requires a deftly approach. The tool is offered with a bat file which
is basically a succession of batch commands, unfortunately those commands are standard and might
differ from one computer to another. This constrains us to run through all the commands and execute
them one by one, after taking care of modifying them when necessary.
Artifactory exposes distant and local repositories.
Figure 30: Artifacts exposed by artifactory

6. Integrating artifactory with bamboo
The integration of artifactory on Bamboo requires to add the Artifactory plugin of
Bamboo and to configure the aforementioned.
The plugin is called “artifactory maven 3 plugin”, after installation, it is possible to add
this capability to one of the active agents of Bamboo. Our instance of Bamboo only possesses the
single default agent.
Figure 31: Capabilities of the default agent
Then a job using this capability of the agent can be configured.
Figure 32: Adding the Artifactory Maven 3 dependency to a job

7. Unit testing results
Bamboo hosts a set of plans that might be to launch automatically or manually.
Figure 33: List of plans configured on Bamboo
A plan is a succession of jobs that are organized into stages. A plan launches each of
its stages in a chronological order. Our plan’s name is “Java MOX unit testing”.
Figure 34: Stages within the Java MOX unit testing plan
Our plan is executed in two phases:
- Initialize artifacts consists in downloading the artifacts necessary to compile the
source code. This merely corresponds to the entire source code fetched by the CI
branch. The picture below represents the downloaded artifacts:

Figure 35: Artifacts produced by the first job “initialize artifacts”
- Test runs the artifactory maven 3 capability on the current working directory which
is a complete replication of the last commit in the CI Git branch.
A green bar wrapping the build number attests whether the built has gone well.
Figure 36: Plan successfully runned
Reports can be viewed compiling general trends on a specific period.
The build activity diagram represents the number of build spread on a period of 10
days, between July 16th
and 26th
.

Figure 37: Build activity diagram
The build duration diagram represents the average duration of builds spread on a
period of 10 days, between July 16th and 26th.
Figure 38: Build duration diagram
The percentage of successful builds diagram represents the number of successful
builds spread on a period of 10 days, between July 16th and 26th.

Figure 39: Percentage of successful builds
8. Statistics
To gather some metrics regarding the performances of our software, a class has been
added which generates statistics at the end of the integration tests.
Those statistics are:
- The number of case file retrieved from the pooler
- The number of messages sent from SBSYS to orchestrator during the first
exchange
- The number of messages sent from orchestrator to SBSYS during the second
exchange
- The number of messages sent from SBSYS to orchestrator during the third
exchange
- The number of messages sent from orchestrator to Jupiter during the fourth
exchange
- The number of messages sent from Jupiter to orchestrator during the fifth exchange
- The number of messages sent from orchestrator to SYSYS during the sixth
exchange
- The number of messages published on ZeroMQ
- The number of messages consumed on ZeroMQ by orchestrator
- The number of messages consumed on ZeroMQ by SBSYS and Jupiter
- The number of lost messages
- The success rate
- The time elapsed to process all the 38 testing case files

Figure 40 : Statistics
Beside those personalized statistics, there are native maven statistics that can be
presented as well. They are:
- The number of tests processed in total
- The number of failed tests
- The number of tests which lead to errors
- The number of skipped tests
- The time to conduct each test alongside with the time to conduct all the tests which
is different from the time elapsed to process 38 case files, since the later also
includes the other Maven phases.
A capture of the Maven results that we have got is below:
Figure 41: Maven results

Conclusion
The chapter was essentially about describing the software and hardware working
environment. Afterwards, a diagram summing up the organization of the achieved tasks over the
time has been presented and finally a general overview of the final result was displayed throughout
shot screens.

Overall conclusion
This document summarizes our internship at Dataproces in Denmark on a time frame
of 5 months, since our first day in the company. The main objective was to write down tests for the
MOX project which is on its way to be rewritten in another technology, as well as setting up the
continuous integration server, in instance Bamboo to handle continuous integration of the new MOX
version and applying the required modifications on the former source code when needed to. To carry
out our duty, we went through 5 phases:
The first phase consisted in introducing the company (Dataproces), then we
announced the problematic to resolve and finally a comparison of different working technologies
finalized by the choice of an agile method (SCRUM) coupled to a software development method, in
instance TDD. Speaking about the second phase, it was essentially about presenting the current
MOX project, studying the different notions that might be needed to get a full understanding of the
report. Thirdly, we moved forward to analyzing the needs as well functional and non-functional which
we illustrated through use cases and system sequence UML diagrams. Getting close to the end of
our report, the fourth phase was depicting the conceptual aspect of our new MOX software by the
mean of a class diagram, object sequence diagrams and activity diagrams. Finally, the fifth and last
phase of the report briefly provides an overview of the final result at the end of our work, by listing
up the software and technologies involved, displaying a diagram summarizing the tasks that we
fulfilled as well as their sequence over time and a couple of interfaces explained in detail.
We can definitely be satisfied of the new assets that we have got during this experience
at Dataproces, amongst other things, a deeper understanding of middleware oriented messages,
unit-testing and mostly the importance of a tool like Mockito. In order to do well during our internship,
it was important to have beforehand a good capacity to manage our time, great team working skills
which have helped us to make an impact, autonomous work as well as the ability to find the finest
solution to a problem we are confronted to.
A further development of our solution might be considered by providing a more user-
friendly graphic interface to users. Moreover, a better interaction machine-user is feasible if we
considered sending reports compiling statistics to users either by email or on their mobile phones.

Bibliography and sources
[1] https://www.scrum.org/Resources/What-is-Scrum
[2] https://en.wikipedia.org/wiki/Test-driven_development
[3] http://www.geus.dk/DK/data-maps/jupiter/Sider/default.aspx
[4] http://www.codeproject.com/Articles/326574/An-Introduction-to-Mutual-SSL-Authentication
[5] http://www.kuntalganguly.com/2014/08/message-queue-comparision.html
[6] http://www.sparxsystems.com.au/resources/uml2_tutorial/
[6] http://www.agilemodeling.com/essays/umlDiagrams.htm
[7] https://en.wikipedia.org/wiki/Activity_diagram
[8] https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html

Appendices
A1 ZeroMQ
A2 Broker design pattern
The Broker pattern hides the implementation details of remote service invocation by
encapsulating them into a layer other than the business component itself.
This layer provides an interface to the client that allows it to invoke methods just as it
would invoke any local interface. However, the methods inside the client interface trigger services to
be performed on remote objects. This is transparent to the client because the remote service object
implements the same interface. This pattern refers to the business component that initiates the
remote service invocation as the client, and the component that responds to the remote service
invocation as the server.
The figure below shows the static structure of a simple example without any
distribution. The client invokes the performFunctionA method on the server directly. This is possible
only if the server objects reside on the same computer as the client objects.

A3 Producer/Consumer design pattern
A4Short Casefile structure

A5 Case file structure

A6 Continuous integration
A7 MOX project organization

Rewrite a message exchange system and set up its testing environment

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (13)

Ähnlich wie Rewrite a message exchange system and set up its testing environment

Ähnlich wie Rewrite a message exchange system and set up its testing environment (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Rewrite a message exchange system and set up its testing environment