ala_harabi-4 presentation d une platform web

Republic of Tunisia University of Monastir
Higher institute of Computer
Science Mahdia
Project Graduation
Order N°: ..
Ministry of Higher Education and Scientific
Research
DISSERTATION PROJECT
Introduced to
Higher institute of Computer Science Mahdia
In order to obtain
The Degree of License in Computer Science
Performed by:
Aladin HARABI
DEVELOPMENT OF A CRYPTOCURRENCY
TRADING PLATFORM
« CRYPTOPHILIA».
Presented on 16/06/2023, to the review committee:
Ms. Ines BEN HASSINE President
Ms. Afef BEN AHMED Supervisor
Mr. Oussema BELHAJ BEL KACEM Examiner
Academic Year : 2022/2023

Dedications
I want to dedicate this project to everyone who has helped me get where I am today.
I can’t express enough gratitude to my loving parents, Halima Belhaj Aoun and Mo-
hamed Harabi, who gave me the resources I needed to become who I am today as
well as their love and spiritual support. I want to thank my beautiful sister and brother,
Fatma Harabi and Abdallah Harabi, who were always there to encourage me through
the worst times and discomfort. May God keep you safe and grant you all the things
you seek in life.
To my soulmate, Salsabil Chiha, the woman who was with me in every step of this
project beside many other moments before, I will never forget how you support me,
inspired me, and believe in me, without you I would never be here.
I sincerely appreciate you believing in my potential, Jamel, Omar, Moez, Mohamed,
Saber, Baha, Amen, Fayssal, Youssef, Oussema, Alaa Edine, Aziz, Mariem, Si-
war, Skander, and all my friends that helped me, gave me opportunities, and shared
some with me.
I credit this accomplishment to all My Group’s members, Leaders Clubistes, with whom
I have shared every minute of joy and sorrow. I send my best wishes and luck to my
second family UGTE, with whom I had the privilege to work, learn, eat, weep, and laugh.
I would not pass without mention my Club Members, ISI Mahdia Dynamic Club, thank
you for the vibrant energy you bring, Keep Moving Forword.
III

Acknowledgments
My deepest gratitude is extended to my supervisor, Mrs Afef Ben Ahmed, for her tire-
less support and effort. Without her management abilities, I would never have been
able to complete my study project.
I also want to express my sincere gratitude to Mrs Ines Ben Hassine and Mr Oussema
Belhaj Bel Kacem for agreeing to judge My End of the Studies project.
III

Contents
List of Figures VII
List of Tables IX
General introduction 1
1 Project Presentation 3
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Context and objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.2 Project Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Study of exist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.1 Review of existing solutions . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.2 Criticisms of existing solutions . . . . . . . . . . . . . . . . . . . . . 7
1.4.3 Proposed solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2 Requirement specification 10
2.1 Itroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Requirement Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.1 Identification of actors . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.2 Specification of functional requirements . . . . . . . . . . . . . . . 12
2.2.3 Specification of non-functional requirements . . . . . . . . . . . . . 13
2.3 Project management with KANBAN . . . . . . . . . . . . . . . . . . . . . . 13
2.4 Sprint planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5 Technologies and development tools . . . . . . . . . . . . . . . . . . . . . . 15
2.5.1 Back-end development . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5.2 Front-end development . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.5.3 Conception and development tools . . . . . . . . . . . . . . . . . . 16
2.6 Generic diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3 Release1: «Guest & Trader» 21
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2 Sprint 1: «Register» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.1 Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
IV

CONTENTS
3.2.2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3 Sprint 2: « Consult Guide » . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3.1 Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3.2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4 Sprint 3: « Manage his account » . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4.1 Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4.2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.5 Sprint 4: « Realize Trading Transactions » . . . . . . . . . . . . . . . . . . 36
3.5.1 Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.5.2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.5.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.5.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.6 Sprint 5: « Post on forum » . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.6.1 Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.6.2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.6.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.6.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.7 Sprint 6: « Consult Trading Bot » . . . . . . . . . . . . . . . . . . . . . . . . 47
3.7.1 Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.7.2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.7.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.7.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.8 Sprint 7: « Consult Tutorials » . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.8.1 Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.8.2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.8.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.8.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4 Release 2: « Admin » 57
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.2 Sprint 8: « Manage accounts » . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.2.1 Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.2.2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.2.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.2.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.3 Sprint 9: « Manage posts » . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.3.1 Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.3.2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.3.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.3.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.4 Sprint 10: « Manage tutorials » . . . . . . . . . . . . . . . . . . . . . . . . . 70
PFE- Ala Harabi V

CONTENTS
4.4.1 Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.4.2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.4.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.4.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5 Release 3: « Trading Bot » 76
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.2 Sprint 10: « Analyse Cryptocurrency market » . . . . . . . . . . . . . . . . 77
5.2.1 Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.2.2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.2.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.3 Sprint 11: « Conclude estimation and give advice » . . . . . . . . . . . . . 80
5.3.1 Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.3.2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.3.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.3.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
General conclusion and outlook 84
PFE- Ala Harabi VI

List of Figures
4.1.1Interfaces « Binance» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1.2Interfaces « Coinbase » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1.3Interfaces « Kraken » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.0.4kanban board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.0.1Overall Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.1Sprint 1 « Register» use case diagram . . . . . . . . . . . . . . . . . . . . 24
2.3.2Sprint 1 - « Authenticate » sequence diagram . . . . . . . . . . . . . . . . 26
2.3.3Sprint 1 « Authenticate » class diagram . . . . . . . . . . . . . . . . . . . . 27
2.3.4Sprint 1 - Sequence diagram « Register » . . . . . . . . . . . . . . . . . . 28
2.4.5Sprint 1 – Interface « Register » . . . . . . . . . . . . . . . . . . . . . . . . 28
2.4.6Sprint 1 – Interface « Register » . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3.7« Consult Guide» system sequence diagram . . . . . . . . . . . . . . . . . 30
3.4.8Sprint 2 – Interface « Guide » . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2.9Sprint 3 - « Manage his account » use case diagram . . . . . . . . . . . . 32
4.3.10
Sprint 3 - « Modify Photo » sequence diagram . . . . . . . . . . . . . . . . 34
4.3.11
Sprint 3 - « Modify Photo » sequence diagram . . . . . . . . . . . . . . . . 34
4.3.12
Sprint 3- « Manage his account » class diagram . . . . . . . . . . . . . . . 35
4.4.13
4.4.14
5.2.15
« Realize Trading Transactions » use case diagram . . . . . . . . . . . . 38
5.3.16
Sprint 4 - « Realize Trading transactions » sequence diagram . . . . . . 39
5.3.17
Sprint 4 - « Realize Trading transactions » sequence diagram . . . . . . 40
6.2.18
Sprint 5 - « Post on Forum » use case diagram . . . . . . . . . . . . . . . 42
6.2.19
Sprint 5 - « Comment on Post» use case diagram . . . . . . . . . . . . . . 43
6.3.20
Sprint 5 - « Post on Forum » sequence diagram . . . . . . . . . . . . . . . 44
6.3.21
Sprint 5 - « Comment on Post » sequence diagram . . . . . . . . . . . . . 45
6.3.22
Sprint 5 - « Comment on Post » sequence diagram . . . . . . . . . . . . . 46
6.4.23
Sprint 5 - Interface « Post on Forum » . . . . . . . . . . . . . . . . . . . . 47
6.4.24
Sprint 5 - Interface « Comment on Post » . . . . . . . . . . . . . . . . . . . 47
7.2.25
Sprint 6 - « Consult Trading Bot » use case diagram . . . . . . . . . . . . 49
7.3.26
Sprint 6 - « Consult Trading Bot » Sequence diagram . . . . . . . . . . . 50
7.3.27
Sprint 6 - « Consult Trading Bot » Class diagram . . . . . . . . . . . . . . 51
7.4.28
Sprint 6 - Interface « Consult Trading Bot » . . . . . . . . . . . . . . . . . . 52
8.3.29
Sprint 7 - « Consult Tutorials » Sequence diagram . . . . . . . . . . . . . 54
8.3.30
Sprint 7 - « Consult Tutorials » Class diagram . . . . . . . . . . . . . . . . 55
8.4.31
Sprint 7 - Interface « List of Tutorials » . . . . . . . . . . . . . . . . . . . . . 55
VII

LIST OF FIGURES
2.2.1Sprint 8 - « Manage accounts» use case diagram . . . . . . . . . . . . . . 59
2.3.2Sprint 8 - « Manage accounts»: “Update account” sequence diagram . . 61
2.3.3Sprint 8 - « « Manage accounts»: “Delete account” sequence diagram . 62
2.3.4Sprint 8 - « Manage accounts» Class diagram . . . . . . . . . . . . . . . . 63
2.3.5Sprint 8 - « « Manage accounts»: “Delete account” activity diagram . . . 64
2.3.6Sprint 8 - « Manage accounts»: “Update account” activity diagram . . . 64
2.4.7Sprint 8- Interface « Manage accounts »1 . . . . . . . . . . . . . . . . . . . 64
2.4.8Sprint 8- Interface « Manage accounts »2 . . . . . . . . . . . . . . . . . . . 65
3.2.9Sprint 9 - ”Manage posts” use case diagram . . . . . . . . . . . . . . . . . 66
3.3.10
Sprint 9 - « Manage posts »: ”Accept or refuse post” sequence diagram 68
3.3.11
Sprint 9 - « Manage posts » : ”Delete post” sequence diagram . . . . . . 68
3.3.12
Sprint 9 - « Manage posts »: Class diagram . . . . . . . . . . . . . . . . . 69
3.3.13
Sprint 9 - « Manage posts »: activity diagram . . . . . . . . . . . . . . . . 69
3.4.14
Sprint 9 - Interface « Manage posts »1 . . . . . . . . . . . . . . . . . . . . 70
3.4.15
Sprint 9 - Interface « Manage posts »2 . . . . . . . . . . . . . . . . . . . . 70
4.2.16
Sprint 10 - «Manage tutorials» use case diagram . . . . . . . . . . . . . . 71
4.3.17
Sprint 10 - « Manage tutorials » sequence diagram . . . . . . . . . . . . . 73
4.3.18
Sprint 10 - « Manage tutorials » Class diagram . . . . . . . . . . . . . . . 74
4.4.19
Sprint 10- Interface « Manage tutorials » . . . . . . . . . . . . . . . . . . . 74
2.2.1Sprint 10 - « Analyse cryptocurrency market » use case diagram . . . . 78
2.3.2Sprint 10 - « Analyse cryptocurrency market » sequence diagram . . . . 79
3.2.3Sprint 11 - « Conclude estimation and give advice » use case diagram . 81
3.3.4Sprint 11 - « Conclude estimation and give advice » sequence diagram 82
3.4.5Sprint 11 – Interface « Conclude estimation and give advice » . . . . . . 83
PFE- Ala Harabi VIII

List of Tables
1.1 Comparison of existing applications . . . . . . . . . . . . . . . . . . . . . . 8
2.1 Illustrates the different functional Requirements of the “Admin” actor. . . 12
2.2 Cthe different functional Requirements of the “Guest” actor . . . . . . . . 12
2.3 the different functional Requirements of the “Trader” actor. . . . . . . . . 12
2.4 the different functional Requirements of the “Trading-Bot” actor. . . . . . 13
2.5 “CRYPTOPHILIA” Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.6 Sprint Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.7 Conception and development tools . . . . . . . . . . . . . . . . . . . . . . . 18
3.1 Backlog for Sprint 1: « Register» . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2 Textual description of the « Register» use case . . . . . . . . . . . . . . . 24
3.3 Text description of « Authenticate » use case . . . . . . . . . . . . . . . . 25
3.4 Backlog for sprint 2: « Consult Guide ». . . . . . . . . . . . . . . . . . . . . 29
3.5 Textual description of the « Consult Guide» use case. . . . . . . . . . . . 30
3.6 Backlog for sprint 3: « Manage his account ». . . . . . . . . . . . . . . . . 31
3.7 Textual description of the « Manage his account » use case. . . . . . . . 33
3.8 Backlog for Sprint 4: « Realize Trading Transactions » . . . . . . . . . . . 37
3.9 Textual description of the « Realize Trading transactions » use case . . 38
3.10 Backlog for Sprint 5: « Post on forum » . . . . . . . . . . . . . . . . . . . . 41
3.11 Textual description of the « Post on Forum » use case . . . . . . . . . . . 42
3.12 Textual description of the « Comment on Post » use case . . . . . . . . . 43
3.13 Backlog for Sprint 6: « Consult Trading Bot» . . . . . . . . . . . . . . . . . 48
3.14 Textual description of the « Consult Trading Bot » use case . . . . . . . . 49
3.15 Backlog for sprint 7: « Consult Tutorials ». . . . . . . . . . . . . . . . . . . 52
3.16 Textual description of the « Consult Tutorials » use case. . . . . . . . . . 53
4.1 Backlog for Sprint 8: « Manage accounts» . . . . . . . . . . . . . . . . . . 58
4.2 Textual description of the « Manage accounts» use case . . . . . . . . . 60
4.3 Backlog for sprint 9: « Manage posts ». . . . . . . . . . . . . . . . . . . . . 65
4.4 Textual description of the « Manage posts » use case. . . . . . . . . . . . 67
4.5 Backlog for sprint 10: « Manage tutorials ». . . . . . . . . . . . . . . . . . . 71
4.6 Textual description of the « Manage tutorials » use case. . . . . . . . . . 72
5.1 Backlog for Sprint 10: « Analyse cryptocurrency market » . . . . . . . . . 77
5.2 Textual description of the « Manage posts » use case. . . . . . . . . . . . 78
5.3 Backlog for sprint 11: « Conclude estimation and give advice » . . . . . . 80
5.4 Textual description of the « Conclude estimation and give advice » use
case. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
IX

General introduction
Whether we agree with it or not, technology has had a significant impact on human
beings over the past ten years, especially when it comes to areas like machine learn-
ing and artificial intelligence, which have greatly facilitated access to information and
provided several other benefits.
Those involved in cryptocurrency trading and finance are also affected by this.
The process of purchasing and selling digital assets like Bitcoin or Ethereum on a cryp-
tocurrency exchange is known as cryptocurrency trading. It entails utilizing a variety
of trading tactics to make money from this digital currency’ price swings. Trading cryp-
tocurrencies is a high-risk, high-reward activity that calls for a thorough knowledge of
both the market and the technology underlying these digital assets.
Overall, technology has significantly changed the way trading is done, increased ac-
cess to markets and information, and stimulated innovation in the trading business.
However, as technology continues to influence trade in the future, it has also sparked
worries about risks, fairness, and regulatory compliance, all of which need to be prop-
erly handled.
In order to earn the Bachelor of Science in Computer Science (LCS) speciality Engi-
neering Software and Computer Systems (GLSI) from the Higher Institute of Computer
Science of Mahdia (ISIMa), our project is therefore a component of the final project’s
preparation. It sets out to create the ”CRYPTOPHILIA” web application, which special-
izes in cryptocurrency trading.
This brief is organized into 5 chapters listed as follows: This end-of-studies project
report is concluded with a brief conclusion and perspectives.
Chapter 1: The project presentation and the incubation phase are the two sections of
this introductory chapter. The project’s overall framework is described in the first part.
We start by outlining the problem and the larger context. Then, we take a look at a
few already-proven solutions that follow a similar structure to our project. In light of this
investigation, we suggest a fix. The incubation phase is covered in the second section.
We pinpoint the participants in this application’s interactions. We then go into how the
functional and technical requirements for the application were captured. Finally, we
1

LIST OF TABLES
also give you the methodology we used.
Chapter 2: This chapter, titled ” Requirement specification” emphasizes, first, the
application of the chosen methodology by planning our work. We provide a detailed
overview of all the tools, strategies, and methods we will employ to transform the initial
conception into an application that will be self-sufficient.
Chapter 3: In this chapter, we present the initial implementation related to the ”Guest
and Trader” module. We begin by proposing the organization and backlog for this
sprint. Next, we discuss the analysis phase and the conceptual solution by presenting
various diagrams that describe the interaction between the actors and the system.
Finally, we showcase the implementation through the user interfaces.
Chapter 4: In this chapter, we present the implementation of the ”Admin” module.
We provide the organization and its backlog. Then, we discuss the analysis phase and
the conceptual solution by presenting differing diagrams that describe the interaction
between the actors and the system. Lastly, we illustrate the implementation through
the user interfaces.
Chapter 5: In the last chapter, we release the ”Trading Bot” module. We present
the organization and its backlog. Thereafter, we deal with the analysis phase and
the conceptual solution by presenting various diagrams that describe the interaction
between the actors and the system. Finally, we display the implementation via the
user interfaces.
PFE- Ala Harabi 2

Chapter 1
Project Presentation
Summary
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Context and objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.2 Project Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Study of exist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.1 Review of existing solutions . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.2 Criticisms of existing solutions . . . . . . . . . . . . . . . . . . . . . 7
1.4.3 Proposed solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3

CHAPTER 1. PROJECT PRESENTATION
1.1 Introduction
A critical phase in a project’s development cycle is the requirements analysis and spec-
ification phase. By understanding the needs of the many users that the system must
satisfy, it does help to better understand the task asked. We give the preliminary anal-
ysis that was created before beginning the implementation in this area, rather than
our application. We provide an analysis of a few current trading platforms to support
this. Then, we detail our project’s functional and non-functional requirements. The use
case diagram serving as the initial conception constraint will be included. We define
the methods we’ll use throughout the development cycle at the end of this chapter.
1.2 Context and objectives
1.2.1 Context
In order to earn a bachelor’s degree in computer science (LCS), specialty Software
Engineering and Computer Systems (GLSI), from the Higher Institute of Computer Sci-
ence of Mahdia (ISIMa), our present project entitled “CRYPTOPHILIA”: development
of a web application is part of the preparation of the end-of-studies project.
1.2.2 Project Motivations
The final project selection is a crucial step in achieving the relationship between the
learning environment and the working world. Several factors influenced our decisions:
• Our topic acknowledges its advantages, primarily the creation of websites, par-
ticularly those devoted to trade.
• The concept behind this topic is very new, and it provides a practical option for
those looking to invest their money safely, possibly, and with the knowledge that
they would receive assistance.
• the potential for utilizing cutting-edge technology, such as ReactJS, Solidity, NodeJS;
to deepen our computer knowledge.
1.3 Objectives
Our project’s goal is to create a web application that satisfies the demands of the in-
tended user base. Actuality, the application offers the following services:
PFE- Ala Harabi 4

• Provide guide for Guest, who visit the site to help them to make an idea about
the platform and cryptocurrency trading.
• Create an account by choice.Allows Trader to sign up to make trading transac-
tions such as buy and sell Crypto.
• Allows Trader to sign up to make trading transactions such as buy and sell Crypto.
• Enables Trader to keep pace with cryptocurrency market changes and get more
evolution through interaction with the application.
• Permit Trader to give feedback and rate, and post on the forum.
• Provide a Trading Bot which will be in service of Traders to help them making the
best trading choices.
1.4 Study of exist
In the process of implementing projects, the analysis of the current state is a crucial
phase. In order to identify demands and provide project solutions, it actually entails
comprehending and analysing current solutions to establish their strengths and limita-
tions. There are three sections: a description of current solutions, a review of current
solutions, and a presentation of new solutions.
1.4.1 Review of existing solutions
We have taken on the customer’s hat in order to improve the analysis of the current.
We searched far and wide to achieve this. Due to this, there are already a number
of trading platforms that guarantee a service quite similar to ours, notably education
based on the platforms ”Binance,” ”Coinbase,” and ”Kraken”.
1.4.1.1 Binance
One of the biggest cryptocurrency exchanges in the world, Binance provides a huge
selection of trading pairs and reasonable costs. However, it has already experienced
security breaches and has been under regulatory attention in various nations, including
the United States and Japan.
PFE- Ala Harabi 5

Figure 4.1.1: Interfaces « Binance»
1.4.1.2 Coinbase
Popular platform Coinbase is renowned for its straightforward user interface and robust
security features. However, compared to other exchanges, its fees might be exorbitant,
and its customer care has come under fire.
Figure 4.1.2: Interfaces « Coinbase »
PFE- Ala Harabi 6

1.4.1.3 Kraken
Kraken is a reputable exchange that provides cutting-edge trading features and rea-
sonable fees. However, beginners may find it challenging to operate, and it has occa-
sionally had outages during periods of heightened trading volume.
Figure 4.1.3: Interfaces « Kraken »
1.4.2 Criticisms of existing solutions
We have created several criteria for evaluating the solutions already discussed above
that are focused on both the functional and non-functional aspects of the application.
They are defined as follows:
• Criterion 1: Register and create an account on the application.
• Criterion 2: Provides the ability to buy and sell cryptocurrencies.
• Criterion 3: Guarantees reel-time information so that Trader can keep pace with
cryptocurrency market changes and be up to date which will make Traders be
able to make the best choice in realising transaction.
• Criterion 4: Has a well-organized and easy-to-use interface.
• Criterion 5: Provides tutorials and training for Trader that cover a range of top-
ics, from basic concepts to advanced trading strategies to help Traders to better
understand cryptocurrency trading.
PFE- Ala Harabi 7

Criterion Binance Coinbase Kraken
1 Yes Yes Yes
2 Yes Yes Yes
3 Acceptable Acceptable Acceptable
4 Yes Yes Yes
5 Yes Yes Yes
Table 1.1: Comparison of existing applications
1.4.3 Proposed solutions
Following the detailed analysis of the existing, we distinguish that the interest of our
platform ”CRYPTOPHILIA” towards traders is certain. Indeed, our platform offers sev-
eral functionalities necessary for the needs of traders, which are distributed as follows:
• Trading services: Offers cryptocurrency trading services to Traders by giving
them the ability to buy and sell cryptocurrency relying on Solidity API’s.
• Training and information: Offer to customers updated training and information
about using the platform, blockchain and cryptocurrency with many resources.
• Reel-time information: Guarantee reel-time information so that Trader can keep
pace with cryptocurrency market changes and be up to date.
• Publish and comment: Create a forum where traders may post articles, analy-
ses, or debates about cryptocurrencies and leave comments on the work of other
members so that Traders can share experience and advice with each other.
• Friendly interface: Provide a well-organized and easy-to-use interface.
• Trading-Bot: Provide a Trading-Bot to automate trading strategies and help
Traders to make the best choice.
1.5 Methodology
In this part, we discuss the methodology chosen to properly organize and structure our
project and to facilitate and accelerate the conception, documentation and even devel-
opment. In this context, we have chosen the Kanban method. Kanban is a method
of collective and still individual work based on the visualization in the form of a table
(see Figure 1) and the limitation of the work in progress, and the incremental improve-
ment which finds its place in many organizations. The main advantage of the Kanban
methodology is its flexibility. It can be assembled with other kanban methods or other
methods such as PDCA (Deming Wheel).
PFE- Ala Harabi 8

What is kanban? A well-liked framework for implementing agile and DevOps soft-
ware development is kanban. It necessitates complete transparency of work and real-
time capacity communication. Team members can always observe the status of every
piece of work thanks to the visual representation of work items on a kanban board.
Figure 5.0.4: kanban board
The Kanban board is divided into 3 columns namely ”To do”, ”In progress” and ”Done”.
At the beginning, the tasks are listed on the left of the table, in the “to do” column.
Then, when you work on a task, it is listed in the ”in progress” column. Once the
task is completed, it goes to the “done” column. Each task is inserted on a Kanban
label. A label can include the following information which varies from project to project:
Task number / ID, Header, Title, Description, Responsible / participants, Comment,
Keywords, Icons, Priority, Sub- tasks or dependencies and Dates/due dates.
1.6 Conclusion
Throughout this chapter, we begin with a bibliographical study of which we present a
description of our project, context, and problem, then a study of the existing and we
indicated the comparison between the existing systems and these limits. Subsequently,
we clarified the functional and non-functional needs extracted from the problem we are
dealing with. The next chapter will be devoted to the conceptual study of the project to
be carried out.
PFE- Ala Harabi 9

Chapter 2
Requirement specification
Summary
2.1 Itroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Requirement Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.1 Identification of actors . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.2 Specification of functional requirements . . . . . . . . . . . . . . . 12
2.2.3 Specification of non-functional requirements . . . . . . . . . . . . . 13
2.3 Project management with KANBAN . . . . . . . . . . . . . . . . . . . . . . 13
2.4 Sprint planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5 Technologies and development tools . . . . . . . . . . . . . . . . . . . . . . 15
2.5.1 Back-end development . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5.2 Front-end development . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.5.3 Conception and development tools . . . . . . . . . . . . . . . . . . 16
2.6 Generic diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
10

CHAPTER 2. REQUIREMENT SPECIFICATION
2.1 Itroduction
The second chapter, titled ” Requirement specification ” focuses on the utilization of the
first stage of the KANBAN approach. Sprint 0 is a time for investigation, reasoning, and
planning. In the first section of this chapter, we discuss project management using the
Kanban methodology. The planning for the various sprints is described in the section
that follows. Next, a description of the technology and development tools we employed
follows. We also provide a general description of the ”CRYPTOPHILIA” architectural
style. Finally, we present the general use case diagram.
2.2 Requirement Specification
A comprehensive and user-friendly platform for bitcoin trading and exchange is what
our project intends to build. Advanced trading tools, improved security, social engage-
ment, and training management will all be available on the site. The implementation
of advanced trading features including quick order execution, limit orders, stop-loss
orders, interactive price charts, and other technical analysis tools. Users will be able
to monitor their balances, performances, and transaction histories thanks to portfolio
management. In addition to existing industry-standard security procedures, the im-
proved security measures will include two-factor authentication, encryption of sensitive
data, safe management of API keys for exchanges, and more. Users will be able to
engage with one another and share ideas through social interaction. Trading educa-
tion and training will be made available to Traders by the training management. In the
” Requirement Specification ” phase, the system requirements and the various actors
that will interact with them are identified. In this section, we discuss the various actors,
functional needs, and non-functional demands.
2.2.1 Identification of actors
An actor is a role that a real person or a component of the system that communicates
with the system directly plays. Our application identifies three actors, namely:
• Admin: Admin must be registered and logged in, so he be able to manage the
application.
• Trader: Trader must be registered and logged in so he can benefit the application
services.
• Guest: Our Guest is user who has not registered yet, but he doesn’t need an
account to benefit some features in the platform.
PFE- Ala Harabi 11

• Trading-Bot: It is a software program that automatically executes trades on be-
half of users based on pre-defined trading strategies and market conditions.
2.2.2 Specification of functional requirements
The aim of the functional specs is to define the functional scope of the project by pre-
cisely describing all the functions of the application. The customer’s needs are ex-
pressed during the specification-writing process. As a result, each actor in our appli-
cation must satisfy the following conditions.
2.2.2.1 Functional needs of the “Admin” actor
Feature Description
Manage accounts Allows admin to control Trader’s accounts.
Manage tutorials Allows admin to create, update or delete tutorials.
Manage posts Allows Admin to manage posts.
Table 2.1: Illustrates the different functional Requirements of the “Admin” actor.
2.2.2.2 Functional Requirements of the “Guest” actor
Feature Description
Register Gust needs to sign up and wait for approval from the administrator
before being granted user access to the application.
Consult the guide Gust can customize the program and obtain an overview of
the many services available by consulting the ”CRYPTOPHILIA”
handbook.
Table 2.2: Cthe different functional Requirements of the “Guest” actor
2.2.2.3 Functional Requirements of the “Trader” actor
Feature Description
Authenticate The Trader authenticates with his email and password to access
his space.
Manage his account Allows him to manage his profile.
Buy Crypto Allows him to buy cryptocurrency.
Sell Crypto Allows him to sell cryptocurrency.
Consult trading-bot Allows Trader to relay on trading-bot’s help to realise transactions.
Post on forum Allows Trader to post.
Write comment Allows Trader to comment on his post or on other Trader’s posts.
Consult tutorials Allows Traders to learn and get information from platform tutorials.
Table 2.3: the different functional Requirements of the “Trader” actor.
PFE- Ala Harabi 12

2.2.2.4 Functional Requirements of the “Trading-Bot” actor
Feature Description
Analyse Cryptocur-
rency market
It utilizes algorithms and rules to analyze market data.
Conclude estimation Provide an estimation for Cryptocurrencies prices from analyse
result.
Give advice Provide advice for Traders to help them make the best decision.
Table 2.4: the different functional Requirements of the “Trading-Bot” actor.
2.2.3 Specification of non-functional requirements
The life cycle of information systems must take into account a few non-functional re-
quirements and evaluate the integration tests. These requirements are crucial to our
project to maintain the calibre and effective operation of ”CRYPTOPHILIA.” Our project
requires the following:
• Security: The program needs to be safe. The information shouldn’t be open to
the public; instead, a login and password are required to access some program
modules.
• Availability: The platform must be accessible to all users at all times.
• Usability: The platform must be straightforward and user-friendly.
• Performance: The application must be effective, which means that regardless
of user behaviour, the system must respond in a certain amount of time.
• Extensibility: The application must be expandable as part of this task, meaning
the application manager may be able to add or alter new functions.
• Modularity: To enable future evolutions or upgrades, the source code of the
program must be transparent.
2.3 Project management with KANBAN
A requirement is a necessity that a system must satisfy. The details of our application
may also make the aforementioned prerequisites clearer. We noticed that some needs
receive higher importance than others while listing all the features. In general, the func-
tionalities that are verified in the first will be employed to realize those that come after.
Therefore, it is vital to divide the requirements into Low, Medium, and High priorities to
create a well-structured and non-frustrating strategy.
PFE- Ala Harabi 13

ID Feature ID User Story Priority
1 Register 1.1 You must fill out a registration form to
sign up as a Guest.
High
1.2 You must authenticate as a Guest,
Trader, and Administrator.
High
2 Consult the
guide
2.1 You have access to the application
guidance as a Guest.
High
3 Manage his ac-
count
3.1 You can modify your personal infor-
mation as Trader
Average
4 Realize Trading 4.1 4You can buy crypto as a Trader. High
transactions 4.2 You can sell crypto as a Trader. High
5 Post on 5.1 You can post on the platform forum as
a Trader.
Average
forum 5.2 You can comment on the other
Traders’ posts or your own posts as
a Trader.
Average
6 Consult trading-
bot
6.1 The trading-bot help Traders to make
decisions by analysing markets and
give a price estimation.
High
7 Consult tutorials 7.1 You can consult tutorials provided by
the platform as a Trader.
Average
8 Manage ac-
counts
8.1 You can update, block, and delete a
Trader’s account as an Admin.
High
9 Manage posts 9.1 You can accept, refuse, and delete
posts published by traders as an Ad-
min.
Average
10 Manage tutori-
als
10.1 You can create, update, and delete tu-
torials as an Admin.
Average
11 Analyse Cryp-
tocurrency
market
11.1 Utilizing algorithms and rules,
Trading-Bot analyze market data.
High
12 Conclude 12.1 Providing an estimation for Cryptocur-
rencies prices from analyse result.
High
estimation and
give advice
12.2 Provide advice for Traders to help
them make the best decision.
High
Table 2.5: “CRYPTOPHILIA” Backlog
PFE- Ala Harabi 14

2.4 Sprint planning
The work that must be done during the sprint is planned to use the Kanban process.
After much thought, we have found 2 releases. Sprint planning is displayed in Table
2.6
Release ID
Sprint
Sprint Name Period
1 Register 4 days
2 Consult the guide 2 days
3 Manage his account 3 days
Release 1 4 Realize Trading transactions 10 days
5 Post on forum 5 days
6 Consult trading-bot 2 days
7 Manage accounts 3 days
Release3 8 Manage posts 3 days
9 Manage tutorials 3 days
Release4 10 Analyse Cryptocurrency market 5 days
11 Conclude estimation and give
advice
3 days
Table 2.6: Sprint Planning
2.5 Technologies and development tools
Frameworks, classes, and libraries all directly affect productivity by facilitating faster
development and higher-quality code in general. The products, followed by the tools
and programming languages, that we used to complete our project are all presented in
this part.
2.5.1 Back-end development
Spring Boot: Java-based framework makes it easier to create independent, deploy-
able apps. Developers may easily design apps with minimal boilerplate code because
PFE- Ala Harabi 15

they use the Spring ecosystem. Spring Boot is a well-liked option for Java developers
because it is frequently employed for constructing web apps, microservices, and APIs.
NodeJS: Based on the V8 JavaScript engine in Chrome, Node.js is a JavaScript run-
time. It enables the creation of server-side and command-line applications by allowing
developers to execute JavaScript code outside of the browser. Node.js is a popular
option for JavaScript developers since it is extensively used for web development, API
servers, microservices, and creating command-line tools.
PostgreSQL: A free and open-source relational database management system that
emphasizes extensibility and SQL compliance is PostgreSQL, also referred to as Post-
gres. Its original name, POSTGRES, referred to the fact that it was created as a re-
placement for the Ingres database at the University of California, Berkeley.
2.5.2 Front-end development
ReacJS: React is a well-liked JavaScript library for creating user interfaces, it improves
speed by rendering updates to the actual DOM more effectively using a virtual DOM.
React has a huge and active community that contributes to its ecosystem of tools and
libraries. It is also quite versatile and can be used with other libraries or frameworks.
2.5.3 Conception and development tools
We employed a variety of conception and development technologies to bring our ap-
plication ”CRYPTOPHILIA” to life. The table 2.7 includes a list of these.
PFE- Ala Harabi 16

Tool Description
‘ React is a well-liked JavaScript library for creating user interfaces,
it improves speed by rendering updates to the actual DOM more
effectively using a virtual DOM. React has a huge and active com-
munity that contributes to its ecosystem of tools and libraries. It is
also quite versatile and can be used with other libraries or frame-
works.[1]
. Spring Boot is a Java-based framework makes it easier to cre-
ate independent, deployable apps. Developers may easily design
apps with minimal boilerplate code because they use the Spring
ecosystem. Spring Boot is a well-liked option for Java develop-
ers because it is frequently employed for constructing web apps,
microservices, and APIs.[2]
. Based on the V8 JavaScript engine in Chrome, Node.js is a
JavaScript runtime. It enables the creation of server-side and
command-line applications by allowing developers to execute
JavaScript code outside of the browser. Node.js is a popu-
lar option for JavaScript developers since it is extensively used
for web development, API servers, microservices, and creating
command-line tools.[3]
. A free and open-source relational database management sys-
tem that emphasizes extensibility and SQL compliance is Post-
greSQL, also referred to as Postgres. Its original name, POST-
GRES, referred to the fact that it was created as a replacement for
the Ingres database at the University of California, Berkeley.[4]
. Java is a powerful object-oriented programming language with a
broad range of applications that is renowned for its ease of use,
platform freedom, and versatility. With the aid of the Java Vir-
tual Machine (JVM), it was developed to function on any device,
making it incredibly portable. The development of mobile apps,
business software, scientific applications, and websites all use
Java extensively.[5]
. A dynamic, high-level programming language with a focus on
web development, JavaScript. It makes interactive components
and dynamic material possible and improves website user expe-
rience. Real-time updates without page reloading are made pos-
sible by JavaScript because it runs directly in the web browser.
Additionally, server-side programming and the creation of mobile
apps employ it more and more frequently. JavaScript is adapt-
able and well-liked by developers for building dynamic web apps
since it provides a large selection of frameworks and libraries.[6]
PFE- Ala Harabi 17

. The simplicity, clarity, and flexibility of Python, a high-level, in-
terpreted programming language, are well known. It places a
strong emphasis on the readability of the code and provides a
sizable standard library and a robust third-party package ecosys-
tem. Python is appropriate for a variety of applications because
it supports many programming paradigms, including procedural,
object-oriented, and functional programming.[7]
. ATEX is a document composition language and system. It is a
collection of macro commands designed to facilitate the use of
Donald Knuth’s TEX «text processor».[8]
. VSCode is a lightweight, cross-platform code editor by Microsoft.
It offers a rich and customizable environment for coding, with
features like autocompletion, debugging, Git integration, and ex-
tensions. It’s user-friendly, supports multiple OS, and is widely
favoured by developers.[9]
. Users can create flowcharts, diagrams, wireframes, and other vi-
sual representations of professional quality using the web-based
diagramming and visual collaboration tool Lucidchart. The real-
time collaboration feature of Lucidchart enables many users to
collaborate on the same diagram at once, making it an effective
tool for brainstorming and team collaboration.[10]
. Trello is an online project management tool. It is built on a system
of organizing projects into boards listing cards that each represent
tasks. Users can assign the cards to themselves and transfer
them from one board to another to show their progress, we can
share projects using email addresses with teammates for exam-
ple.[11]
Table 2.7: Conception and development tools
PFE- Ala Harabi 18

2.6 Generic diagrams
To satisfy client needs and make it simpler and clearer to comprehend how the system
functions. Figure 6.0.1 below groups all the potential use cases:
Figure 6.0.1: Overall Use Case Diagram
PFE- Ala Harabi 19

2.7 Conclusion
We have discussed the project’s KANBAN piloting in this chapter. we are organiz-
ing relays and sprints. Additionally, we have a list of all the tools and technologies
used for this project. Our decision was primarily aimed at cutting-edge technology and
development trends (ReactJS, Spring Boot, etc.). As a result, several platforms are
mentioned, each of which guarantees the functionality of the program that was devel-
oped. The general use case graphic was then displayed. The implementation of our
project’s initial release is the main topic of the following chapter.
PFE- Ala Harabi 20

Chapter 3
Release1: «Guest & Trader»
Summary
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2 Sprint 1: «Register» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.1 Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3 Sprint 2: « Consult Guide » . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3.1 Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3.2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4 Sprint 3: « Manage his account » . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4.1 Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4.2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.5 Sprint 4: « Realize Trading Transactions » . . . . . . . . . . . . . . . . . . 36
3.5.1 Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
21

CHAPTER 3. RELEASE1: «GUEST & TRADER»
3.5.2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.5.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.5.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.6 Sprint 5: « Post on forum » . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.6.1 Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.6.2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.6.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.6.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.7 Sprint 6: « Consult Trading Bot » . . . . . . . . . . . . . . . . . . . . . . . . 47
3.7.1 Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.7.2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.7.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.7.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.8 Sprint 7: « Consult Tutorials » . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.8.1 Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.8.2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.8.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.8.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
PFE- Ala Harabi 22

3.1 Introduction
The initial release, which supports the «Register», «Consult Guide», «Manage his ac-
count», « Realize Trading transactions », « Post on forum », « Consult trading-bot »
and « Consult tutorials » sprints are all covered in full in this chapter. We present the
organization and its Backlog for each sprint. Following that, we provide the concep-
tual solution and analysis phase, laying out the many diagrams that depict how the
actors interact with the system. We conclude by showcasing the implementation via
the interfaces.
3.2 Sprint 1: «Register»
In the first part of this section, we outline the organisation and backlog for the first sprint
« Register». The analysis stage and the conceptual solution are then presented. The
numerous implementations are then illustrated.
3.2.1 Organisation
A thorough breakdown of the Backlog for the first sprint supporting the « Register»
functionality can be seen in Table 3.1.
ID Sprint ID User Story Estimation/d
1.1 Home interface implementations. 2
1 Register 1.2 Creation of registration interfaces. 2
1.3 development of authentication interfaces 2
1.4 Test the authentication interfaces. 1
Table 3.1: Backlog for Sprint 1: « Register»
3.2.2 Analysis
In this stage, we detail the different functionalities and their use cases.
3.2.2.1 Use case diagrams
We outline the many refined use cases in this section.
- Refinement of the use case for « Register»
PFE- Ala Harabi 23

The « Register» use case refinement is shown in Figure 2.2.1. In order to benefit the
features that “CRYPTOPHILIA” offers, Guest must register.
Figure 2.2.1: Sprint 1 « Register» use case diagram
CU name «Register»
Actor Guest
Summary To use the “CRYPTOPHILIA” features, Guet must register.
Pre-conditions Guest accesses the “Home” page
Nominal Sce-
nario 1. Guest clicks on “Sign Up”.
2. The system displays the form on the “Register” page.
3. The user completes the form and clicks on “Register”.
4. The system checks the consistency of the data.
5. The system saves the data and sends a verification
email.
6. Guest consults his email and clicks on the verification
link.
7. The system saves the data and displays a confirma-
tion message regarding the registration.
8. The system redirects Guest to “Log In” page.
Alternative se-
quences
4.1. The data entered by the Guest is inconsistent: starts at
point 3 of the nominal scenario.
6.1. The verification email is not received: starts at point 3
of the nominal scenario.
Post-conditions Guest authenticates by the system as Trader.
Table 3.2: Textual description of the « Register» use case
A textual explanation of the « Register» use case for the “Guest” actor can be found in
Table 3.2. Both the nominal scenario and the alternate steps are described.
PFE- Ala Harabi 24

- The « Authenticate » use case could be improved.
The « Authenticate » use case is described textually in Table 3.3. Both the nominal
scenario and the alternate sequences are described.
CU name « Authenticate »
Actor Trader
Summary Trader must be authenticated in order to take ad-
vantage of the functionalities offered by « CRYP-
TOPHILIA».
Pre-conditions Trader has already created an account. Trader ac-
cesses to the « Log In» page.
Nominal Sce-
nario 1. Trader fills in the fields and clicks on the « Log In
» button.
2. The system checks the data.
3. The system redirects the actor to the “profile”
page and displays a Welcome message.
Alternative se-
quences
2.1. The data entered by the user is invalid: starts at
Post-conditions Trader is authenticated by the system.
Table 3.3: Text description of « Authenticate » use case
3.2.3 Conception
In this section, we present the conceptual study of the data through the presentation
of the sequence, the class diagram and interaction diagram.
PFE- Ala Harabi 25

3.2.3.1 System sequence diagrams
- « Authenticate » system sequence diagram
Figure 2.3.2 shows how the user interacts with the system to Authenticate.
Figure 2.3.2: Sprint 1 - « Authenticate » sequence diagram
PFE- Ala Harabi 26

3.2.3.2 Class diagrams
The class diagram allows us to describe the internal structure while showing the dif-
ferent classes, their attributes, as well as the various structural relationships between
these classes.
Figure 2.3.3: Sprint 1 « Authenticate » class diagram
Figure 2.3.3 depicts the class diagram that we used to develop the first sprint of Re-
lease1
PFE- Ala Harabi 27

3.2.3.3 Interaction Diagram
In this subsection, we present a sequence diagram that details the interaction between
the front-end and back-end components.
Figure 2.3.4: Sprint 1 - Sequence diagram « Register »
3.2.4 Implementation
Following the analysis of sprint 1 and the design phase, this section illustrates the
human-machine interfaces developed as part of this sprint.
Figure 2.4.5: Sprint 1 – Interface « Register »
PFE- Ala Harabi 28

Figure 2.4.6: Sprint 1 – Interface « Register »
3.3 Sprint 2: « Consult Guide »
In this section, we first present the organisation and Backlog of the second sprint,
«Consult Guide». Next, we present the analysis phase and the conceptual solution.
Finally, the various implementations are illustrated.
3.3.1 Organisation
Table 3.4 gives a detailed overview of the Backlog for the second sprint that supports
the « Consult Guide » functionality.
2.1 The conception of « Consult Guide » inter-
faces.
2
2 Consult
Guide
2.2 Creation of « Consult Guide » interfaces. 2
2.3 Testing « Consult Guide » functionality. 1
Table 3.4: Backlog for sprint 2: « Consult Guide ».
3.3.2 Analysis
In this step, we describe the « Consult guide» functionality and its use case.
- Refinement of the « Consult Guide» use case.
PFE- Ala Harabi 29

Table 3.5 provides a textual description of the « Consult Guide» use case. It details
the nominal scenario.
CU name « Consult Guide »
Actor Guest
Summary The user consults the guide to learn about the different
steps and features offered by « CRYPTOPHILIA».
Pre-conditions Guest access to the « Home» page.
Nominal Sce-
nario 1. Trader accesses the Guide menu.
2. The system displays the interfaces.
Table 3.5: Textual description of the « Consult Guide» use case.
3.3.3 Conception
of the sequence.
3.3.3.1 System sequence diagram
- « Consult Guide» system sequence diagram.
Figure 3.3.7 shows how the user interacts with the system to consult the guide.
Figure 3.3.7: « Consult Guide» system sequence diagram
PFE- Ala Harabi 30

After the analysis of sprint 2 and the conception phase, we illustrate in this section the
user interfaces developed as part of this sprint.
Figure 3.4.8: Sprint 2 – Interface « Guide »
3.4 Sprint 3: « Manage his account »
In this section, we first present the organization and backlog of the third sprint « Manage
his account ». Then, we describe the analysis phase and the conceptual solution.
Finally, we illustrate the different implementations.
3.4.1 Organisation
Table 3.6 gives a detailed overview of the Backlog for the third sprint that supports the
« Manage his account » functionality.
3 Manage
his
3.1 Account management interface implemen-
tations.
3
account 3.2 Testing the account management function-
ality.
1
Table 3.6: Backlog for sprint 3: « Manage his account ».
PFE- Ala Harabi 31

3.4.2 Analysis
In this step, we describe the « Manage his account » functionality and its use case.
- Refinement of the « Manage his account » use case
Figure 4.2.9 illustrates the refinement of the « Manage his account » use case for the
”Trader” actor. The Trader can modify his account information.
Figure 4.2.9: Sprint 3 - « Manage his account » use case diagram
PFE- Ala Harabi 32

Table 3.3.7 provides a textual description of the « Manage his account » use case. It
details the nominal scenario.
CU name « Manage his account »
Actor Trader
Summary The Trader accesses his account and modify some in-
formation.
Pre-conditions Trader accesses profile page.
Nominal Sce-
nario
Scenario 1: Modify Photo
1. The Trader clicks on the ”Profile Photo ” button.
2. The system displays the list of Photos.
3. The Trader selects a profile picture and clicks on
the ”Validate” button.
4. The system saves the data.
Scenario 2: Modify his name
1. The Trader clicks on the ”modify name” button.
2. The system displays the field of name.
3. The Trader fills in the field of name and clicks on
the ”Validate” button.
4. The system saves the data.
Post-conditions Scenario 1: Modify Photo
Photo modified.
Scenario 2: Modify his name
Name modified.
Table 3.7: Textual description of the « Manage his account » use case.
3.4.3 Conception
of sequence diagrams and the class diagram.
In this section, we present the various system sequence diagrams for « Manage his
account ». The trader can modify the profile photo and he can also modify his account
name.
Figure 4.3.11 illustrates the interaction between the Trader and the system to change
the Profile Photo.
PFE- Ala Harabi 33

Figure 4.3.10: Sprint 3 - « Modify Photo » sequence diagram
Figure 4.3.11 illustrates the interaction between the Trader and the system to change
the account name.
Figure 4.3.11: Sprint 3 - « Modify Photo » sequence diagram
PFE- Ala Harabi 34

The class diagram is used to describe the internal structure, showing the different
classes, their attributes, and the different structural relationships between these classes.
Figure 4.3.12 describes the class diagram we used to develop the third sprint of Re-
lease1.
Figure 4.3.12: Sprint 3- « Manage his account » class diagram
After the analysis of sprint 3 and the conception phase, we illustrate in this section the
user interfaces developed as part of this sprint.
PFE- Ala Harabi 35

3.5 Sprint 4: « Realize Trading Transactions »
In this section, we outline the organisation and backlog for the fourth sprint « Real-
ize Trading Transactions ». Then, we present the analysis stage and the conceptual
solution. The numerous implementations are also illustrated.
PFE- Ala Harabi 36

3.5.1 Organisation
A thorough breakdown of the Backlog for the fourth sprint supporting the « Realize
Trading Transactions » functionality can be seen in Table 3.10
4.1 Design and implement of Buy and Sell in-
terfaces.
4
4 Realize Trading 4.2 Implement order placement functionality. 5
transactions 1.3 Development of market data interfaces. 3
4.4 Creation of portfolio management inter-
faces.
3
Table 3.8: Backlog for Sprint 4: « Realize Trading Transactions »
3.5.2 Analysis
- Refinement of the use case for « Realize Trading Transactions ».
PFE- Ala Harabi 37

The « Realize Trading Transactions » use case refinement is shown in Figure 5.2.15
Figure 5.2.15: « Realize Trading Transactions » use case diagram
CU name « Realize Trading transactions »
Actor Trader
Summary The Trader will buy and sell cryptocurrency.
Pre-conditions The Trader must be authenticated.
Nominal Sce-
nario 1. The Trader will select an option “Buy” or “Sell”.
2. The Trader will enter quantity of cryptocurrency.
3. He places the buy or sell order specifying the
price desired.
4. The order is executed by the system.
5. The trader will receive a smart contract.
6. Trader checks the transaction history.
Post-conditions The Trader buys or sells cryptocurrency. Quantity of
cryptocurrency in the wallet is appended.
Table 3.9: Textual description of the « Realize Trading transactions » use case
A textual explanation of the ” Realize Trading transactions ” use case for the ”Trader”
actor can be found in Table 3.9. Both the nominal scenario and the post-conditions are
PFE- Ala Harabi 38

described.
3.5.3 Conception
In this section, we illustrate the conceptual study of the data through the presentation
of the sequence diagram and the class diagram.
Figure 5.3.16: Sprint 4 - « Realize Trading transactions » sequence diagram
PFE- Ala Harabi 39

Figure 5.3.17 depicts the class diagram that we used to develop the sprint 4 of Release2
Figure 5.3.17: Sprint 4 - « Realize Trading transactions » sequence diagram
Following the analysis of sprint 4 and the conception phase, this section illustrates the
3.6 Sprint 5: « Post on forum »
In the first part of this section, we outline the organisation and backlog for the fifth sprint
« Post on forum». The analysis stage and the conceptual solution are then presented.
The numerous implementations are then illustrated.
PFE- Ala Harabi 40

3.6.1 Organisation
A thorough breakdown of the Backlog for the fifth sprint supporting the « Post on forum
» functionality can be seen in Table 3.10
5.1 Forum interface implementations. 2
5.2 Posting interface implementations. 2
5 Post on forum 5.3 Comments interface implementations. 2
5.4 Testing Posting. 1
5.5 Testing Comments. 1
Table 3.10: Backlog for Sprint 5: « Post on forum »
3.6.2 Analysis
- Refinement of the use case for « Post on Forum »
The « Post on Forum » use case refinement is shown in Figure 6.2.18
PFE- Ala Harabi 41

Figure 6.2.18: Sprint 5 - « Post on Forum » use case diagram
The « Post on forum » use case is described textually in Table 3.11. Both the nominal
scenario and the alternative sequences are described.
CU name « Post on Forum »
Actor Trader
Summary The Trader posts on forum to make a transaction re-
quest or give feedback.
Pre-conditions Trader must be authenticated.
Nominal Sce-
nario 1. The Trader accesses the forum.
2. The Trader clicks on the space specified for post-
ing.
3. The Trader creates post depending on objective.
4. The Trader waits for Admin decision.
Alternative se-
quences
4.1. Admin doesn’t accept the post: starts at point 3.
Post-conditions Post is published on the Forum.
Table 3.11: Textual description of the « Post on Forum » use case
PFE- Ala Harabi 42

- Refinement of the use case for « Comment on Post »
The « Comment on Post » use case refinement is shown in Figure6.2.19.
Figure 6.2.19: Sprint 5 - « Comment on Post» use case diagram
CU name « Comment on Post »
Actor Trader
Summary The Trader Comments on a Post which is proportional
to his need.
Pre-conditions Trader accesses the Forum and find a Post that is pro-
portional to his need.
Nominal Sce-
nario 1. Trader chooses post that he will comment on it.
2. Trader writes his comment.
3. Trader submits his comment.
Post-conditions Trader’s comment is published.
Table 3.12: Textual description of the « Comment on Post » use case
PFE- Ala Harabi 43

A textual explanation of the « Comment on Post » use case for the ”Trader” actor can
be found in Table 3.12 The nominal scenario is described.
3.6.3 Conception
of sequence diagrams and the class diagram.
3.6.3.1 Sequence system diagrams
Figure 6.3.20: Sprint 5 - « Post on Forum » sequence diagram
PFE- Ala Harabi 44

Figure 6.3.21: Sprint 5 - « Comment on Post » sequence diagram
Figure 6.3.21 depicts the class diagram that we used to develop the fifth sprint of Re-
lease1
PFE- Ala Harabi 45

3.6.3.2 Class Diagram
Figure 6.3.22: Sprint 5 - « Comment on Post » sequence diagram
these classes.
PFE- Ala Harabi 46

Figure 6.4.23: Sprint 5 - Interface « Post on Forum »
Figure 6.4.24: Sprint 5 - Interface « Comment on Post »
3.7 Sprint 6: « Consult Trading Bot »
In this section, we start by outlining the organisation and backlog for the sixth sprint «
Consult Trading Bot». The analysis stage and the conceptual solution are then pre-
sented. The numerous implementations are then illustrated.
PFE- Ala Harabi 47

3.7.1 Organisation
A thorough breakdown of the Backlog for the sixth sprint supporting the « Consult
Trading Bot » functionality can be seen in Table 3.13.
6.1 Design and implement the user interface for
the Trading Bot.
3
6 Consult
Trading
Bo
6.2 Establish a connection between the plat-
form and the trading bot module.
3
6.3 Test the “Consult Trading Bot” functionality. 1
Table 3.13: Backlog for Sprint 6: « Consult Trading Bot»
3.7.2 Analysis
- Refinement of the use case for « Consult Trading Bot »
The « Consult Trading Bot » use case refinement is shown in Figure 7.2.25.
PFE- Ala Harabi 48

Figure 7.2.25: Sprint 6 - « Consult Trading Bot » use case diagram
CU name « Consult Trading Bot »
Actor Trader
Summary The trader Consult the Trading Bot to benefit their recom-
mendations and advice.
Pre-conditions The Trader accesses to the Trading Bot section.
Nominal Sce-
nario 1. Trader clicks on “Trading Bot” button.
2. The system displays a chat.
3. The Trader enter specific criteria and preferences.
4. Based on the analysis, the Trading Bot gives an esti-
mation and advice.
5. The Trader follow the Bot’s instructions to execute the
trade manually.
Alternative se-
quences
4.1. The criteria entered by the Trader is not clear: starts at
Post-conditions Trader can make Transactions.
Table 3.14: Textual description of the « Consult Trading Bot » use case
A textual explanation of the « Consult Trading Bot » use case for the ”Trader” actor
can be found in Table 3.14. Both the nominal scenario and the alternate steps are
PFE- Ala Harabi 49

described.
3.7.3 Conception
of the sequence diagram, the class diagram and interaction diagram.
3.7.3.1 System Sequence Diagram
Figure 7.3.26: Sprint 6 - « Consult Trading Bot » Sequence diagram
PFE- Ala Harabi 50

Figure 7.3.27: Sprint 6 - « Consult Trading Bot » Class diagram
Figure 7.3.27 depicts the class diagram that we used to develop the sixth sprint of Re-
lease1
these classes.
human-machine interface.
PFE- Ala Harabi 51

Figure 7.4.28: Sprint 6 - Interface « Consult Trading Bot »
3.8 Sprint 7: « Consult Tutorials »
In this section, we first present the organisation and Backlog of the seventh sprint, «
Consult Tutorials ». Next, we present the analysis phase and the conceptual solution.
Finally, the various implementations are illustrated.
3.8.1 Organisation
Table 3.15 gives a detailed overview of the Backlog for the seventh sprint that supports
the « Consult Tutorials » functionality.
7 Consult
Tutorial
7.1 Creation of Tutorials interfaces. 2
7.2 Testing « Consult Tutorials » functionality. 2
Table 3.15: Backlog for sprint 7: « Consult Tutorials ».
3.8.2 Analysis
In this step, we describe the « Consult Tutorials » functionality and its use case.
- Refinement of the « Consult Tutorials » use case
PFE- Ala Harabi 52

Table 3.16 provides a textual description of the « Consult Tutorials » use case. It details
CU name « Consult Tutorials »
Actor Trader
Summary The Trader consults Tutorials to learn more about cryptocur-
rency and trading.
Pre-conditions Trader must authenticate.
Nominal Sce-
nario 1. Trader accesses to the Tutorials menu.
2. The system displays various tutorials.
3. Trader open one of them and begin learning.
Table 3.16: Textual description of the « Consult Tutorials » use case.
3.8.3 Conception
of the sequence diagram and the class diagram.
- « Consult Tutorials» system sequence diagram
PFE- Ala Harabi 53

Figure 8.3.29 shows how the user interacts with the system to consult the tutorial.
Figure 8.3.29: Sprint 7 - « Consult Tutorials » Sequence diagram
Figure 8.3.30 depicts the class diagram that we used to develop the seventh sprint of
Release1
PFE- Ala Harabi 54

Figure 8.3.30: Sprint 7 - « Consult Tutorials » Class diagram
human-machine interface.
Figure 8.4.31: Sprint 7 - Interface « List of Tutorials »
PFE- Ala Harabi 55

3.9 Conclusion
During this release, we have completed the analysis, conceptual study, and implemen-
tation of the «Register», «Consult Guide», «Manage his account», « Realize Trading
transactions », « Post on forum », « Consult trading-bot » and « Consult tutorials »
sprints. In the next chapter, we will complete the second release.
PFE- Ala Harabi 56

Chapter 4
Release 2: « Admin »
Summary
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.2 Sprint 8: « Manage accounts » . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.2.1 Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.2.2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.2.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.2.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.3 Sprint 9: « Manage posts » . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.3.1 Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.3.2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.3.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.3.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.4 Sprint 10: « Manage tutorials » . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.4.1 Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.4.2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.4.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.4.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
57

CHAPTER 4. RELEASE 2: « ADMIN »
4.1 Introduction
The second release, which supports the «Manage accounts», «Manage posts» and
«Manage tutorials» sprints are all covered in full in this chapter. We present the orga-
nization and its Backlog for each sprint. Thereafter, we provide the conceptual solution
and analysis phase, laying out the many diagrams that depict how the actors interact
with the system. Finally, we showcase the implementation via the interfaces.
4.2 Sprint 8: « Manage accounts »
In this section, we outline the organisation and backlog for the seventh sprint « Manage
accounts». Then, we present the analysis stage and the conceptual solution. The
numerous implementations are also illustrated.
4.2.1 Organisation
A thorough breakdown of the Backlog for the seventh sprint supporting the « Manage
accounts» functionality can be seen in Table 4.1.
8 Manage
accounts
8.1 Development of Manage account interfaces 3
8.2 Testing the block, update and delete of the
Trader’s account.
1
Table 4.1: Backlog for Sprint 8: « Manage accounts»
4.2.2 Analysis
PFE- Ala Harabi 58

- Refinement of the use case for « Manage accounts »
The « Manage accounts» use case refinement is shown in Figure 4.1.
Figure 2.2.1: Sprint 8 - « Manage accounts» use case diagram
PFE- Ala Harabi 59

CU name « Manage accounts »
Actor Admin
Summary The Admin has access to delete, block, or update
Trader accounts.
Pre-conditions The Admin accesses the Admin dashboard by authen-
tication
Nominal Sce-
nario
Scenario 1: Modify Account
1. The admin navigates to the « Manage Traders
accounts » section.
2. He searches for the specific Trader account he
wishes to modify.
3. The admin selects the Trader account.
4. The system presents a form with editable fields.
5. The admin makes the necessary changes.
6. The admin submits the modifications.
7. The system updates the Trader account accord-
ingly.
Scenario 2: Delete Account
1. The admin navigates to the « Manage Traders
accounts » section.
2. He searches for the specific Trader account he
wishes to delete.
3. The admin selects the Trader account.
4. The system deletes the Trader account
Post-conditions Scenario 1: Modify Account
Trader account modified.
Scenario 2: Delete account
Trader account Deleted.
Table 4.2: Textual description of the « Manage accounts» use case
A textual explanation of the « Manage accounts» use case for the ”Admin” actor can be
found in Table 4.2. Both the nominal scenario and the post-conditions are described.
PFE- Ala Harabi 60

4.2.3 Conception
of sequence diagrams, the class diagram and activity diagram.
Figure 2.3.2: Sprint 8 - « Manage accounts»: “Update account” sequence diagram
PFE- Ala Harabi 61

Figure 2.3.3: Sprint 8 - « « Manage accounts»: “Delete account” sequence diagram
PFE- Ala Harabi 62

Figure 2.3.4 depicts the class diagram that we used to develop the eighth sprint of
Release2
Figure 2.3.4: Sprint 8 - « Manage accounts» Class diagram
4.2.3.3 Activity Diagrams
PFE- Ala Harabi 63

Figure 2.3.5: Sprint 8 - « « Manage accounts»: “Delete account” activity diagram
Figure 2.3.6: Sprint 8 - « Manage accounts»: “Update account” activity diagram
In this subsection, we present some activity diagrams provide a visual representation
of steps and actions in this use case.
Figure 2.4.7: Sprint 8- Interface « Manage accounts »1
PFE- Ala Harabi 64

Figure 2.4.8: Sprint 8- Interface « Manage accounts »2
4.3 Sprint 9: « Manage posts »
In this section, we start by presenting the organisation and Backlog of the eighth sprint
«Manage posts». We also present the analysis phase and the conceptual solution.
Lastly, we illustrate the various implementations.
4.3.1 Organisation
Table 4.3 gives a detailed overview of the Backlog for sprint 9 that supports the «
Manage posts » functionality.
9.1 Development of Manage posts interfaces. 3
9 Manage
posts
9.2 Testing the refuse and accept of the post. 1
9.3 Testing the delete of the post. 1
Table 4.3: Backlog for sprint 9: « Manage posts ».
PFE- Ala Harabi 65

4.3.2 Analysis
In this step, we describe the « Manage posts » functionality and its use case.
- Refinement of the use case for « Manage posts »
The « Manage posts » use case refinement is shown in Figure 3.2.9
Figure 3.2.9: Sprint 9 - ”Manage posts” use case diagram
PFE- Ala Harabi 66

Table 4.4 provides a textual description of the « Manage posts » use case. It details
CU name « Manage posts »
Actor Admin
Summary TThe admin has access to delete, accept, or refuse
posts.
Pre-conditions The admin authenticates and accesses to the dash-
board.
Nominal Sce-
nario
Scenario 1: Delete Post
1. The admin navigates to the « Manage Posts »
section.
2. He searches for the specific post he wishes to
delete.
3. The admin selects the post.
4. The system deletes the post.
Scenario 2: Accept or refuse the post
1. The system sends a notification to the admin.
2. The admin checks the notification.
3. The admin clicks on “Accept” to accept a post or
“Refuse” to refuse a post.
Post-conditions Scenario 1: Delete Post
Post deleted.
Scenario 2: Accept or refuse the post
Post accepted or refused.
Table 4.4: Textual description of the « Manage posts » use case.
A textual explanation of the « Manage Posts » use case for the « Admin » actor can be
found in Table 4.4 Both the nominal scenario and the post-conditions are described.
4.3.3 Conception
of sequence diagrams, the class diagram and activity diagram.
PFE- Ala Harabi 67

Figure 3.3.10: Sprint 9 - « Manage posts »: ”Accept or refuse post” sequence diagram
Figure 3.3.11: Sprint 9 - « Manage posts » : ”Delete post” sequence diagram
PFE- Ala Harabi 68

Figure 3.3.12 depicts the class diagram that we used to develop the ninth sprint of
Release2
Figure 3.3.12: Sprint 9 - « Manage posts »: Class diagram
4.3.3.3 Activity Diagram
In this subsection, we present the activity diagram provide a visual representation of
steps and actions in this use case.
Figure 3.3.13: Sprint 9 - « Manage posts »: activity diagram
PFE- Ala Harabi 69

Following the analysis of sprint and the conception phase, this section illustrates the
Figure 3.4.14: Sprint 9 - Interface « Manage posts »1
Figure 3.4.15: Sprint 9 - Interface « Manage posts »2
4.4 Sprint 10: « Manage tutorials »
In this section, we start by presenting the organisation and Backlog of the sprint 10 «
Manage tutorials ». Then, we present the analysis phase and the conceptual solution.
PFE- Ala Harabi 70

Finally, we illustrate the various implementations.
4.4.1 Organisation
Manage tutorials » functionality.
10 Manage
tutorials
10.1 Development of «Manage tutorials» interfaces. 3
10.2 Testing the creation, delete and update of tutori-
als.
1
Table 4.5: Backlog for sprint 10: « Manage tutorials ».
4.4.2 Analysis
In this step, we describe the « Manage tutorials » functionality and its use case.
- Refinement of the use case for « Manage tutorials »
The « Manage tutorials » use case refinement is shown in Figure 4.2.16
Figure 4.2.16: Sprint 10 - «Manage tutorials» use case diagram
PFE- Ala Harabi 71

Table 4.6 provides a textual description of the « Manage tutorials » use case. It details
CU name « Manage tutorials »
Actor Admin
Summary The admin has access to create, update, or delete tutorials.
Pre-conditions The admin authenticates and accesses to the dashboard.
Nominal Sce-
nario
Scenario 1: Create tutorial
1. The admin navigates to the « Manage tutorials »section
2. The admin clicks on “Add” to create a new tutorial
4. The admin fills fields with the necessary information.
5. The admin submits the form.
6. The system updates the Trader account accordingly.
Scenario 2: Update tutorial
1. The admin navigates to the « Manage tutorials » section.
2. He searches for the specific tutorial he wishes to modify.
3. The admin selects the tutorial.
5. The admin makes the necessary changes.
6. The admin submits the modifications.
7. The system updates the tutorial accordingly.
Scenario 3: Delete tutorial
1. The admin navigates to the « Manage tutorials » section.
2. He searches for the specific tutorial he wishes to delete.
3. The admin selects the tutorial.
4. The system deletes the tutorial.
Post-conditions Scenario 1: Create tutorial
Tutorial created.
Scenario 2: Update tutorial
Tutorial updated.
Scenario3: Delete tutorial
Tutorial deleted.
Table 4.6: Textual description of the « Manage tutorials » use case.
A textual explanation of the « Manage tutorials » use case for the ”Admin” actor can be
found in Table 4.6 Both the nominal scenario and the post-conditions are described.
PFE- Ala Harabi 72

4.4.3 Conception
of the sequence diagram, the class diagram and activity diagram.
Figure 4.3.17: Sprint 10 - « Manage tutorials » sequence diagram
PFE- Ala Harabi 73

Figure 4.3.18 depicts the class diagram that we used to develop the tenth sprint of
Release2
Figure 4.3.18: Sprint 10 - « Manage tutorials » Class diagram
Following the analysis of sprint 10 and the conception phase, this section illustrates
the human-machine interfaces developed as part of this sprint.
Figure 4.4.19: Sprint 10- Interface « Manage tutorials »
PFE- Ala Harabi 74

4.5 Conclusion
tation of the « Manage accounts », « Manage posts » and « Manage tutorials » sprints.
At this stage, the admin can manage multiple functionalities in our platform.
PFE- Ala Harabi 75

Chapter 5
Release 3: « Trading Bot »
Summary
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.2 Sprint 10: « Analyse Cryptocurrency market » . . . . . . . . . . . . . . . . 77
5.2.1 Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.2.2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.2.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.3 Sprint 11: « Conclude estimation and give advice » . . . . . . . . . . . . . 80
5.3.1 Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.3.2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.3.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.3.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
76

CHAPTER 5. RELEASE 3: « TRADING BOT »
5.1 Introduction
The third release, which supports the «Analyze Cryptocurrency market» and « Con-
clude estimation and give advice » sprints are all mentioned in full in this chapter. We
present the organization and its Backlog for each sprint. Next, we provide the con-
ceptual solution and analysis phase, laying out the many diagrams that depict how
the actors interact with the system. Lastly, we illustrate the implementation via the
interfaces.
5.2 Sprint 10: « Analyse Cryptocurrency market »
In this section, we outline the organisation and backlog for the tenth sprint « Analyse
Cryptocurrency market ». Then, we present the analysis stage and the conceptual
solution. The numerous implementations are also illustrated.
5.2.1 Organisation
A thorough breakdown of the Backlog for the tenth sprint supporting the « Analyse
cryptocurrency market » functionality can be seen in Table 5.1.
10 Analyse
Cryptocur-
rency
10.1 Design and implement a module to retrieve
real-time data from various cryptocurrency
exchanges.
3
market 10.2 Develop algorithms to process and analyse
the retrieved market data.
5
Table 5.1: Backlog for Sprint 10: « Analyse cryptocurrency market »
5.2.2 Analysis
- Refinement of the use case for « Analyse cryptocurrency market »
PFE- Ala Harabi 77

The « Analyse cryptocurrency market » use case refinement is shown in Figure 2.2.1
Figure 2.2.1: Sprint 10 - « Analyse cryptocurrency market » use case diagram
CU name « Analyse cryptocurrency market »
Actor Trading Bot
Summary The Trading Bot will help trader to make decision by
analysing market.
Pre-conditions The Trader gives a specific criterion and send a re-
quest to the Trading Bot.
Nominal Sce-
nario 1. The Trading Bot receive the user inputs.
2. The Trading Bot connect to the market data and
clean it.
3. The Trading Bot evaluates the user’s criteria
against the market conditions.
Post-conditions The Data is analysed, and the result is saved.
Table 5.2: Textual description of the « Manage posts » use case.
PFE- Ala Harabi 78

A textual explanation of the « Analyse cryptocurrency market » use case for the ”Trad-
ing Bot” actor can be found in Table 5.2. Both the nominal scenario and the post-
conditions are described.
5.2.3 Conception
of the sequence diagram.
Figure 2.3.2: Sprint 10 - « Analyse cryptocurrency market » sequence diagram
PFE- Ala Harabi 79

5.3 Sprint 11: « Conclude estimation and give advice »
In this section, we start by presenting the organisation and Backlog of the sprint «
Conclude estimation and give advice ». We also present the analysis phase and the
conceptual solution. Finally, we illustrate the various implementations.
5.3.1 Organisation
Conclude estimation and give advice » functionality.
Conclude 11.1 Development of Estimation and advice in-
terfaces..
3
11 estimation 11.2 Develop algorithms to give estimations. 5
and give
advice
11.3 Testing the execute of the algorithm to give
estimation and advice.
2
Table 5.3: Backlog for sprint 11: « Conclude estimation and give advice »
5.3.2 Analysis
In this step, we describe the « Conclude estimation and give advice » functionality and
its use case.
- Refinement of the use case for « Conclude estimation and give advice».
PFE- Ala Harabi 80

The « Conclude estimation and give advice » use case refinement is shown in Figure
3.2.3. Table 5.4 provides a textual description of the « Conclude estimation and give
Figure 3.2.3: Sprint 11 - « Conclude estimation and give advice » use case diagram
advice » use case. It details the nominal scenario.
CU name Conclude estimation and give advice
Actor Trading Bot
Summary The Trading Bot will give the trader an estimation about
his demand and advise him.
Pre-conditions The Trading Bot analyse cryptocurrency market.
Nominal Sce-
nario 1. The Trading Bot generates accurate recommen-
dations.
2. The Trading bot provides clear instructions for
manual execution.
3. It gives advice to Trader.
Post-conditions The Trader receive recommendation.
Table 5.4: Textual description of the « Conclude estimation and give advice » use
case.
PFE- Ala Harabi 81

5.3.3 Conception
Figure 3.3.4: Sprint 11 - « Conclude estimation and give advice » sequence diagram
Following the analysis of sprint 11 and the conception phase, this section illustrates the
PFE- Ala Harabi 82

Figure 3.4.5: Sprint 11 – Interface « Conclude estimation and give advice »
5.4 Conclusion
tation of the « Analyse cryptocurrency market » and « Conclude estimation and give
advice » sprints. At this stage, the Trading Bot can help traders to make transactions
in the right way.
PFE- Ala Harabi 83

General conclusion and outlook
Our end-of-studies project entitled « CRYPTOPHILIA »: a “Cryptocurrency trading plat-
form” aims to design and develop an adaptive web solution to assist Traders make
transactions: buy and sell cryptocurrency and learn more about this domain. Addition-
ally, it enables admin to monitor and track posts and comments Traders. Besides, this
platform provides a trading bot to help traders.
To carry out this work, we began by understanding the general context of the project
and the various requirements of the future system. Subsequently, we analysed and
specified the functional and non-functional requirements. At the end of the first chap-
ter, we chose the most suitable methodology, namely ”KANBAN.”
In the second chapter, we specified the product backlog and planned the sprints. Then,
we presented the working environment, the development environment, and the global
use case diagram. Finally, we specified the backlog for each sprint and detailed our
conception through sequence diagrams, activity diagrams, and class diagrams. We
described our application through screenshots in three releases. This end-of-studies
project was a real opportunity for us to enhance our technical skills on one hand and
discover a new highly valuable profession on the other hand.
As for future perspectives, it is interesting to further refine the ergonomic aspect rather
than the functional aspect of ”CRYPTOPHILIA”. It would be more appropriate to en-
hance the ”Trading Bot” functionality by drawing inspiration from artificial intelligence.
In the long term, it could integrate other features related to Traders by Developing more
algorithms to facilitate trading transactions and more help them.
84

Bibliography
[1] In: https://fr.wikipedia.org/wiki/React ().
[2] In: ().
[3] In: https://fr.wikipedia.org/wiki/Node.js ().
[4] In: https://fr.wikipedia.org/wiki/Scrum-(développement) ().
[5] In: https://www.ideematic.com/actualites/2015/01/methodes-agiles-definition/ ().
[6] In: https://fr.wikipedia.org/wiki/TypeScript ().
[7] In: https://fr.wikipedia.org/wiki/Redux-(bibliothèque-JavaScript) ().
[8] In: https://en.wikipedia.org/wiki/Overleaf ().
[9] In: https://mui.com ().
[10] In: https://en.wikipedia.org/wiki/Figma-(software) ().
[11] In: https://code.visualstudio.com/docs ().
85

ala_harabi-4 presentation d une platform web

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie ala_harabi-4 presentation d une platform web

Ähnlich wie ala_harabi-4 presentation d une platform web (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

ala_harabi-4 presentation d une platform web