Rapport de stage de fin d’etudes

By Ouerghie Houssem & Dakhlaoui Aymen

June 22,2021
Dedications:
It is a humbling experience to acknowledge those people who have, mostly out of kindness,
helped along the journey of my Studies. I am indebted to so many for encouragement and
support. To my many friends and family, you should know that your support and
encouragement was worth more than i can express on paper.

Thank you, mom, for never giving up on me, and pushing me to be my very best. I couldn’t
have become who i am without your guidance and support. Thank you for raising me to be
me.

Thank you, dad, from you i have learned never to give up. I always have your words with
me, they lift me up when i am down and life struggles to get me.

Thank you, sister, I think of all of the things we have shared growing up, and the least I can
do is thank you for being such a wonderful sister to me for as long as I can remember.
Thank you for being my sister.

Thank you, uncle, every time that I turned around, you were always there for me. You have
always ensured that I was happy and even when you would scold me, it was for my benefit. I
may not have said it enough in my life and so, I wanted to make it clear today that I am
filled with gratitude for you being in my life

Last but no least I want to say thanks to my grandparents, even the ones that are not here
with us today, thank you for all you do and did, please know you are a shining part of my life.

At the end i want to thank all my friends, your friendship has rewarded me with love,
understanding and support, thank you. I just wanted to write to let you know how much I
appreciate the positive influence you’ve had on my life. Thank you for your concern and
useful advice! I’ll be forever grateful.

Ouerghie Houssem

1
Dedications:
I dedicate this project : To my dear parents KAMEL and MALIKA, symbol of love and
unconditional sacrifice.

To my supporter team Infoplus and to my binome Ouerghie Houssem. One of the sweetest
gestures that one can show

Dedication could not be commensurate with the gratitude and respect that I carries you.
May God preserve you all and give you health and long life.

Words are not enough to express my gratitude for your kindness to our family and my
friends and to all those who are dear, close to my heart, and to all who love me and would
have liked to share my joy.

Dakhlaoui Aymen

2
Acknowledgement:
At the end of my graduation project, I would like to express my feelings of gratitude to all
the people who by their presence, support, availability and their advice, I was able to
accomplish this project.

First of all, I would like to express my sincere thanks to Ms. Hanen Bouhadda, who knew
with her professionalism and her pedagogical supervision how to guide me during this
internship. I thank her for her regular monitoring of my progress in the project, for his
valuable advice and encouragement.

my sincere thanks also go to my supervisor at Tunisian red Crescent, Mr. Ben Ammar
Hazem, responsible for research and development, for his welcome, his availability, his
advice, his confidence in this project and for all the help he brought me to allow me to
better understand the work to be done throughout the internship.

May the members of the Jury also find my highest considerations for having accepted to
evaluate my work.

3
Contents

1 General context and project presentation 11

1.1 Host organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.1.1 Tunisian Red Crescent . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.1.2 Services provided . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2 Subject context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.3 Critique of the existing and proposed solution . . . . . . . . . . . . . . . . . 12
1.3.1 Description of the existing . . . . . . . . . . . . . . . . . . . . . . . 12
1.3.2 Proposed solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4 Methodological choice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.4.1 Modeling formalism . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.4.2 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.5 Basic notions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.5.1 What is a web application ? . . . . . . . . . . . . . . . . . . . . . . 14
1.5.2 What is a dashboard ? . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.5.3 What are sockets . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.5.4 What is UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.5.5 What is FLUX architecture . . . . . . . . . . . . . . . . . . . . . . 15

2 Analysis and specification of needs 16

2.1 Needs analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.1 Study of the existing . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.2 Identifying roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1.3 Functional requirements . . . . . . . . . . . . . . . . . . . . . . . . 18
2.1.4 Non-functional needs . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2 Use case diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2.1 General use case diagram . . . . . . . . . . . . . . . . . . . . . . . 21
2.2.2 Refined use case diagrams . . . . . . . . . . . . . . . . . . . . . . . 22

3 Conceptual study 32
3.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.1.1 N-Tier Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.1.2 Architecture of the ”Tunisian Red Crescent Web Application” . . . . 33
3.2 Detailed design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.2.1 Class diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.2.2 Sequence diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4
4 Realization and implementation 44
4.1 Development environment . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.1.1 Hardware environment . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.1.2 Software environment . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2 Development tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2.1 Technological choices . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2.2 Programming languages . . . . . . . . . . . . . . . . . . . . . . . . 46
4.3 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.3.1 Always Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.3.2 Deployment steps . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.4 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.4.1 Authentication interfaces . . . . . . . . . . . . . . . . . . . . . . . 50
4.4.2 Different scenarios for using the dashboard . . . . . . . . . . . . . . 52

5
List of Figures

1.1 Scrum life cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.1 General use case diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.2 News feed use case diagram . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.3 Manage privileges use case diagram . . . . . . . . . . . . . . . . . . . . . . 24
2.4 Manage volunteers use case diagram . . . . . . . . . . . . . . . . . . . . . 25
2.5 Manage families use case diagram . . . . . . . . . . . . . . . . . . . . . . . 29
2.6 Manage financial data use case diagram . . . . . . . . . . . . . . . . . . . . 30
2.7 Manage meetings use case diagram . . . . . . . . . . . . . . . . . . . . . . 30
2.8 Manage events use case diagram . . . . . . . . . . . . . . . . . . . . . . . 31

3.1 n-tiers architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.2 Three tiers architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.3 Presentation layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.4 Business layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.5 Class diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.6 Login sequence diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.7 Sign up sequence diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.8 News feed sequence diagram . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.9 Managing privileges sequence diagram . . . . . . . . . . . . . . . . . . . . . 39
3.10 Managing users sequence diagram . . . . . . . . . . . . . . . . . . . . . . . 39
3.11 Managing families sequence diagram . . . . . . . . . . . . . . . . . . . . . 40
3.12 Managing financial data sequence diagram . . . . . . . . . . . . . . . . . . 41
3.13 Managing meetings sequence diagram . . . . . . . . . . . . . . . . . . . . . 42
3.14 Managing events sequence diagram . . . . . . . . . . . . . . . . . . . . . . 42

4.1 Always data platform’s dashboard . . . . . . . . . . . . . . . . . . . . . . . 47

4.2 Old API’s url . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.3 New API’s url . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.4 Building process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.5 Public folder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.6 Serving the index file on entering the root link of the server . . . . . . . . . 49
4.7 Uploading the server to always data platform . . . . . . . . . . . . . . . . . 50
4.8 Signup page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.9 Login page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.10 Error handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.11 News feed page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.12 Creating a post . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.13 Looking at a list of conversations . . . . . . . . . . . . . . . . . . . . . . . 53
4.14 Looking at a specific conversation . . . . . . . . . . . . . . . . . . . . . . . 54

6
4.15 Looking at a specific event . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.16 Super admin accepting new volunteers . . . . . . . . . . . . . . . . . . . . 55
4.17 Super admin editing other volunteers’ privileges . . . . . . . . . . . . . . . . 55
4.18 Treasurer looking at his dashboard . . . . . . . . . . . . . . . . . . . . . . 56
4.19 Diffusion manager looking at his panel . . . . . . . . . . . . . . . . . . . . 57
4.20 Diffusion manager checking a specefic meeting . . . . . . . . . . . . . . . . 57
4.21 Diffusion manager looking at his panel . . . . . . . . . . . . . . . . . . . . 58

7
List of Tables

8
 General introduction

A good level of participants knowledge indeed allows the organizations to know better those
who contribute to its prosperity, including information about their profiles, needs, interests
and expectations.

The collection of the right information, its structuring in readable and easy files accessible,
are some of the challenges facing small organizations.

By data collection, we mean the systematic approach of bringing together and measure
information from various sources, in order to gain insight complete and precise of an area of
interest. Data collection allows a person or an organization to answer relevant questions and
assess results.

As a result, Tunisian red crescent, the host organization of our internship, decided to
automate the process of collecting and processing data. Indeed, the main objectives of our
internship was divided into two fundamental parts, starting with the collection of relevant
information until the implementation of a tool allowing the administrator to collect data as
needed and to consult tables of edge.

9
 No plagiarism charter Protection of intellectual property

Tout travail universitaire doit être réalisé dans le respect intégral de la propriété intellectuelle
d’autrui. Pour tout travail personnel, ou collectif, pour lequel le candidat est autorisé à
utiliser des documents (textes, images, musiques, films etc.), celui-ci devra très précisément
signaler le crédit (référence complète du texte cité, de l’image ou de la bande-son utilisés,
sources internet incluses) à la fois dans le corps du texte et dans la bibliographie. Il est
précisé que l’UCO dispose d’un logiciel anti-plagiat, aussi est-il demandé à tout étudiant de
remettre à ses enseignants un double de ses travaux lourds sur support informatique.

Cf.  Prévention des fraudes à l’attention des étudiants 

Je soussigné(e), . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .,
étudiant(e) en . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . m’engage à
respecter cette charte. Je soussigné(e),

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ., étudiant(e) en
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . m’engage à respecter cette
charte.

Fait à . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . ,
le. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..

Signature :

10
Chapter 1

General context and project

presentation

Introduction
In this chapter we are going to present the host organization the Red Crescent Of Tunisia,
we are also going to identify the problems and introduce some ways to fix them, last but not
least we’ll talk about the methodology used, at last, we will present some basics which will
be useful for the rest of our report.

1.1 Host organization

We will start with a narrow presentation of the host organization Tunisian Red Crescent and
its activities

1.1.1 Tunisian Red Crescent

The International Red Cross and Red Crescent Movement is an international humanitarian
movement with approximately 97 million volunteers, members and staff worldwide, which was
founded to protect human life and health, to ensure respect for all human beings, and to
prevent and alleviate human suffering. Within three distinct organizations that are legally
independent from each other, but are united within the movement through common basic
principles, objectives, symbols, statutes and governing organizations.

1.1.2 Services provided

The official mission of the ICRC as an impartial, neutral, and independent organization is to
stand for the protection of the life and dignity of victims of international and internal armed
conflicts. According to the 1997 Seville Agreement, it is the ”Lead Agency” of the Movement
in conflicts. Their Fundamental principles are

ˆ Humanity: The International Red Cross and Red Crescent Movement, born of a desire
to bring assistance without discrimination to the wounded on the battlefield, endeav-
ors, in its international and national capacity, to prevent and alleviate human suffering
wherever it may be found. Its purpose is to protect life and health and to ensure respect

11
 for the human being. It promotes mutual understanding, friendship, cooperation and
lasting peace among all peoples.

ˆ Impartiality: It makes no discrimination as to nationality, race, religious beliefs, class

or political opinions. It endeavors to relieve the suffering of individuals, being guided
solely by their needs, and to give priority to the most urgent cases of distress.

ˆ Neutrality: In order to continue to enjoy the confidence of all, the Movement may
not take sides in hostilities or engage at any time in controversies of a political, racial,
religious or ideological nature.

ˆ Independence: The Movement is independent. The National Societies, while auxil-

iaries in the humanitarian services of their governments and subject to the laws of their
respective countries, must always maintain their autonomy so that they may be able at
all times to act in accordance with the principles of the Movement.

ˆ Unity: There can be only one Red Cross or one Red Crescent Society in any one
country. It must be open to all. It must carry on its humanitarian work throughout its
territory.

ˆ Universality: The International Red Cross and Red Crescent Movement, in which all
Societies have equal status and share equal responsibilities and duties in helping each
other, is worldwide.

1.2 Subject context

As a part of their activities, the red cross has to manage multiple databases, families,
volunteers, meetings, and others we will talk about later, that is why they want to
implement a web application to help manage their internal system, a way to manage their
members(volunteers) and their databases.

1.3 Critique of the existing and proposed solution

1.3.1 Description of the existing
Until now the Tunisian Red Cross are still relying on papers, Facebook groups and pages to
manage all their data,and to talk about their events, meetings, and to communicate with
their volunteers, tell them about upcoming events and check their availability.

1.3.2 Proposed solution

To fix a large portion of these problems and help them better manage their internal system,
we decided to build them a Web Application that would have so many functionalities to help
them organize all of their data, better manage their volunteers and display their work for
visitors to see by:

ˆ Having an index page for all visitors where events will be displayed in the form of
articles.

12
 ˆ Including a dashboard for the volunteers where they will be able to communicate
between each others

ˆ Including an administration panel with different roles where they will be able to
manage different parts of the system.

1.4 Methodological choice

In this section, we discuss the modeling formalism for the design of the project. and the
methodology for its realization.

1.4.1 Modeling formalism

For the specification of needs, we opted for the UML modeling language which allows the
description and visualization of needs, as well as the definition of the software architecture.
We present the diagrams useful for the design of the project:

ˆ Use case diagram to visualize the overall behavior of the application.

ˆ Class diagram to define the structure of the application.

ˆ Sequence diagram to describe the different interactions between the elements of the
system and the actors.

1.4.2 Methodology
The methodology is a systematic and technical analysis following an organizational approach
to achieve a result.
To conduct our project well and ensure the smooth running of the various phases, we have
opted for the Agile SCRUM methodology as a project management methodology.
The Scrum methodology is a participatory approach in the conduct of a project. His basic
principle is to always be ready for the reorientation of the project as it progresses. It involves
the self-organization of teams and allows much more responsiveness to adapt to customer
needs. It applies Agile principles, i.e. transparency, simplicity and collaboration.
The Scrum Method supports the rapid and consistent delivery of high-value features added.
Scrum has several advantages:

ˆ The team obtains a clear visibility of the progress of the project.

ˆ The customer takes part in the definition and evolution of the functionalities.

ˆ Requirements are prioritized according to needs and changes faced.

ˆ Large projects are broken down into easily manageable sprints.

Sprint planning includes identifying the priority points the team thinks about be able to
achieve during the sprint

13
 Figure 1.1: Scrum life cycle

The sprint review takes place at the end of each sprint, where the development team
presents features completed. The product increment is possibly deliverable and the
implementation of the next sprint can be anticipated.
The sprint retrospective is an opportunity for the Scrum team to self-inspect and create an
improvement plan to adopt during the next sprint.

1.5 Basic notions

In this part, we will illustrate some basic concepts that will be very useful for the good
understanding of the solution.

1.5.1 What is a web application ?

A Web application (Web app) is an application program that is stored on a remote server
and delivered over the Internet through a browser interface. Web services are Web apps by
definition and many, although not all, websites contain Web apps. According to
Web.AppStorm editor Jarel Remick, any website component that performs some function for
the user qualifies as a Web app.

1.5.2 What is a dashboard ?

It is a visual representation of important information on one screen. It then makes it possible
to measure the performance of a company and to evaluate its organization in order to
achieve one or more objectives.
Essentially, it saves time, because it gives an overview of all the encrypted data that will no
longer be scattered across the different branches of the company, but centralized in a single

14
medium

1.5.3 What are sockets

A socket is one endpoint of a two way communication link between two programs running
on the network. The socket mechanism provides a means of inter-process communication
(IPC) by establishing named contact points between which the communication take place.
Like ‘Pipe’ is used to create pipes and sockets is created using ‘socket’ system call. The
socket provides bidirectional FIFO Communication facility over the network. A socket
connecting to the network is created at each end of the communication. Each socket has a
specific address. This address is composed of an IP address and a port number.
Socket are generally employed in client server applications. The server creates a socket,
attaches it to a network port addresses then waits for the client to contact it. The client
creates a socket and then attempts to connect to the server socket. When the connection is
established, transfer of data takes place.

1.5.4 What is UML

Unified Modeling Language is a pictogram-based graphical modeling language designed as a
standardized method of visualization in the fields of software development and
object-oriented design.

1.5.5 What is FLUX architecture

Flux is an architecture that Facebook uses internally when working with React. It is not a
framework or a library. It is simply a new kind of architecture that complements React and
the concept of Unidirectional Data Flow.

Conclusion
In this chapter, we have presented the project in its general framework, namely the host
organization and the ”Smart Data Collection” project, we have also put the emphasis on the
concepts of the process and the methodologies adopted during the cycle of life of the project.
The next chapter will be on the analysis and specification of the needs of our project.

15
Chapter 2

Analysis and specification of needs

Introduction
The analysis and specification of needs is an important step in the realization of any project
to define the requirements of the application to be developed in order to ensure the
development of expected results. by identifying potential conceptual, organizational and
technical issues
In this chapter, we will do an analysis of the applications of data collection the most used on
the market.In particular, we will present the functional study of our system, identify the
actors interacting with our application, specify the functional and non-functional needs and
finally model using the diagrams of use cases, text descriptions as well as system sequence
diagrams.

2.1 Needs analysis

This is the first phase of a project that guarantees success in as it defines the real needs of
those who will use the end result. Phase communication and exchange, it is often a
reflection of the end result.

2.1.1 Study of the existing

The system they are using now has many flows, and they need a better way to manage their
activities and to solve problems such as:

ˆ Using papers.

ˆ There is no way to evaluate the volunteers

ˆ There is no way to display their work

ˆ There is no good communication between the volunteers

16
2.1.2 Identifying roles
An actor is an entity external to the modeled system, and which interacts directly with it
through external elements that interact with a system Each actor corresponds to a role and
not to a natural person
For the representation of actors, our application is mainly based on the notion of roles, and
this is why user functionalities are grouped together each by role. Our application interacts
with three main players who are:

ˆ Simple user : It’s a user that will only use the application to check events, gallery or
calendar.

ˆ Volunteer : It’s a user that has access to the dashboard but does not have any
administrative role.

ˆ Administrator : It’s a user that has access to the dashboard and has one or many roles
(privileges) and can access parts of the web application to manage the system. There
are 5 different roles :

– Super Admin: Has access to all parts of the web application, he can edit other
volunteers’ roles(privileges).
– Treasurer: Has access to the financial part of the web application, he can
manage programs,actions and transactions.
– Human resources: Has access to the human resources part of the web
application, he can manage volunteers and families.
– General secretary: Has access to the general secretary part of the web
application, he can manage meetings.
– Diffusion: Has access to the diffusion part of the web application, he can manage
events.

17
2.1.3 Functional requirements
A functional need expresses an action that the system must perform in response on demand
(outputs that are produced for a given set of inputs). In the follows, we will present the
functionalities that the system must satisfy in relation to each actor that we have just
specified.
Functional needs are called ”User Stories” in the Scrum approach
A simple user can:

ˆ Sign up: If a simple user wants to become a volunteer, he has the option to sign up,
he will then be accepted by an admin after being checked or tested.

ˆ Check Events: A simple user can have access to see a list of past events, their dates
and places.

ˆ Check gallery: A simple user can have access to see the gallery.

ˆ Calendar: A simple user has access to a calendar where he’ll be able to check
upcoming events.

A volunteer:

ˆ Log in: A volunteer will be able to lo gin to his dashboard account.

ˆ Edit profile: once logged in a volunteer will be able to edit his profile(change
name,email,password and profile picture).

ˆ Post: once logged in a volunteer will be able to post on a news feed where his posts
will be published, seen, liked and commented on by other volunteers.

ˆ Chat: Once logged in a volunteer will be able to search and chat with other volunteers.

A super admin can:

ˆ Create programs: Once logged in an admin with the role treasurer will be able to
create new programs.

ˆ Edit programs: Once logged in an admin with the role treasurer will be able to edit
programs (change program’s name).

ˆ Delete programs: Once logged in an admin with the role treasurer will be able to
delete programs.

ˆ Create actions: Once logged in an admin with the role treasurer will be able to create
new actions.

ˆ Edit actions: Once logged in an admin with the role treasurer will be able to edit
actions (change action’s name).

ˆ Delete actions: Once logged in an admin with the role treasurer will be able to delete
actions.

ˆ Create transactions: Once logged in an admin with the role treasurer will be able to
create new transactions.

18
 ˆ Edit transactions: Once logged in an admin with the role treasurer will be able to edit
transactions (change transaction’s name).

ˆ Delete transactions: Once logged in an admin with the role treasurer will be able to
delete transactions.

ˆ Download data: Once logged in an admin with to role of treasurer will be able to
download excel files with all the financial data.

Human resources:

ˆ Accept volunteers: Once logged in a admin with the human resources role will be able
to accept new volunteers.

ˆ Delete volunteers: Once logged in an admin with to role of human resources will be
able to delete volunteers.

ˆ Evaluate volunteers: Once logged in an admin with to role of human resources will be
able to evaluate volunteers.

ˆ Create families: Once logged in an admin with to role of human resources will be able
to create new families.

ˆ Delete families: Once logged in an admin with the role of human resources will be able
to delete families.

ˆ Edit families: Once logged in an admin with the role of human resources will be able
to edit families.

A general secretary admin can:

ˆ Create meetings: Once logged in a admin with the role of general secretary will be
able to create new meetings.

ˆ Delete meetings: Once logged in a admin with the role of general secretary will be
able to delete meetings.

ˆ Edit meetings privileges: Once logged in a admin with the role of general secretary will
be able to edit meetings.

ˆ Generating meeting’s record: Once logged in a admin with the role of general
secretary will be able to generate a PDF file for the meeting.

A diffusion admin can:

ˆ Create events: Once logged in a admin with the role of diffusion will be able to create
new events.

ˆ Delete events: Once logged in a admin with the role of diffusion will be able to delete
events.

ˆ Edit events : Once logged in a admin with the role of diffusion will be able to edit
events.

19
2.1.4 Non-functional needs
These are the features that characterize the system. These are needs related to performance
and type of design. These needs may relate to the constraints implementation. They can be
considered as specific functional needs. Sometimes they are not linked to a particular use
case but they characterize the whole system (architecture, security, response time, etc.)
The system must ensure the following operational needs:

ˆ Ergonomics: The application must offer a user-friendly and ergonomic interface usable
by the user by considering all possible interactions on the screen of the support held.

ˆ Extensibility: the application should be developed in a modular fashion to make it

possible to integrate new features always.

ˆ Performance: Our application must ensure a minimum response time while ensuring
proper operation of the system. Loading the application and refreshing pages should
not annoy the user.

ˆ Availability: the application must always be available while avoiding failures.

ˆ Maintainability: The application code must be readable and understandable in order

to to ensure its evolving and extensible state in relation to the needs of the market.

ˆ Security: Access to the platform is permitted only to its users. The user must
authenticate in a secure manner in order to access it, so the application must
guarantee the integrity and confidentiality of their data to the user.

20
2.2 Use case diagrams
It is a way of using a system that has a value or a usefulness for the actors involved. The
use case corresponds to a set of actions performed by the system in interaction with the
actors for a purpose.
The use cases allow the description of the interactions of the system to be designed with its
users. An interaction represents a need expected by a user at satisfied.

2.2.1 General use case diagram

Based on the functional needs of our solution we are able to to illustrate the collected
functionality through an overall use case diagram. The latter gives a general idea of how our
system works. vis-à-vis the various actors.

Figure 2.1: General use case diagram

21
2.2.2 Refined use case diagrams
To better understand how our application works, we will detail in this part some of the
above-mentioned use cases

News feed use case diagram

This part offers the user the ability to see,like and comment other volunteers’ posts and post
his own posts. He can also chat with other volunteers.

Figure 2.2: News feed use case diagram

use case news feed

Actor Volunteer

pre-conditions log in

post-conditions volunteer logged in

best case scenario:

22
1. Volunteer enters his email and password

2. system verifies his identity and logs him in

3. volunteer is redirected to the home page

4. a list of posts will be generated to the volunteer

5. volunteer can like and comment on other volunteers’ posts

6. volunteer can post his own posts

7. volunteer can edit and delete his own posts

23
Manage privileges use case diagram
This part offers the admin the ability to edit other volunteer’s privileges

Figure 2.3: Manage privileges use case diagram

use case Manage privileges

Actor Super admin

pre-conditions ˆ log in

ˆ have super admin role

best case scenario:

1. Volunteer enters his email and password

2. system verifies his identity and logs him in

3. system verifies that he has the super admin role

4. volunteer is redirected to the home page

5. volunteer can choose to enter the super admin panel

6. a list of vlunteers will be shown where he can edit there previleges

24
Manage volunteers use case diagram
This part offers the admin the ability to accept and delete volunteers

Figure 2.4: Manage volunteers use case diagram

use case Manage volunteers

Actor ˆ super admin

ˆ human resources

pre-conditions ˆ log in

ˆ have super admin or human resources role

best case scenario:

25
 1. Volunteer enters his email and password

2. system verifies his identity and logs him in

3. system verifies that he has the super admin or human resources role

4. volunteer is redirected to the home page

5. volunteer can chooses to enter the super admin or human resources

panel

6. a list of volunteers will be shown where he can accept or delete them

Manage families use case diagram

This part offers the admin the ability to create, edit and delete families

use case maanage families

Actor human resources

pre-conditions ˆ log in

ˆ have human resources role

best case scenario:

1. Volunteer enters his email and password

2. system verifies his identity and logs him in

3. system verifies that he has the human resources role

4. volunteer can chooses to enter the human resources panel

5. a list of families will be generated to the admin

6. admin can edit a chosen family

7. admin can delete a chosen family

8. admin can create a new family

Manage financial data use case diagram

This part offers the admin the ability to manage programs,actions and financial transactions

use case manage financial data

26
 Actor Tresorer

pre-conditions ˆ log in

ˆ have tresorer role

best case scenario:

1. admin enters his email and password

2. system verifies his identity and logs him in

3. system verifies that he has the human resources role

4. volunteer is redirected to the home page

5. volunteer can chooses to enter the tresorer panel

6. a list of programs will be generated to the admin

7. admin chooses an existing program or creates a new program

8. a list of actions will show up

9. admin chooses an action or create a new action

10. a list of transaction will show up

11. admin edit an existing transaction

12. admin deletes an existing transaction

13. admin creates a new transactions

14. admin downloads a csv file with all the data

Manage meetings use case diagram

This part offers the user the ability to create, edit and delete meetings

use case manage meetings

Actor general secretary

pre-conditions ˆ log in

ˆ have general secretary role

best case scenario:

27
 1. Volunteer enters his email and password

2. system verifies his identity and logs him in

3. system verifies that he has the general secretary role

4. volunteer can chooses to enter the general secretary panel

5. a list of meetings will be generated to the admin

6. admin can edit a chosen meeting

7. admin can delete a chosen meeting

8. admin can create a new meeting

Manage events use case diagram

This part offers the user the ability to see,like and comment other volunteers’ posts and post
his own posts

use case manage events

Actor diffusion manager

pre-conditions ˆ log in

ˆ have diffusion manager role

best case scenario:

1. Volunteer enters his email and password

2. system verifies his identity and logs him in

3. system verifies that he has the diffusion manager role

4. volunteer can chooses to enter the diffusion panel

5. a list of events will be generated to the admin

6. admin can edit a chosen events

7. admin can delete a chosen events

8. admin can create a new event

28
 Figure 2.5: Manage families use case diagram

Conclusion
In this chapter we have designated the various actors involved in our application and subse-
quently specified the functional and non-functional requirements. We have also mentioned
the overall use case diagram as well as some diagrams of detailed use cases.

29
Figure 2.6: Manage financial data use case diagram

Figure 2.7: Manage meetings use case diagram

30
Figure 2.8: Manage events use case diagram

31
Chapter 3

Conceptual study

Introduction
The success of any project depends on the quality of its start. stated, we are entering the
design development phase, which is a phase fundamental and essential in the process of
developing a project. During this chapter, we will first present the software architecture of
the application.
Then we undertake the in-depth design in which we detail the static views through the class
diagram, as well as dynamic views exposing the operation inside the application through
sequence diagrams detailed.

3.1 Architecture
In response to the needs already defined, our solution aims to guarantee a remarkable
momentum of rise, evolution and ductility for all the elements that constitute. Hence, we
wanted these aspects to be evident in both the physical and logical architecture that is the
subject of this part.

3.1.1 N-Tier Architecture

N-level architecture is also called multi-level architecture because the software is designed to
physically and logically separate the processing functions, data management and
presentation. This separation guarantees us to obtain services at the best possible rate and
easier to manage. An N-level architecture would involve dividing an application into three
levels different:

ˆ Presentation level: user interfaces on a PC, which are addressed to server applications

ˆ Business level (also called logic): server applications that contain logic management
and access to data

ˆ Database level: database servers

32
 Figure 3.1: n-tiers architecture

3.1.2 Architecture of the ”Tunisian Red Crescent Web Application”

Our application will be based on the 3-tiers architecture This architecture is a logical model
of application architecture which aims to model an application as a stack of three software
layers (or levels, floors).

Figure 3.2: Three tiers architecture

33
Logical architecture

The figure above has the architecture of our solution. This figure shows that the logical
architecture of the solution represents a separation between the different components
according to the treatment they establish. It consists of three main parts:
ˆ Frontend: this is the presentation layer

ˆ Backend : It takes the various web application services, configuration and the
authentication part.
ˆ Database: contains all the data used by our application
Presentation layer
This is the layer that corresponds to the visible and interactive part of the application for
users, we are talking about human-machine interfaces. This layer provides the navigation
logic in the application. This layer relays user requests to destination of the processing layer,
and in return presents it with the information returned by the treatments of this layer. In
return, it does not contain any treatment job.

Figure 3.3: Presentation layer

ˆ Stores: They contain the application state and logic. Their role is somewhat similar
to a model in a traditional MVC, but they manage the state of many objects — they
do not represent a single record of data like ORM models do. Nor are they the same as
Backbone’s collections. More than simply managing a collection of ORM-style objects,
stores manage the application state for a particular domain within the application.

34
 ˆ Actions: Include the treatments necessary for the consumption of APIs from the
backend.
ˆ Dispatchers : As mentioned above, a store registers itself with the dispatcher and
provides it with a callback. This callback receives the action as a parameter. Within
the store’s registered callback, a switch statement based on the action’s type is used
to interpret the action and to provide the proper hooks into the store’s internal
methods. This allows an action to result in an update to the state of the store, via the
dispatcher. After the stores are updated, they broadcast an event declaring that their
state has changed, so the views may query the new state and update themselves.
Business layer

It is also called the treatment layer. It corresponds to the functional part of the application.
The business layer describes the operations and processing of our application .
In our case, this layer contains the controller going to receive the REST requests, the
javascript services which are responsible for collecting and processing data, the data layer
that supports all interactions between the application and the database.

Figure 3.4: Business layer

ˆ Controller: Ensures the exposure of processing results using REST web services.
This is the party responsible for communicating with the party frontend.
ˆ Models: Represents the data models of our application.
ˆ Router:
ˆ Database: Represent the Database tier.

Physical architecture
The choice to be made concerning the architecture is finally the most critical in the design
of the project. Moreover, it simulates its performance and maintenance throughout its life
cycle.
Through this architecture we distinguish the following parts:
ˆ A thin client that represents a web browser allowing its user to access the application
via the internet
ˆ The web server is where the application is run to process requests for users
ˆ A database server, in our case ”MongoDB”, allowing data persistence.

35
3.2 Detailed design
In this part, we will present the class diagram, some sequence diagrams to better understand
how our solution works.

3.2.1 Class diagram

In our case we decided to use the MongoDb database because of our need for NoSql .Unlike
SQL, NoSql has no names or constraints for data modeling diagrams what offers us a fast
performance in level of data collection.

Figure 3.5: Class diagram

3.2.2 Sequence diagrams

A sequence diagram is the graphic presentation of the interactions between actors and the
system in chronological order in the UML formulation (Unified Modeling Language). It
allows to show the interactions of objects within the framework of a scenario of a use case
diagram.
In what follows, we will present the system sequence diagrams corresponding to some use
cases.

36
 Figure 3.6: Login sequence diagram

Figure 3.7: Sign up sequence diagram

Sequence diagram of Authentication system

37
Sequence diagram of managing being a part of the news feed

Figure 3.8: News feed sequence diagram

38
Sequence diagram of managing privileges

Figure 3.9: Managing privileges sequence diagram

Sequence diagram of managing volunteers

Figure 3.10: Managing users sequence diagram

39
Sequence diagram of managing families

Figure 3.11: Managing families sequence diagram

40
Sequence diagram of managing financial data

Figure 3.12: Managing financial data sequence diagram

41
Sequence diagram of managing meetings

Figure 3.13: Managing meetings sequence diagram

Sequence diagram of managing events

Figure 3.14: Managing events sequence diagram

42
Conclusion
In this chapter we have dealt with the conceptual aspect of our solution. We have started by
presenting the architecture that our solution will have to satisfy, then we have presented the
different class diagrams relating to various parts of the project to finally arrive at the
sequence diagrams.

43
Chapter 4

Realization and implementation

Introduction
This chapter represents the last part of this report and aims to expose work completed.
First, we start with the presentation of the hardware environment and technological choices,
programming language and appropriate techniques for carrying out the application.
Secondly, we describe the work carried out while detailing a few screenshots of the
functionalities performed.

4.1 Development environment

In this part we are interested in a study of the technical environment available for the
realization of our project, then we mention the choices made in terms of the software
environment to complete the application part.

4.1.1 Hardware environment

We used a laptop with the following characteristics:

ˆ Operating system: 64-bit Operating System - Windows 10 pro

ˆ Processor: Intel(R) Core(TM) i5-10300H

ˆ Memory: 16 Go of Ram

4.1.2 Software environment

In this part, we present the software tools for which we have opted during all phases of the
project, from specification to completion, namely:

Visual Studio Code

is an open-source, free code editor and cross-platform (Windows, Mac and Linux),
developed by Microsoft, not to be confused with Visual Studio, Microsoft’s proprietary IDE.
VSC is developed with Electron and leverages advanced editing features of the Monaco
Editor project. Mainly designed for application development with JavaScript, Type Script

44
and Node.js, the editor can adapt to other types of languages thanks to a good extension
system provided.

MongoDB Compass
this software is an administration client of popular and efficient Mongo databases (v1.26.2 in
our case)

Insomnia
It is a tool created by Kong, used by web developers who allows testing of custom http
requests. It offers full control over connections and request headers and a way to organize
your requests into folders and subfolders for easy access later.

Adobe Photoshop
Adobe Photoshop is a raster graphics editor developed and published by Adobe Inc. for
Windows and macOS. It was originally created in 1988 by Thomas and John Knoll. Since
then, the software has become the industry standard not only in raster graphics editing, but
in digital art as a whole.

Adobe Illustrator
Adobe Illustrator is a vector graphics editor and design program developed and marketed by
Adobe Inc. Originally designed for the Apple Macintosh, development of Adobe Illustrator
began in 1985. Along with Creative Cloud, Illustrator CC was released.

Texmaker
It is a text editor made for windows with a strong predisposition to the creation and
compilation of latex documents.

StarUML
StarUML or UML modeling software, which was ”released as open source” by its publisher,
at the end of its commercial use, under a modified license from the GNU GPL. Today the
StarUML V3 version is only available under a proprietary license.

4.2 Development tools

In this part, we will propose the various development tools used in the during the
development of our solution.

4.2.1 Technological choices

In this part, we will present the techniques used in the realization of our project.

ˆ Frameworks / libraries

45
 – Express: Express js, or simply Express, is a back end web application framework
for Node. js, released as free and open-source software under the MIT License. It
is designed for building web applications and APIs. It has been called the de
facto standard server framework for Node.
– Socket.io: Socket.IO enables real-time, bidirectional and event-based
communication. It works on every platform, browser or device, focusing equally
on reliability and speed. This library helped us to create real time chat and real
time notifications
– Material-UI: Material-UI is a framework that has a lot of React components for
faster and easier web development.
– Feather-icons: Feather is a collection of simply beautiful open source icons. Each
icon is designed on a 24x24 grid with an emphasis on simplicity, consistency and
readability.
– mongoose: Mongoose provides a straight-forward, schema-based solution to
model your application data. It includes built-in type casting, validation, query
building, business logic hooks and more, out of the box.

ˆ React 17: React (also called React.js or ReactJS) is a free JavaScript library
developed by Facebook since 2013. The main purpose of this library is to facilitate the
creation of single page web application, through the creation of state dependent and
generating components an HTML page at each change of state.

ˆ Always Data: Always data is a platform built for developers to host big or small
projects, it allows to host, run, monitor and backup your application’s data securely
and efficiently, it allows you to set up your mailboxes with advanced antispam and
Sieve filtering rules, store all your messages and access them for anywhere, securely
(Webmail, StartTLS, and modern protocols) and to register your domains with more
than 700 TLD available, and manage your DNS records finely (MX, SPF/DKIM,
customs records).

4.2.2 Programming languages

In this part, we expose the programming languages used throughout project.

ˆ JavaScript: JavaScript is a scripting programming language primarily used in

interactive web pages and as such is an essential part of web applications. Along with
HTML and CSS technologies, JavaScript is sometimes considered one of the core
technologies of the World Wide Web.

4.3 Deployment
In this part, we will list the stages of deployment of our application in the ”Always data”
platform. First of all we will present the platform used, then we will show screenshots
concerning the different stages of deployment and finally we will discuss the difficulties that
we have faced this process.

46
4.3.1 Always Data
Always Data mainly supports Go, PHP, Java applications , Python, Node.js, .NET, and
Ruby, although it can also support other languages through ”custom runtime environments”.
The service is Free up to a certain level of consumed resources and only in a standard
environment but not in a flexible environment.

Figure 4.1: Always data platform’s dashboard

4.3.2 Deployment steps

Code level changes (Frontend + Backend)
To deploy an application on any platform we must always adapt our application with the
requested configuration of the platform used by making making some modifications at the
source code level and adding configuration files so that the target platform can understand
our architecture and can have a complete idea about the dependencies of our application.
Firs of all we will start by changing the main URL link for the apis in our react project to
”/” because we will building it and it will be served from the express server

47
 Figure 4.2: Old API’s url

Figure 4.3: New API’s url

Then we will build our react application using the command npm run build

Figure 4.4: Building process

Then we will create a public folder in our server where we will put our index.html file and
then we will serve it as the index page when entering the root page of our server

48
 Figure 4.5: Public folder

Figure 4.6: Serving the index file on entering the root link of the server

Then we will upload our server to the alwaysdata platform using FTP and filezilla as a
software for the upload

49
 Figure 4.7: Uploading the server to always data platform

4.4 User Interface

In this part, we will detail the execution of the different functionalities through well-defined
scenarios.

4.4.1 Authentication interfaces

it constitutes the common interface to all users who allow them to authenticate by each
entering their email and his password or to create an account and wait to be approved.
Once the authentication is successful, the user is redirected to the dahsboard page where he
can access the various functionalities.

Sign up

Figure 4.8: Signup page

Log in

50
 Figure 4.9: Login page

Figure 4.10: Error handling

As you can see if the user inputs some invalid data the system would prompt him and tell
him what he did wrong using a popup, this could be seen in all the web application.

51
4.4.2 Different scenarios for using the dashboard
News feed
After logging in phase, the volunteer will find himself in the dashboard of the web
application, exactly in the news feed
He can share posts there with other volunteers, like and comment on other volunteers’ posts

Figure 4.11: News feed page

Looking at other people’s posts, liking and commenting on them.

52
 Figure 4.12: Creating a post

Being logged in you can also chat with other volunteers

Figure 4.13: Looking at a list of conversations

53
 Figure 4.14: Looking at a specific conversation

Opening a specefic conversation.

Figure 4.15: Looking at a specific event

Looking at a specific event after clicking on it on the top of the news feed.

Super admin
Having access to the super admin panel you can accept new volunteers that haven’t been
accepted yet

54
 Figure 4.16: Super admin accepting new volunteers

Looking at the list of not accepted users.

Figure 4.17: Super admin editing other volunteers’ privileges

Editing a specefic volunteer’s privileges.

55
Treasurer
Having access to the treasurer panel you can handle programs,actions and transaction within
those actions.

Figure 4.18: Treasurer looking at his dashboard

Looking at the list of programs,actions and transactions and you can see the forms he can
fill to manage those panels.

General secretary
Having access to the general secretary panel you can handle meetings, creating new
meetings, editing or deleting old ones.

56
 Figure 4.19: Diffusion manager looking at his panel

You can see the forms he can fill to create new meetings and to check old meetings.

Figure 4.20: Diffusion manager checking a specefic meeting

You can see the forms he can fill to create new meetings and to check old meetings.

57
Diffusion manager
Having access to the diffusion panel you can handle events, creating new events, editing or
deleting old ones.

Figure 4.21: Diffusion manager looking at his panel

You can see the forms he can fill to create new events.

Conclusion
In this chapter, we have detailed how we do our work. We first started with the description of
the hardware and software environments and development tools. Subsequently, we exposed
the implementation of the architecture of our project and we ended with the layout of a few
scenarios processing (authentication, managing items, managing legal and physical persons,
etc.) through screenshots of the interface produced.

58
 Conclusion

Dashboard are being used more and more by a lot of companies and organizations for users
profiling and marketing activities. The information collected allows them to establish the
profile of their users, in other words determining their working efficiency. Unlike big
organizations which have been exploiting these technologies for a few years, small ones that
do not have many users are not.

In this work, which is part of an end-of-study project, our main objective is the creation of
an application that facilitates for the admins the process of data gathering. This work was
done in several stages. The starting point of this internship was the business study of the
Tunisian Red Crescent’s old data saving and gathering techniques in order to determine the
problems and the technical requirements of this profession.

problematic and the study of existing solutions in order to develop our solution. Then, we
focused on the study of functional and non-functional needs of our application. In this step
we have made the decision of the technologies that we will use them after a ”benchmark”
made on the level of available technologies in the market . Moreover, we also had our time
to discuss the sources public data and the various methods such as the data saving
methosds and the consumption of APIs and files that contain public information. were
fortunate enough to deploy our apps using the always data hosting platform

Apart from the technical side, this project was an opportunity to understand the work in a
professional hierarchy within a world wide organization like the Red Crescent. In participating
in the development of the project, we were able to discover the rigor necessary to using
dashboards as well as the good practices necessary for carrying out a quality product.

59
Bibliography

[1] Visual studio code,

https://code.visualstudio.com/

[2] All the informations about star uml is from,

https://staruml.io/

[3] All the informations about expressJS is from,

https://expressjs.com/fr/

[4] All the informations about the socketIO is from,

https://socket.io/

[5] All the informations about materialUI is from,

https://material-ui.com/

[6] All the informations about react is from,

https://fr.reactjs.org/

[7] All the informations about insomnia is from,

https://insomnia.rest/

[8] All the informations about always data is from,

https://www.alwaysdata.com/en/

60