Dedication

To my dear dad who carried me to school on his back every day when I was little.

To my dear mother who believed in me and continues to encourage me to make my

dreams come true.

To my darling grandmother. I wish you could have been there. May God have your
soul in his holy mercy.

To my brothers Mohamed Aymen and Achref for their support.

“A brother shares childhood memories and grown-up dreams.” – Garrison Keillor

To my bestfriend Farah for being there for me during all the internship program and
encouraged me to get through all the hardships. You’ve been the best cheerleader ever!

To all my extended family : The love of the family is the life’s greatest blessing.

GRADUATION PROJECT iii

Acknowledegment

At the conclusion of this internship, I would like to thank the people who contributed
to making this period an enriching experience and full of interest for my professional
future. In particular, I would like to express my gratitude and high consideration to :

- My supervisor, Mrs Nehed Ben Slimene, for the honour of working with her
team and for the help she gave me during all the stages of this internship. Her
availability, guidance and advice were invaluable in achieving the objectives of
the project within the agreed timeframe.

- My supervisor, Mrs. Rahma Dhaouadi, for her continuous assistance throughout

the realization of this project and for the time she generously devoted to me.

- The entire ESPRIT teaching team as well as the professional contributors

responsible for our curriculum.

- To all the staff of FIS Tunisia for their kindness and sympathy especially Mr
Bassem Hayder , Mrs Soumaya Jelassi and Mrs Chiraz Amara.

My last word is addressed to all the members of the jury for the honour they do me by
participating in the examination of this work.

GRADUATION PROJECT iv
Contents

1 Project context and state of art 4

1.1 Hosting company . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1.1 Presentation of the hosting company : FIS . . . . . . . . . . . . . . 5
1.1.2 Company solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1.3 The distribution of the System Testing team . . . . . . . . . . . . . 7
1.2 Presentation of the project . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.1 Analysis of the current situation . . . . . . . . . . . . . . . . . . . 8
1.2.1.1 The FIX protocol . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.1.2 The V5 protocol . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.1.3 Trading Server . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.1.4 P3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.1.5 Selector . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.1.6 SLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.1.7 The ValdiFix plateform . . . . . . . . . . . . . . . . . . . 10
1.2.1.8 The client architecture . . . . . . . . . . . . . . . . . . . . 10
1.2.2 Problematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2.3 Target solution and objectives . . . . . . . . . . . . . . . . . . . . . 12
1.3 Working methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.3.1 Agile approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.3.2 SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.3.3 Project monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

GRADUATION PROJECT v
2 Sprint 0 : Analysis and specification of needs 19
2.1 Requirements Specification . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.1.1 Actors identification . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.1.2 Identification of the requirements . . . . . . . . . . . . . . . . . . 21
2.1.2.1 Functional requirements . . . . . . . . . . . . . . . . . . 21
2.1.2.2 Non functionnal requirements . . . . . . . . . . . . . . . 22
2.2 Global Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2.1 Global usecase diagram . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2.2 Deployment diagram . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.3 Global class diagram . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.3 Product backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.4 Work environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.4.1 Hardware environnement . . . . . . . . . . . . . . . . . . . . . . . 28
2.4.2 Software environnement . . . . . . . . . . . . . . . . . . . . . . . . 28
2.5 Choice of technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.6 Physical architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.7 Logical architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3 Sprint 1: Administration module 38

3.1 Sprint backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.2.1 Detailed usecase diagram of the «Administration Module». . . . 40
3.2.2 Text description of the usecase «Authentication» . . . . . . . . . . 41
3.2.3 Sequence diagram relative to the usecase «Authentication» . . . 41
3.2.4 Activity diagram of the usecase «Authentication» . . . . . . . . . 42
3.2.5 Text description of the usecase «Add an account» . . . . . . . . . 43
3.2.6 Sequence diagram of the use case «Add an account» . . . . . . . 43
3.2.7 Sequence diagram relative to the usecase «Update profile» . . . 44
3.2.8 Design class diagram of the first sprint . . . . . . . . . . . . . . . 45
3.2.9 Package diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.3 Chronicle of Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.3.1 Implementation and realisation . . . . . . . . . . . . . . . . . . . . 46
3.3.1.1 Home page . . . . . . . . . . . . . . . . . . . . . . . . . . 46

GRADUATION PROJECT vi
 3.3.1.2 Authentication . . . . . . . . . . . . . . . . . . . . . . . . 47
3.3.1.3 List of users . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.3.1.4 Adding a user . . . . . . . . . . . . . . . . . . . . . . . . 48
3.3.1.5 Account activation . . . . . . . . . . . . . . . . . . . . . . 49
3.3.1.6 Edit Profile and update password . . . . . . . . . . . . . 49
3.3.2 Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4 Sprint 2 :Files management 52

4.1 Sprint backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.2 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.2.1 Global use case diagram for sprint 2 . . . . . . . . . . . . . . . . . 54
4.2.2 Detailed usecase diagram of «Manage the configuration files» . . 54
4.2.3 Detailed usecase diagram of «Consult the dashboard» . . . . . . 55
4.2.4 Text description of the use case «Upload one or multiple files» . . 56
4.2.5 Text description of the use case «Check the list of non-respected
conditions» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.2.5.1 Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.2.6 Second sprint design class diagram . . . . . . . . . . . . . . . . . 57
4.2.7 Activity diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.3 Chronicle of Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.3.1 Implementation and realisation . . . . . . . . . . . . . . . . . . . . 60
4.3.1.1 List of uploaded files interface . . . . . . . . . . . . . . . 60
4.3.1.2 List of unsatisfied conditions in a file with state «Not
validated» interface . . . . . . . . . . . . . . . . . . . . . 60
4.3.1.3 Comparison of files imported at the same time interface 61
4.3.1.4 Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.4 Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Bibliography 67

GRADUATION PROJECT vii

List of Figures

1.1 Strategic mergers and acquisitions of FIS . . . . . . . . . . . . . . . . . . 6

1.2 Financial services of FIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3 Position of the system testing team in the delivery flow . . . . . . . . . . 7
1.4 Current architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.5 Target architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.6 Agile principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.7 Agile lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.8 Scrum process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.9 Use of the Trello platform . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.1 Global Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.2 Deployment diagram of our application . . . . . . . . . . . . . . . . . . . 24
2.3 Global class diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.4 Spring Framework logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.5 Swagger documentation in HTML format . . . . . . . . . . . . . . . . . . 31
2.6 Angular Framework logo . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.7 Postman Logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.8 Spring Security Logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.9 Logo of the lombok library . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.10 Logo of the Chart.js library . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.11 Physical architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.12 Logical architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.13 JSON Web Token . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

GRADUATION PROJECT viii

 3.1 «Administration Module» usecase diagram . . . . . . . . . . . . . . . . . 40
3.2 Sequence diagram relative to the use case «Authentication» . . . . . . . 42
3.3 Activity diagram of the usecase «Authentication» . . . . . . . . . . . . . 42
3.4 Sequence diagram of the use case «Add an account» . . . . . . . . . . . . 44
3.5 Sequence diagram relative to the use case «Update profile» . . . . . . . 44
3.6 Class diagram of the sprint «Administration Module» . . . . . . . . . . 45
3.7 Package diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.8 Home page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.9 Authentication interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.10 List of users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.11 Adding a user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.12 Account activationn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.13 Update profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.14 Update password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.1 «Files management» usecase diagram . . . . . . . . . . . . . . . . . . . . 54

4.2 «Manage the configuration files» usecase diagram . . . . . . . . . . . . . 55
4.3 «Consult the dashboard» usecase diagram . . . . . . . . . . . . . . . . . . 55
4.4 Class diagram of the sprint «Files Management» . . . . . . . . . . . . . . 58
4.5 Activity diagram «Download a file converted to groovy script» . . . . . 59
4.6 List of uploaded files interface . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.7 List of unsatisfied conditions in a file with state «Not validated» interface 61
4.8 Comparison of files imported at the same time . . . . . . . . . . . . . . . 61
4.9 Fields defined more than once with different values . . . . . . . . . . . . 62
4.10 Dashboard of a team leader . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.11 Dashboard of a team member . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.12 Dashboard of the admin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

GRADUATION PROJECT ix
List of Tables

2.1 Product backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.2 Hardware environnement . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.1 Backlog of the sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.2 Text description of the usecase «Authentication» . . . . . . . . . . . . . . 41
3.3 Text description of the usecase «Add an account» . . . . . . . . . . . . . 43

4.1 Backlog of the sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.2 Text description of the use case «Upload one or multiple files» . . . . . . 56
4.3 Text description of the use case «Check the list of non-respected condi-
tions». . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

GRADUATION PROJECT x
Abreviations

FIS:Fidelity National Information Services

JWT:JWT : JSON Web Token
JSON: JavaScript Object Notation
JPA: Java Persistence API
API : Application Programming
FIX:The Financial Information eXchangeCore

GRADUATION PROJECT 1
General Introduction

Information technology is changing the world around us, now becoming a main factor
of development that affects all sectors of society. Finance is among the areas that ben-
efit from the use of these new technologies. The financial market has modernized by
becoming dematerialized and electronic. It is a network of information technology that
processes transactions between several financial institutions, allowing any individual
to buy shares all over the world and follow the evolution of market prices from his
computer. This is the principle of the electronic trading platforms that are used mainly
to place orders on financial products.

The technological revolution is overturning the companies’s economic model and is

contributing to the evolution of uses on an unprecedented scale. What was the most
recent and with the latest versions yesterday, has become « old school» today. This
is why companies that use the latest technologies are more efficient and generally the
most effective. Technology provides the best services to customers and maintains the
company’s position as a market leader. That is why it is very important to be up to
date with the latest technological trends.

Migration is therefore a process of changing an application from one environment to

another or from one version of databases to another, making the necessary adaptations
so that it continues to function correctly. In order to provide an easier, day-to-day so-
lution based on its functional components,FIS is migrating its backend enironments to
new backend generation.
In this context, we have designed and developed a platform for analysis, management

GRADUATION PROJECT 2
of configuration files and conversion of these files into a Groovy script.

This report is divided into four chapters.

The first chapter outlines the project framework, the host organization and the topic
to be discussed. We integrate the problem, the proposed solution and the working
methodology.

The second chapter deals with the analysis and the specification of the requirements
of our application .It includes the gloabl product backlog,the global analysis, the work
environment ,the choice of the different technologies and the physical and logical ar-
chitecture adapted

The third chapter is devoted the design and implementation of the first sprint called
«Administration module». It contains the several steps and diagrams that lead us to
realise the first part of the project.

The fourth chapter is devoted the conception and implementation of the second
sprint called «Files management». It contains the different screenshots for our applica-
tion as well as the feedback.

We will conclude our report with a general conclusion in which we present our
achievement in brief and introduce some perspectives.

GRADUATION PROJECT 3
Chapter 1
Project context and state of art

Contents
1.1 Hosting company . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.1.1 Presentation of the hosting company : FIS . . . . . . . . . . . . . . . . . . . . . . . 5

1.1.2 Company solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.1.3 The distribution of the System Testing team . . . . . . . . . . . . . . . . . . . . . . 7

1.2 Presentation of the project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.2.1 Analysis of the current situation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.2.1.1 The FIX protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.2.1.2 The V5 protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.2.1.3 Trading Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.2.1.4 P3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.2.1.5 Selector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.2.1.6 SLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.2.1.7 The ValdiFix plateform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.2.1.8 The client architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.2.2 Problematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.2.3 Target solution and objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.3 Working methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.3.1 Agile approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.3.2 SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.3.3 Project monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

GRADUATION PROJECT 4
Introduction

In this first chapter, we will first present the host company and its different solutions.
Then we will introduce the project framework through its problematic, the proposed
solution and we will conclude this chapter with the adopted work methodology.

1.1 Hosting company

In this section we are going to present the hosting company.

1.1.1 Presentation of the hosting company : FIS

Fidelity National Information Services FIS, since 1968 a global provider and producer
of financial solutions. Named the world’s number one financial technology provider in
the annual FinTech 100 ranking, FIS’s commitment to operational excellence and cus-
tomer satisfaction is at the forefront of its business strategies. FIS strives to give every
customer a voice, to listen . By focusing on on innovation, new product development
and improvements, FIS is positioned to help its customers to be more competitive, to
meet their business challenges and objectives. strategic. Information security is one of
the company’s advantages in meeting its customer requirements.
As mentioned in Figure 2.1, FIS was founded in 1968 as Systematics and then acquired
by Fidelity National Financial, which renamed it Fidelity Information Services in 2003.
FIS has continued to acquire several other financial services technology companies,
including Cartesy(2006) , eFunds(2007) and Metavante(2009). In 2015, FIS acquired
SunGard, which opened up new markets for financial technology services. [1]

GRADUATION PROJECT 5
 Figure 1.1: Strategic mergers and acquisitions of FIS

1.1.2 Company solutions

As a world leader in financial services technology, FIS offers a wide range of solutions
for the financial sector.

• Payment solutions: FIS offers a complete set of end-to-end payment solutions. It

proposes a fast and simple payment transaction for retailers and reduces the costs
associated with any process and fraud.

• Banking solutions:FIS is rapidly changing its banking solutions to adapt to the

ever-changing banking environment, linking human needs to banking products
and optimising investments in its existing core banking system, as well as provid-
ing customers with a flexible and easy-to-use banking platform.

• Insurance Solutions:FIS provides support functions as well as policy administra-

tion, risk calculations, and accounting and reporting for a wide range of insurance
lines, as well as health and life, property and casualty, insurance and quality man-
agement.

• Digital/Channel Solutions:FIS enables financial institutions of all sizes to deliver

compelling digital experiences to achieve the highest levels of customer engage-
ment and relevance.

GRADUATION PROJECT 6
 Figure 1.2: Financial services of FIS

1.1.3 The distribution of the System Testing team

This end-of-study project took place within the System Testing team at FIS Tunisia. The
role of the Quality Assurance System Testing team is to deploy the products delivered
by the SCRUM teams in a « production » type environment in order to validate the
company’s solutions for all professional uses . The following figure 2.3 describes the
position of the system test team in the delivery flow:

Figure 1.3: Position of the system testing team in the delivery flow

GRADUATION PROJECT 7
 The main responsibilities of the system testing team are :

• Build and maintain a test environment of the client production environment.

• Perform multi-products functionnal acceptance tests.

• Validate the integration of a new version of the product in clients’ architectures

(all professional uses) based on the client workflow.

• Automate integration tests (manage integration pipelines in a continuous integra-

tion environment).

• Testing for retro-compatibility between the different components.

• Adapt the testing strategy to the target customers.

• Make the binaries available to customers and provide the required new configu-
ration.

• Support client on the go live.

1.2 Presentation of the project

In this section we are going to present our project via the analysis of the current situa-
tion, defining the principle concepts that we needed in our work , detailing the prob-
lematic and exposing the target solution.

1.2.1 Analysis of the current situation

In order to fully understand the project and determine its objectives, the analysis of the
current situation is an essential step. It allows us to adapt to it to avoid any imperfec-
tions in the definition of specifications.
First , we are going to study the existant products.

1.2.1.1 The FIX protocol

The FIX protocol is a standard used by financial institutions, to communicate trades

(and related information) electronically between the exchanges and the counterparts.
It is an open and free protocol, it allows to standardize the electronic communication.
related to trade. A FIX engine is used to generate the outgoing FIX messages and to

GRADUATION PROJECT 8
read incoming FIX messages and is used to connect applications to the outside world.
The FIX protocol versions are V 4.0, V 4.1, V 4.2, V4.3, V4.4 and V5.0.2.[2]

1.2.1.2 The V5 protocol

The Financial Information Exchange Protocol "V5" is a proprietary protocol developed

by SUNGARD, this protocol provides the functions required to transmit messages for
SUNGARD’s platforms.

1.2.1.3 Trading Server

The TS Trading Server is the server application that transmits orders from the following
applications clients to an Exchange.

1.2.1.4 P3

The P3 is an application whose role is to establish communications between "client"

applications and "server" applications.

1.2.1.5 Selector

SunGard global Trading’s module. Order filtering module used to limit risk during
trading.

1.2.1.6 SLC

The Local Collection Server is the server application that receives a stock flow and
distributes it to client workstations.

GRADUATION PROJECT 9
1.2.1.7 The ValdiFix plateform

FIS currently has a trading platform under the name ValdiFix that allows for clients
to establish and manage connections from different FIX counterparties, trading server,
and WHO order management systems. ValdiFix also provides orchestration of FIX
message flows. incoming and outgoing data that are routed to multiple destinations or
from other sources without forgetting to conversion between the standard FIX proto-
col and the various proprietary protocols (V5, CCM, CCM9000 . ) ValdiFix manages a
connection with a Fix client. It creates a FIX IN session to send orders and transforms
the FIX protocol into V5 : proprietary SUNGARD-FIS protocol. The exchange sends
him flows for the reception of instruments.

1.2.1.8 The client architecture

Each of FIS’ clients posess a certain specific archiecture for its solution. For our project,we
are working on the architecture of the client named Kepler which is is a financial com-
pany specializing in research, execution, advisory and asset management services. The
figure below represents the overview current architecture :

Figure 1.4: Current architecture

GRADUATION PROJECT 10
 FIS always tends to :

• Offer its customers the best solutions in terms of performance and safety.

• Improve latency as much as possible.

• Provide an easier, day-to-day solution based on its functional components.

For that reason ,FIS is migrating its backend environments to a new backend genera-
tion called «The ValdiSwitch» which will simplify the previous architecture by creating
a single brick which will be the basis of FIS’s trading architecture.

The main purpose of this migration is :

• Improve our Total Cost of Ownership [TCO] on its legacy suite.

• Simplify architecture.

• Simplify configuration.

• Simplify delivery and upgrade process.

Please note : The total cost of ownership (TCO) is the purchase price of an asset
plus the costs of operation.[3]

The figure below represents the target architecture :

Figure 1.5: Target architecture

GRADUATION PROJECT 11
 The Valdi Switch will completely replace the current suite of separate products: P3
- P10 - SELECTOR - GLTS - RELAY - VALDIFIX BROKER.
This new environment is java-encoded and requires very specific input configuration
files coded in «Groovy» script. We have noticed that the configuration files which are
the input of the «Validswitch» can contain logical errors and incomplete acceptance
conditions.
The person in charge of controlling these files can easily commit errors during the man-
ual validation due to the enormous size of the files and the amount of information and
therefore the file manually converted to groovy will contain errors which will cause
problems when launching the backend application.

1.2.2 Problematic

Research into existing problems allows us to carry out a complete diagnosis of the
problems that the test and development team encounters during the configuration pro-
cess of the new backend:

• Loss of information

• The processing time

• Manual conversion of configuration files into groovy scripts

• The syntactic and logical errors that some input files may contain

1.2.3 Target solution and objectives

The context of our project consists in developing an application for analysing , man-
aging configuration files in an efficient way and providing a detailed report of the list
of possible errors. Our application will be integrated into the product « valdiswitch »
and it will be composed of two modules :

• The first module is to read , analyse the configuration files and insert the list of
problems found in a MySQL database.

• The second module is used to convert valid files to groovy script and generates a
downloadable file with « .groovy » as extension.

GRADUATION PROJECT 12
 As a whole, our web application is an interface that allows team members to con-
nect securely, import configuration files to the platform , receive a detailed report on
the types of errors using custom search and filtering algorithms according to various
criterias and also receive the report that comes from the comparison of several files
imported at the same time. The main functionalities that our platform must ensure
are:

• An elegant and dynamic web architecture.

• Implemented algorithms to compare and filter the different configuration files as

required and identify possible errors.

• Clear statistics providing information on the number of valid and invalid files,
types of possible errors, the number of files converted to groovy during a defined
period of time ...

1.3 Working methodology

The size and nature of the project are the basis for the choice of working methodology.
For a project where there are no requirements defined at the outset, iterative or proto-
typing methods will provide adequate solutions. One of these methods is the AGILE
method, which is widely used throughout the world.
By taking into account the changing needs of customers, the AGILE method can pro-
duce high quality products. This method can ensure good communication with cus-
tomers, provide visibility of product progress and find problems as quickly as possible.
After an in-depth study of several methods, we have to determine the most appropri-
ate method, namely the AGILE type, in particular the SCRUM type.

GRADUATION PROJECT 13
1.3.1 Agile approach

Agile methodology is an iterative incremental method, which has powerful features to

adapt to changes and unexpected events. The main objective of Agile is to deliver a
valid version of the product to the customer as quickly as possible.

• Agile principles : The Agile manifesto embodies 12 important principles:

Figure 1.6: Agile principles

GRADUATION PROJECT 14
 • Develeopment process Agile follows the development of continuous ver-
sions called incremental, which add and modify the necessary functions over time
to provide a more powerful product. The planning, coding, testing, and comple-
tion of each subsequent module requires a short meeting of two to four weeks, as
shown in the figure below.

Figure 1.7: Agile lifecycle

1.3.2 SCRUM

The Scrum method is the most widely used, proven and documented agile method-
ology. It is considered a simple framework for managing complex projects based on
transparency, adaptability and inspection. It is based on the process of breaking down
the project into several iterations called sprints. These represent "user stories" that will
be executed within a fixed timeframe of 1 to 4 weeks. 3 main roles are involved in the
SCRUM method:

• The product owner : He is a business expert who can define functional

specifications. He determines the priority of the functions to be developed or
corrected and verifies the developed functions. Basically, he plays the role of the
customer. As far as we are concerned, Mrs Nehed Ben Slimene is our product
manager.

• The scrum master : The Scrum master must ensure that the Scrum values
and principles are upheld. Its function is to foster communication between team
members and increase their productivity. In our case, Ms. Safa Mehrez is our
Scrum Master.

GRADUATION PROJECT 15
 • The development team : The team has no defined roles: architect, program-
mer, tester, etc. All team members contribute their knowledge to accomplish the
tasks. In theory, a team usually consists of 6 to 10 people and no more than 200
people at the most, but in our case, the team consists of only 2 people: Ms. Hamida
Jarraya, my technical supervisor and myself.

In order to better iterate, we have organised the following meetings for each itera-
tion:

• Sprint planning
The « sprint plan » is realized at the beginning of each sprint, Monday at 2 pm.
During this meeting, the use cases proposed by the « product owner » are broken
down into technical tasks.

• The sprint review

At the end of each sprint, for the sprint review, all the collaborators meet every
fortnight, on Friday at 5 pm. During this meeting we discuss the progress of the
project, evaluate the finite and unfinished elements and make an "update" of the
product backlog.

• The sprint retrospective The retrospective meeting takes place half an hour
after the sprint review to evaluate the elapsed time. Everyone mentions the posi-
tive and negative points that were discussed during the sprint.

The diagram below summarises the scrum process applied by our team.

GRADUATION PROJECT 16
 Figure 1.8: Scrum process

• Daily scrum
It is a synchronisation meeting of the development team : « stand up meeting »
which is done in a maximum of a quarter of an hour during in which everyone
answers questions: « What have I finished since the last melee? What will I have
finished by the next scrum? What obstacles are holding me back? »

GRADUATION PROJECT 17
 Scrum offers advantages that motivate us to use it:

• Provides greater responsiveness to adapt to changing customer needs.

• Increases liquidity and speed of delivery.

• Eliminates a lot of paperwork regarding documentation and control.

• It stimulates a sense of direction, rigour and vitality in the team.

1.3.3 Project monitoring

We use the Trello tool ( a project management platform) to monitor the progress of the
project on a daily basis. As shown in Figure 1.9, we have marked the tasks that have
been completed, the tasks to be completed and the tasks to be completed.

Figure 1.9: Use of the Trello platform

Conclusion

In this chapter we have published an overall perspective of the project. First of all,
we presented the host organisation. Then we mentioned the problematic and studied
the existing solutions. Finally, we analysed the working method to be used. In the
next chapter, we will illustrate the preparation phase of the project through a set of
specifications describing the needs of our project.

GRADUATION PROJECT 18
Chapter 2
Sprint 0 : Analysis and specification of
needs

Contents
2.1 Requirements Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.1.1 Actors identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.1.2 Identification of the requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.1.2.1 Functional requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.1.2.2 Non functionnal requirements . . . . . . . . . . . . . . . . . . . . . . . . 22

2.2 Global Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.2.1 Global usecase diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.2.2 Deployment diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.2.3 Global class diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.3 Product backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.4 Work environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.4.1 Hardware environnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.4.2 Software environnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.5 Choice of technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.6 Physical architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.7 Logical architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

GRADUATION PROJECT 19
Introduction

In this chapter, we will start by defining our product backlog which contains the list
of user stories with their priorities, then we will move on to identify the actors in our
system and the functional and non-functional requirements, and finally we will present
the use case diagrams.

2.1 Requirements Specification

The study of requirements is an essential preparatory stage, whose objective is to study

the basic elements that will lead to the realisation of the project. In order to do so, our
team spent the time necessary to identify and write the specifications for our project.

2.1.1 Actors identification

Actors are the users capable of accessing and interacting with the application’s data
and services, each with specific roles and privileges. [4]
For our solution, we have distinguished three actors who interact with our system:

• Team Leader :
It is a user of the application, who creates the accounts of the team members, can
consult the list of files imported by each member and check the statistics about the
validity of the imported files.

• Team Member:
With the possibility of importing configuration files, downloading them, checking
the error list and correcting it, reviewing whether the file is valid or not, receiv-
ing the comparison report between several files, downloading the file converted
to groovy and visualizing statistics about the status of the files that have been
uploaded.

• Manager

Playing the role of an Administrator, it is any person who creates the accounts
of other users, can activate and deactivate the accounts and receives the weekly
report on the status of the files that are imported by each team.

GRADUATION PROJECT 20
 Of course, any user of the application has the possibility to change his password
and contact information.

2.1.2 Identification of the requirements

In this section we will identify the different functionnal and non functionnal require-
ments of our application.

2.1.2.1 Functional requirements

Our application provides services via the web interface: it must allow access to its
services in a reliable and secure manner so that users can carry out various operations
within the limits of their rights.
In this section, we will detail the requirements for each actor:

• Authentication
The application requires users to be authenticated to access the application and
participate in various platform activities.

• Management of users
The admin can create, view details, search, activate or deactivate a user’s account
(which can be a team leader, a team member, etc.).

• Consult the dashboard

Each user can consult a set of statistics depending on his role.

• View list of imported files

A team leader can consult the platform, view the list of imported files (sorted by
import date) and the person who imported these files.

• Team member board :

As soon as they are connected, team members can consult and manage their per-
sonal space: they can consult or edit their personal information, their email ad-
dress (provided it is not already in use), or their password (for security reasons
the password will be encrypted). He can also import, download or delete con-
figuration files, check whether the files’ status is valid or not, check the error list,
convert and download a valid configuration file into « Groovy» script.

GRADUATION PROJECT 21
 • Search engine
The system should allow users to search for files by different attributes such as
date, name, status..

2.1.2.2 Non functionnal requirements

It is the requirements that specifies criterias used to evaluate the functioning of a sys-
tem, not specific behaviours.[5]
The non-functional requirements of our application are :

• Extensibility

The architecture of our application must be clear for future developments or

improvements.

• Security Security is an essential criteria in a FIS portal. The FIS slogan is «

Think secure , be secure». So security has to be applied in several aspects includ-
ing authentication and data confidentiality.
In order to respond to this requirement, it is mandatory to use a central authen-
tication system allowing the management of password policy and account status,
use encoding rules (plain text, MD5) and ensure that only authorized parts have
access to data and resources via spring security, which is a powerful and highly
customizable authentication and access control framework. It is the de facto stan-
dard for securing Spring applications.[6] And therefore it will allow the manage-
ment of access to the resources of our project.

• Ergonomics
Our application must be user-friendly, ergonomic and easy to use.

2.2 Global Analysis

After having determined the different actors interacting with our system and the func-
tional and non-functional requirements, we present these different functions through
the diagrams of the unified modelling language UML.
This language is used to specify, display, edit, and create the documentation necessary
to successfully develop object-oriented software.[7]

GRADUATION PROJECT 22
2.2.1 Global usecase diagram

The main use of use case diagrams is structuring and representation. Conceptually, the
user needs and the objectives corresponding to the system. The objective is to highlight
the actors in the domain and their interactions with the system interface. This diagram
provides information on the behaviour and functionality that a user can perform with
the system. On the other hand, it allows to perceive the way the system manages these
functionalities and in particular the communications between sub-systems.
Use case
Represents a series of action sequences that the system performs and which produce
an interesting result for a particular actor. Use cases are used to express the system’s
behaviour in terms of actions and reactions.
Below in the figure 2.1 is shown the global use case of our application :

Figure 2.1: Global Use Case Diagram

The users of our application are divided into three types : The manager , the team

GRADUATION PROJECT 23
leader and the team member : The role of the manager and the team leader is basically
the management of the users and the edit of the profiles and consulting the statistics
while the main role of the team members is basically the manage of the configuration
files, of course apart from updating his profile and checking the statistics. Any user
will need to authentificate himself while accessing the application.

2.2.2 Deployment diagram

Figure 2.2 shows the physical layout of the hardware that makes up the system, as well
as the distribution of components and the relationships between them. The hardware
resources are represented in the form of nodes.
Below is shown the deployment diagram corresponding to our application :

Figure 2.2: Deployment diagram of our application

The modelling of this deployment diagram reveals three Nodes:

• User workstation :Includes a browser that presents the thin client of our applica-
tion, and connects to the web server by sending HTTP requests.

• Nodejs : Used as a web server platform.

• A Tomcat servlet container :Provided by the Framework Spring boot. The dif-
ferent layers, namely the presentation layer, the business logic layer and the data
access layer running in the Spring lightweight container.

• MySql : Database server.

GRADUATION PROJECT 24
2.2.3 Global class diagram

This diagram provides an abstract presentation of the system objects that will interact
together to realize the different use cases. It is the basis for object-oriented analysis.
It shows the classes, their interactions, as well as the operations and attributes of the
classes .
Figure 2.3 presents the global class diagram of our application.

Figure 2.3: Global class diagram

GRADUATION PROJECT 25
 • Users:The User class contains the necessary data that allows the user to authenti-
cate himself.

• Role:This interface presents the different roles of the users of our application.

• AttributeV5:This class provides informations about the FIS’ protocol : V5.

• ConfFile:Contains necessary infomations about the input configuration file.

• Protocol:This enumeration contains the type of protocol used in the files imported.

• FilesUploadedSameTime:This class provides informations about the files being

important at the same time.

• ErrorTypeDescription:Provides the logical errors detected within one or more im-

ported files.

• CompareFile:Contains informations about files being imported at the same time.

• ErrorsEnrichedTags:Contains informations about the logical errors resulting of

the comparison two or more compared files.

• IdSession:This class contains the informations about a session.

• Conditions:This class covers the conditions and the rules that must be verified
within every configuration file imported.

2.3 Product backlog

The product backlog is designed to collect all the customer needs that the project team
has to fulfil. It therefore contains a list of the functions involved in the composition of
the product, as well as all the elements that require the intervention of the project team.
All the elements contained in the product backlog are prioritised to indicate their order
of completion.
Table 2.1 shows the product backlog of our system.

GRADUATION PROJECT 26
 Table 2.1: Product backlog

ID Titles User stories Priority

As a user, I can change my password. 2
As a user, I can change my e-mail address. 2
As a user, I can change my first and last name. 2
As a manager, I can activate/deactivate the accounts of
2
the team leaders.
1 User management
As team leader, I can activate/desactivate
2
the accounts of the members of my team.
As a manager, I can consult the list of team leaders. 2
As a team leader, I can consult the list of
2
the members of my team.
As team leader, I can examine all the files
1
imported by my team.
As a team leader, I can find out who has imported
1
such a file and when exactly.
As a team member, I can check the status
1
of any file (not valid, valid or not yet processed).
2 Files management As a team member, I can import one or more
files at the same time as long as they follow a 1
precise nomenclature.
As a team member, I can check the status
of a file that has not yet been processed 1
using the « Check» button.
As a team member, I can consult
1
the list of logical errors for the invalid files.
As a team member, I can download any
1
file.
As a team member, I can download a file
with « Validated» status that has been converted 1
to a «Groovy» script.

GRADUATION PROJECT 27
 As a manager, I can search for
5
team leaders by last name, first name and login.
3 Search management As a team member, I can filter imported
files according to import date, file name, 5
status, etc.
As a user of the application, I want to
4 Authentication 4
authenticate myself.
As a user of the application, I want to consult
5 Dashboard 3
my dashboard.

2.4 Work environment

In this section we will be referring to a set of software and hardware tools that are used
to successfully implement our solution.

2.4.1 Hardware environnement

Table 2.2: Hardware environnement

Computer ASUS Light Gaming X550VX-XX057D
Processor Intel Core i5
Memory 16 GB de RAM
Hard Disk Drive 1 To
Operating system Windows 10

2.4.2 Software environnement

After having mentioned in detail the material means used, we will move on to describe
in detail the software that was used to carry out the project and prepare the report.

• WebStorm:It is a web language IDE developed by JetBrains and based on the

IntelliJ IDEA platform.[8]

• Spring Tool Suite(STS) It is an extended IDE of Eclipse which consists of an In-

tegrated Development Environment (IDE) used to implement applications and

GRADUATION PROJECT 28
 supports several development languages . It specializes in Spring applications.[9]

• Overleaf Overleaf is an editor that allows you to create LATEX documents online
free of charge, collaboratively and in real time.[10]

• Online Visual Pradigm Online visual pradigm is an online diagramming tool

which allows users to innovate their idea or concepts anytime online in the cloud
using formal specification languages.[11]

2.5 Choice of technologies

In the continuation, we will detail the technologies used in the implementation of our
application.

• Spring It is a foundation for application development. it is one of the most widely

used frameworks in the world. it is open source and provides many functionali-
ties. It is also a lightweight container that simplifies the integration of the different
layers. In addition, Spring can be fully portable to any application server and can
be fully integrated with all the technologies chosen in the development of the
project.[12]
Figure below presents the logo of Spring:

Figure 2.4: Spring Framework logo

• Spring Boot It is a project built on top of the Spring framework.

It allows to simplify the development of Java applications. Spring Boot is based on
important concepts that we have used during the implementation of the backend
of our application :
*Auto-Configuration

GRADUATION PROJECT 29
 *Application Standalone
*No XML generation
*Tomcat/Jetty server in embedded mode[13]

• Spring Data It is a Spring Framework whose main role is to lead the mapping of
the different persistent entities of the application. The advantage of using Spring
Data is that it completely removes implementations from the DAO layer and sub-
stitutes them with predefined interfaces that are called : « les Repositories. » [14]

• JPA It is a standard for the manipulation of relational databases according to the

object-oriented paradigm. It proposes a higher level of abstraction than the use
of JDBC. It also ensures the persistence of objects in the database and vice versa,
whether for readings or updates. [15]

• Maven We used Maven as a tool for the production, management and automation
of Java software projects and as a construction tool for our project.[16]

• Swagger It is an open source project that grants the possibility to graphically re-
verse engineer the documentation of an API specified with the OpenAPI specifica-
tion. Swagger’s Human Machine Interface (UI) allows displaying and interacting
with the API resources without using any implementation logic, which facilitates
back-end implementation and client-side consumption.[17].
The figure below shows the Swagger documentation of our project in HTML for-
mat:

GRADUATION PROJECT 30
 Figure 2.5: Swagger documentation in HTML format

• Angular 8 Angular, which was developed by Google, is an open source frame-

work written in JavaScript that enables the creation of web applications, in par-
ticular SPAs "single page application": web applications that can be accessed via
a single web page, which simplifies the workflow for users and avoids the ne-
cessity of any further operation that would require the page to load. The frame-
work is based on a MVC-type architecture, so the data, visual effects and actions
can be separated to better manage the responsibilities. A largely proven archi-
tecture can achieve high maintainability and an improved collaborative working
environment.[18]
Figure below presents the logo of Angular:

GRADUATION PROJECT 31
 Figure 2.6: Angular Framework logo

• Postman It is a REST client offered by Google with the main purpose of testing
APIs and is either available as a chrome extension or as a standalone application,
and it is the most widely used for testing microservices thanks to its simplicity
and special features.[19]
Figure below presents the logo of Postman:

Figure 2.7: Postman Logo

• Spring Security It is a framework for managing identity verification and data

access control. The interest of using Spring Security is to control access to the
different paths that have the right to manage persistent data.[20]
Figure below presents the logo of Spring Security:

Figure 2.8: Spring Security Logo

• Lombok It is an API whose main objective is to generate Java code for us during
compilation. Everything is done with simple annotations to be included in our
classes.[21]

GRADUATION PROJECT 32
 Figure below presents the logo of Lombok Library:

Figure 2.9: Logo of the lombok library

• Chart.js It is an open source JavaScript library that can easily include animations
and reactive graphics in our platform. In order to use chartJs in Angular, we use
the ng2-charts package.
Figure below presents the logo of the Chart.js library:

Figure 2.10: Logo of the Chart.js library

2.6 Physical architecture

In order to develop our application, we implemented the architecture illustrated in the

following figure:

GRADUATION PROJECT 33
 Figure 2.11: Physical architecture

The architecture contains the following servers :

• The "Apache" web server: This is the server responsible for interpreting HTTP
requests received on port 4200.

• Apache Tomcat:It is an integrated servelet container under the Spring Boot Frame-
work that provides a context for executing Java code and tools for packaging the
application in a jar file.

• MySql:Database server.

2.7 Logical architecture

Logical architecture involves the logical separation of applications and the way in
which the components are grouped according to their functional types and the treat-
ments carried out. For our application solution, we chose the multi-layer architecture
shown in the figure below.

GRADUATION PROJECT 34
 Figure 2.12: Logical architecture

• Presentation layer This is the highest level layer, responsible for data visualization
and the graphical aspect of the application and is therefore the basis of the human-
machine interface. It replies to customer requests by using the application layer.

• Web layer The basic function of the web layer is to coordinate the sequence of
actions/reactions of web applications. They receive requests and trigger logic
based on business objects.

• Business layer The business layer includes the business processing of the appli-
cation, i.e. the services of the different functional modules, the communication
services with the database. Its main role is to abstract the application logic from
the technical code (presentation, persistence), and to offer application and busi-
ness services to the presentation layer.

• Persistance layer The persistence layer has the role of data recovery and persis-
tence. It provides the link between the database management system (DBMS) and
the business layer. It adds a level of abstraction between the data sources and their
use, guarantees a weak coupling between the business layer and the database and

GRADUATION PROJECT 35
 therefore simplifies the code of the business layer, which only has to use the per-
sistence layer.

• Security layer The security layer is used to ensure that the user performing the
operation has the necessary privileges. Security is provided by Spring Security,
which is a JavaEE framework that provides authorization, authentication, and
other security functions for business applications. Among the various Spring Se-
curity functions used with, the « Bcrypt » hash function for hashing passwords
provided by the jar
org.springframework.security.crypto.bcryptpasswordencoder As a result, the JSON
WEB TOKEN (jwt) standard has been applied with Spring Security, which allows
tokens to be securely exchanged between multiple parties. Thus, the information
exchanged is reliable and verified as it is digitally signed. using the HMAC algo-
rithm. [22]

The figure below shows a JSON web token retrieved and exchanged between the server
and the client.

Figure 2.13: JSON Web Token

GRADUATION PROJECT 36
Conclusion

In this chapter, we have presented the needs analysis of the application. We started
with the requirements specifications, then conducted the initial conceptual analysis
and presented the global version of the product backlog. We also presented the work-
ing environment and the logical and physuical architecture of our application. In the
next chapter, we will deal with the project’s first sprint : Administration module.

GRADUATION PROJECT 37
Chapter 3
Sprint 1: Administration module

Contents
3.1 Sprint backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.2 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.2.1 Detailed usecase diagram of the «Administration Module». . . . . . . . . . . . . . 40

3.2.2 Text description of the usecase «Authentication» . . . . . . . . . . . . . . . . . . . 41

3.2.3 Sequence diagram relative to the usecase «Authentication» . . . . . . . . . . . . . 41

3.2.4 Activity diagram of the usecase «Authentication» . . . . . . . . . . . . . . . . . . . 42

3.2.5 Text description of the usecase «Add an account» . . . . . . . . . . . . . . . . . . . 43

3.2.6 Sequence diagram of the use case «Add an account» . . . . . . . . . . . . . . . . . 43

3.2.7 Sequence diagram relative to the usecase «Update profile» . . . . . . . . . . . . . 44

3.2.8 Design class diagram of the first sprint . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.2.9 Package diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.3 Chronicle of Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.3.1 Implementation and realisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.3.1.1 Home page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.3.1.2 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.3.1.3 List of users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3.3.1.4 Adding a user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3.3.1.5 Account activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.3.1.6 Edit Profile and update password . . . . . . . . . . . . . . . . . . . . . . . 49

3.3.2 Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

GRADUATION PROJECT 38
Inroduction

Now that we have determined the actors and the different functionalities that our ap-
plication must provide,We dedicate this sprint to the authentication and the manag-
ment of the accounts of the users.At the end of this chapter the user will be able to
authenticate himself to the application ,he will be directed to his space according to
his privileges.Then he will have the access to update his account informations and his
password.Finally the manager and the team leaders will have the authorization for
adding and activating/deactivating the accounts.

3.1 Sprint backlog

We will introduce in the accompanying table the build-up of the principal sprint mir-
roring the various functionalities of our application finished during this sprint. In the
table 3.1 is presented the backlog of the sprint 1:

Table 3.1: Backlog of the sprint 1

ID User stories Estimation
1 As a user of the application , i want to sign in. 8
As a manager , i want to manage the accounts of the team
2 8
leaders.
As a team leader i want to dispaly the list of my team
3 8
members
As a manager , i want to add the accounts of the team
4 10
leaders
As a manager , i want to activate the accounts of the team
5 2
leaders
As a manager , i want to deactivate the accounts of the
6 2
team leaders
As a teamleader , i want to add the accounts of the team
7 10
members
As a teamleader , i want to activate the accounts of the
8 2
team members

GRADUATION PROJECT 39
 As a user of the application, i want to display my per-
9 3
sonal informations
As a user of the application, i want to update my personal
10 3
informations

3.2 Design

This section is consacred to show the different UML diagrams that we used in oder to
understand more the functionnalities of our application.

3.2.1 Detailed usecase diagram of the «Administration Module».

The manager is able to manage the accounts of the teamleaders:He can add,activate/deactivate
an account, display the list of managers,he can also update his profile and change his
password .Whereas the team leader has all the privileges as the manages but with his
team members. The figure 3.1 represents the use case diagram of the «Administration
Module».

Figure 3.1: «Administration Module» usecase diagram

GRADUATION PROJECT 40
3.2.2 Text description of the usecase «Authentication»

Table 3.2: Text description of the usecase «Authentication»

In order to access the main menu of applica-
Goal
tion,authentication is required.
Actor User with multiple roles according to privileges.
Precondition The user has his or her own access codes.
Postcondition Authentication validated and access granted.
-The system displays a login interface.
-The user enters his access parameters.
-The system checks the validity of the credentials pro-
Main scenario
vided.
-The system redirects the user to the main menu of the
application.
If the data provided is incorrect the system displays an
Exceptions
error message

3.2.3 Sequence diagram relative to the usecase «Authentication»

To access the application, the user must go through the authentication step where he or
she is required to enter his or her correct user name and password. By validating them,
the system verifies the identity of the person. This whole scenario is presented by the
diagram shown above. There is no constraint on the number of connection attempts.

GRADUATION PROJECT 41
 Figure 3.2: Sequence diagram relative to the use case «Authentication»

3.2.4 Activity diagram of the usecase «Authentication»

The figure below shows the activity diagram of the usecase «Authentication»:

Figure 3.3: Activity diagram of the usecase «Authentication»

GRADUATION PROJECT 42
3.2.5 Text description of the usecase «Add an account»

Table 3.3: Text description of the usecase «Add an account»

Goal Add a user’s account
Actor User with multiple roles according to privileges.
-The user is authenticated by his login and password to
Precondition
the application server.
The user is added successfully and an email containing
Postcondition
the users password is sent to the user.
-The system displays a form to be filled in with the re-
quired informations of a team leader or team member re-
garding the privilege of the user connected.
-The manager fills in the appropriate fields of the form.
-The user validates the form by clicking on the « Add a
Main scenario team leader/team member » button.
-The system saves the information about the team leader
/team member in the database and sends an e-mail with
a random password to the team leader/team members’s
inbox so that he or she can use it to log in the application
for the first time.
If an empty or redundant response is entered, it will not
Exceptions
be saved and an alert will be displayed.

3.2.6 Sequence diagram of the use case «Add an account»

In this figure below is listed the sequence diagram of the use case «Add an account»

GRADUATION PROJECT 43
 Figure 3.4: Sequence diagram of the use case «Add an account»

3.2.7 Sequence diagram relative to the usecase «Update profile»

Figure 3.5: Sequence diagram relative to the use case «Update profile»

GRADUATION PROJECT 44
3.2.8 Design class diagram of the first sprint

Figure 3.2 illustrates the design class diagram or this sprint:

Figure 3.6: Class diagram of the sprint «Administration Module»

3.2.9 Package diagram

The figure 3.1 illustrates the package diagram corresponding to our application :

Figure 3.7: Package diagram

Given the number of classes adopted in our project, it is important to resolve this
complexity by grouping the classes into a set of packages with the intention of both
understanding the role of each party and promoting the maintainability of the code.

GRADUATION PROJECT 45
The following is a breakdown of the packages, each of which has a specific role:

• The package tn.esprit.pfe.backend.entities: Contains the classes allowing access

to the data of our application.

• The package tn.esprit.pfe.backend.repositories :Contains the interfaces to help

make the data access layer (UPDATE, SELECT queries) faster.

• The package tn.esprit.pfe.backend.services: Contains the classes and service in-

terfaces of our application.

• The package tn.esprit.pfe.backend.rest: Contains the classes of the REST services

of our application.

• The package tn.esprit.pfe.backend.config: Contains the configuration of the Swag-

ger API and the design and implementation classes of Spring Security and JWT.

• The package tn.esprit.pfe.backend.dto : Contains the classes which are simple

lightweight data containers used to move data between layers.

3.3 Chronicle of Sprint

3.3.1 Implementation and realisation

In order to present the functionality of our application, in this section we show the
human-machine interfaces that we have implemented. Our application is available in
the following two git links:
Back-End
https://nesrinemaiez@bitbucket.org/fis-nesrine/backend-repository.
git
Front-End
https://nesrinemaiez@bitbucket.org/nesrinemaiez/frontendlatestversion.
git

3.3.1.1 Home page

The figure below represents the home page of our application. This page contains a
link to the authentication page and a small description of the main purpose of our

GRADUATION PROJECT 46
application.

Figure 3.8: Home page

3.3.1.2 Authentication

Figure below shows the authentication interface . Through this interface, the user can
acquiesce to the different services offered by the application according to its role in the
company. The manager enters his login «Enumber» and password so that he is directed
to his space according to the specified access rights. For security reasons, the password
must be at least six different characters long and the user must enter an «Enumber» and
a password to access his well defined space according to the privileges granted to him.

Figure 3.9: Authentication interface

GRADUATION PROJECT 47
3.3.1.3 List of users

Figure below shows the list of users . The manager can add, activate/deactivate the
accounts of the team leaders and the team leaders can add, activate/deactivate the
members of their teams.

Figure 3.10: List of users

3.3.1.4 Adding a user

The manager can add team leader accounts and team leaders can add their team mem-
bers.

Figure 3.11: Adding a user

GRADUATION PROJECT 48
3.3.1.5 Account activation

When a user is added for the first time, he receives an email that confirms the creation
of his account and gives him his automatically generated password so that he can
log in. He will have the possibility to change his password and contact information
afterwards.

Figure 3.12: Account activationn

3.3.1.6 Edit Profile and update password

The figure below shows the interface from which the collaborator can consult and mod-
ify his personal information: The identifier is unique so he can just consult it but he can
change his email and full name as long as the email is not already registered.

GRADUATION PROJECT 49
 Figure 3.13: Update profile

Update password This interface is where the user can change his password.

Figure 3.14: Update password

3.3.2 Feedback

Feedback is very important so that we can move forward and create a complete appli-
cation that meets the customer’s needs with very high performance and good quality
on the interface consistency side. For this chapter, the feedback contains much more

GRADUATION PROJECT 50
positive than negative points. The scrum master was impressed by the quality of the
work and asked to change only the graphic charter so that our application would be
simpler and more organised.

Conclusion

In this chapter, we went through the product backlog for this sprint at that point we
portrayed the highlights accomplished whereas outlining them with graphs then we
concluded with displaying the interfacing of these highlights within the realization
part.

GRADUATION PROJECT 51
Chapter 4
Sprint 2 :Files management

Contents
4.1 Sprint backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.2 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.2.1 Global use case diagram for sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.2.2 Detailed usecase diagram of «Manage the configuration files» . . . . . . . . . . . . 54

4.2.3 Detailed usecase diagram of «Consult the dashboard» . . . . . . . . . . . . . . . . 55

4.2.4 Text description of the use case «Upload one or multiple files» . . . . . . . . . . . 56

4.2.5 Text description of the use case «Check the list of non-respected conditions» . . . . 56

4.2.5.1 Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.2.6 Second sprint design class diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.2.7 Activity diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.3 Chronicle of Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4.3.1 Implementation and realisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4.3.1.1 List of uploaded files interface . . . . . . . . . . . . . . . . . . . . . . . . 60

4.3.1.2 List of unsatisfied conditions in a file with state «Not validated» interface 60

4.3.1.3 Comparison of files imported at the same time interface . . . . . . . . . . 61

4.3.1.4 Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

4.4 Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

GRADUATION PROJECT 52
Introduction

We move on to the third sprint. This sprint is dedicated to the management of files.In
this chapter, we specify this sprint using use case diagrams. Then, we model its de-
sign using class diagrams and system sequence diagrams. We end this chapter with a
presentation of some of the interfaces developed.

4.1 Sprint backlog

We will introduce in the accompanying table the build-up of the principal sprint mir-
roring the various functionalities of our application finished during this sprint. In the
table 4.1 is presented the backlog of the sprint 2:

Table 4.1: Backlog of the sprint 2

ID User stories Estimation
1 As a team member, i want to upload one or multiple files 5
As team member, i want to check the status of this file
2 4
(not valid, valid or not yet processed).
As team member, i want consult all the files that i up-
3 6
loaded
4 As a team member, i want to search for a file 2
As a team member, i want to check the status of a file that
5 2
has been imported
As a team member, i want to consult the list of the data
6 15
that i need to correct in the file imported so it can be valid
7 As a team member,i want to download a file. 5
As a team member,i want to download a converted valid
8 15
file in a groovy file script
As a team leader, i want to check the number and the
9 5
state of files imported by all my team members
As a manager, i want to check the number of managers
10 5
and their team members.
As a manager, i want to check the number and state of
11 5
files treated during a work day .
As a team member, i want to check the number and the
12 5
state of files imported by me.

GRADUATION PROJECT 53
4.2 Design

In this section we will present the different UML diagrams that we managed to extract
in order to understand the application’s functionnalities.

4.2.1 Global use case diagram for sprint 2

The figure below represents global use case diagram for sprint 2

Figure 4.1: «Files management» usecase diagram

4.2.2 Detailed usecase diagram of «Manage the configuration files» .

The figure below represents the use case diagram of the «Manage the configuration
files».

GRADUATION PROJECT 54
 Figure 4.2: «Manage the configuration files» usecase diagram

4.2.3 Detailed usecase diagram of «Consult the dashboard»

The figure below represents the use case diagram of the «Consult the dashboard».

Figure 4.3: «Consult the dashboard» usecase diagram

GRADUATION PROJECT 55
4.2.4 Text description of the use case «Upload one or multiple files»

The team member’s main duty is to manage the configuration files : he’s able to upload
one or many files , download a file , view the list of the eventual errors ,check a file’s
status, download a file converted to a groovy script and view details of the logical
errors contained in uploaded files at the same time. -The files which are imported
posses a well structured configuration based on a set of rules and filters which call
each other based on a specific logic.

Table 4.2: Text description of the use case «Upload one or multiple files»
Goal Upload one or multiple configuration files
Actor A team member
Precondition The member is authenticated by his login and password.
Postcondition The upload of the files is successfully completed
-The system displays the field or import the files
-The team member can select one or more files from a
local directory.
Main scenario
-The team member validates his choice by clicking on the
«Upload» button.
-The process is initiated
In case of non-compliance with the nomenclature or size,
Exceptions an alert will be issued and the import will not be carried
out.

4.2.5 Text description of the use case «Check the list of non-respected conditions»

4.2.5.1 Conditions

There are a list of conditions to check in a file uploaded in order to be in a «Valid»

status.If any of these conditions isn’t satisfied , the file’s status will be «Not valid» and
the team member can check the list of the non-respected conditions in order to correct
them :

• The [General] section must exist.

• The [Last Rule] section must exist.

• We can’t have configured but disabled rules.

GRADUATION PROJECT 56
 • Two rules cannot call the same filter.

• We can’t have a filter which is configured but not used.

• We can’t have a rule which calls an inexistant filter.

Table 4.3: Text description of the use case «Check the list of non-respected conditions».
Goal View the list of eventual errors
Actor A team member
-The member is authenticated by his login and password.
Precondition
-There is at least one uploaded file.
Postcondition A list of eventual errors is generated
-The system displays the list of files imported by the team
member.
-The team member tests the validity of a file by clicking
Principal Scenario
on the « Check» button.
-The process changes the check status of the file and gen-
erates the error list in case the file is invalid.
If the file is valid, the list will not be displayed.
Exceptions Instead the button of the convertion to a groovy script
will be shown.

4.2.6 Second sprint design class diagram

Figure 4.2 illustrates the design class diagram of the second sprint:

GRADUATION PROJECT 57
 Figure 4.4: Class diagram of the sprint «Files Management»

4.2.7 Activity diagram

This diagram allows us to describe the business process of the «Download a file con-
verted to groovy script» use case.This case is very important since the groovy file gen-
erated is the main goal of the application.

GRADUATION PROJECT 58
 Figure 4.5: Activity diagram «Download a file converted to groovy script»

GRADUATION PROJECT 59
4.3 Chronicle of Sprint

4.3.1 Implementation and realisation

4.3.1.1 List of uploaded files interface

In this interface , the team members get to see all the files that he uploaded ,their status,
the uploaded time and a set of operations that he can use to treat one of the files that
he uploaded.

Figure 4.6: List of uploaded files interface

4.3.1.2 List of unsatisfied conditions in a file with state «Not validated» interface

When the team member clicks on the «check» button , a treatement is launched and
if the conditions are not satisfied the status of file will be changed from «To check» to
«Not validated» and the team member will have access to an interface where he can
consult the list of the unsatisfied conditions within the file.

GRADUATION PROJECT 60
 Figure 4.7: List of unsatisfied conditions in a file with state «Not validated» interface

4.3.1.3 Comparison of files imported at the same time interface

When the team member uploads more than one file at the same time, there is a process
that is triggered and this is represented in the fact of complete analysis of all imported
files and detect if there is a field that has been defined twice with different values in
more than one file, this is a fatal error and it is mentioned in a specific table. Figure
below represents the interface containing the result of analysis of files imported at the
same time.

Figure 4.8: Comparison of files imported at the same time

In this interface ,the team member gets more informations on which field exactly is
defined more than once with different values.

GRADUATION PROJECT 61
 Figure 4.9: Fields defined more than once with different values

4.3.1.4 Dashboard

Figure below shows the dashboard for each team leader. Through this interface, the
team leader can consult statistics in relation to the number of valid, invalid and not yet
verified files imported by all the members of his team.

Figure 4.10: Dashboard of a team leader

Each team member has the same dashboard as the team leader except that the team
leader can see the number of files imported by all team members whereas a team mem-
ber only views the statistics of the files he has uploaded himself.

GRADUATION PROJECT 62
 Figure 4.11: Dashboard of a team member

The interface presented in the figure below allows to provide information about the
number of team leaders and the number of team members corresponding to each of
them, which allows a better vision for user management. In addition, the system also
displays the number of files processed by each working day and their status (valid,
invalid, not yet processed). The main objective is to minimize the number of files that
are still waiting to be processed and also to speed up the correction time for invalid
files in order to convert them into « Groovy » files, which is the main objective of this
application.

Figure 4.12: Dashboard of the admin

GRADUATION PROJECT 63
4.4 Feedback

The feedback is a very important way in order to improve our application.During this
sprint the feedback is positive.The scrim master loved the quality of the work and the
well understood requirements.However her suggestion was to imporve the graphical
chart of the application so it will be more eye-catching.

Conclusion

During this chapter, we illustrated the backlog of this sprint then we proceded to show
some of the features achieved through the UML diagrams.We concluded this chapter
with showing the different interfaces that we implemented during this sprint and of
course getting the feedback because it will help us imporve our application.

GRADUATION PROJECT 64
General Conclusion

In this report, we have presented the stages of our graduation project, which aims to
create a web application for analysis, management of configuration files and conver-
sion of these files into a Groovy script under the system testing team in FIS Tunisia.

The main objective is the automation of the process of manually checking the con-
figuration files of the new product «ValdiSwitch» that FIS recently migrated to and
the conversion of these files to Groovy script to be the input configuration files of the
«ValdiSwitch».

In order to achieve this result, we first of all started by presenting the host organization
in which we carried out our graduation project. In order to carry out this project, we
have adopted a working methodology in which we started with a study of the existing
situation in order to deepen the analysis of the innovative dimensions of this project.

At that point, we analyzed and indicated the essential needs for the improvement of
our project. we were able to recognize the most functionalities that the application
must coordinated as well as the non-functional needs that it must meet.

We then continued to the design stage : we begun with the design approach to lead
a short time later to a point by point plan that emphasizes the inactive viewpoint and
flow of the application. At long last, we displayed the equipment and computer pro-
gram situations utilized as well as an outline of the diverse graphical interfacing of our
application.

GRADUATION PROJECT 65
This work has allowed us to deepen our knowledge of good programming practices,
especially data security and documentation. Blocking situations, technical problems
and pressure related to tight deadlines have taught us to better manage time, to adopt
a working method and to respect specifications.Many thanks to my professional and
academic supervisors who were always there to reply to my questions and guided me
through this project.

Thanks to its evolutionary character, our project remains open to improvements.

We can add more statistics and enrich user dashboards. We can also containerize our
application with Docker in order to facilitate the deployment of the application.

GRADUATION PROJECT 66
Bibliography

[1] FIS company. https://www.fisglobal.com/about-us/

about-our-company. [ Access 4-August-2020].

[2] FIX protocol. https://www.trading-automatique.fr/

trading-electronique-professionnel/protocole-fix. [Access
4-August-2020].

[3] Total Cost of Ownership – TCO. https://www.investopedia.com/terms/

t/totalcostofownership.asp. [Access 15-August-2020].

[4] UML Actor. https://www.uml-diagrams.org/use-case-actor.html. [

Access 15-August-2020].

[5] Nonfunctional Requirements. https://www.scaledagileframework.com/

nonfunctional-requirements/. [ Access 5-September-2020].

[6] Spring Security. https://spring.io/projects/spring-security. [ Ac-

cess 6-September-2020].

[7] What is UML? https://www.visual-paradigm.com/guide/

uml-unified-modeling-language/what-is-uml/. [ Access 7-September-
2020].

[8] Webstorm. https://fr.wikipedia.org/wiki/WebStorm. [ Access 10-

September-2020].

[9] Install sts. https://o7planning.org/fr/10249/

installez-spring-tool-suite-dans-eclipse. [ Access 10-September-
2020].

GRADUATION PROJECT 67
[10] Create a document in overleaf. https://www.overleaf.com/learn/
how-to/Creating_a_document_in_Overleaf. [ Access 10-September-
2020].

[11] Online visual pradigm. https://www.visual-paradigm.com/solution/

diagramming-tool-on-the-cloud/. [ Access 15-September-2020].

[12] Inroduction to spring framework. https://www.geeksforgeeks.org/

introduction-to-spring-framework/. [Access 15-September-2020].

[13] Spring Boot : The Most Notable Features You Should Know. https://dzone.
com/articles/what-is-spring-boot. [ Access 11-September-2020].

[14] Spring Data. https://spring.io/projects/spring-data-jpa. [ Access

11-September-2020].

[15] Introduction to the Java Persistence API. https://www.infoworld.com/

article/3379043/what-is-jpa-introduction-to-the-java-persistence-api.
html. [ Access 11-September-2020].

[16] Maven. https://www.jmdoudoux.fr/java/dej/chap-maven.html. [ Ac-

cess 11-September-2020].

[17] Swagger. https://swagger.io/tools/swagger-ui/. [ Access 15-

September-2020].

[18] What is Angular ? https://monpetitdev.fr/

cest-quoi-angular-definition. [ Access 16-September-2020].

[19] Testez you API with Postman. https://openclassrooms.

com/fr/courses/4668056-construisez-des-microservices/
5123020-testez-votre-api-grace-a-postman. [ Access 16-September-
2020].

[20] What Is Spring Security? https://www.developer.com/java/ent/

what-is-spring-security.html. [ Access 16-September-2020].

[21] Presentation of Lombok. http://ndruet.github.io/blog/2013/06/20/

presentation-de-lombok/. [ Access 16-September-2020].

GRADUATION PROJECT 68
[22] Introduction aux jetons Web JSON . https://jwt.io/introduction/. [ Ac-
cess 18-September-2020].

GRADUATION PROJECT 69
GRADUATION PROJECT 71