inventory management web and mobile applications (jee/ionic/angular)
TRANSCRIPT
Graduation Project Report 1 2015/2016
DEDICATION
I dedicate this report to my dear parents Abderrahim and Khadija who have always
been here for me throughout my studies and who gave me a wonderful model of labor and
perseverance. I hope that they find in this modest work all my gratitude and all my love.
To my dear professors who helped me climb every obstacle in my academic life, without their
continued support and counsel I would not have been writing these words right now.
To my dear supervisor who did not held from offering me his support and guidance
throughout my entire internship, without his presence I could not have completed this
process.
To the soul of my uncle who would have been the happiest person today may god preserve
him the merits of paradise.
To all my uncles and aunts to all my cousins to all my friends who have always believed in me
and cared for me. To all those I love and all those who love me.
Graduation Project Report 2 2015/2016
AKNOWLEDGEMENTS
An internship is not only a step added to the student's curriculum. It also reflects on a
person's choices in his professional life due to the constant interaction with his coworkers. I
take this opportunity to express my gratitude to the people who have been instrumental in
the successful completion of this project. I would like to show my greatest appreciation to
Mrs. EZZAHAR and Mr. EHLALI. I feel motivated and encouraged every time I attend my
internship. The guidance and support received from them was vital for the success of my
work. I am grateful for their constant support and help. I would like also to thank Mr.
BENTALEB for his valuable guidance and advice. I would also like to express my gratitude to
the jury members for the honor they've granted me to examine and evaluate this modest
contribution, and all of my professors at the National School of Applied Sciences for the
schooling and training they have given me and hopefully that this work will meet up to their
standards and expectations.
Graduation Project Report 3 2015/2016
ABSTRACT
The main goal of this project is to provide an interface to the Research and
development center of the OCP Group where they can manage their chemical products
inventory. To this end, we developed two types of applications: a web application and mobile
application, in order to satisfy the needs of users with different levels of IT expertise. One
application is implemented based on Jee technology with a server/client architecture and
frameworks such as Maven, Hibernate and Spring, the other is an hybrid application
implemented based on Ionic/Angular JS technologies. The chosen development methodology
is the agile software development due to its repeated cycles (iterative) and in smaller
development portions (incremental), allowing to test and review during development
benefiting in speed, lower cost, and flexibility.
Keywords: Ionic, Angular JS, API, JEE
Graduation Project Report 4 2015/2016
RESUME
L'objectif de notre projet est de concevoir et développer deux applications qui vont
être servies comme une interface utilisatrice pour le centre Innovation, Recherche et
Développement du Groupe OCP Jorf Lasfar. Ces applications vont gérer le stock des produits
chimiques, les fournisseurs, les commandes entrantes et les commandes sortantes des
produits. Elles permettront aux différents utilisateurs, à savoir le magasinier, le responsable
d’achat, et le responsable général de garder trace sur les mouvements et historiques de
l’inventaire, avoir accès aux fiches techniques et fiches de sécurité des produits chimique,
accéder aux informations concernant les fournisseurs et les localiser à partir de leurs
téléphones portables. La première application est une application web développée avec la
technologie Jee avec une architecture client/serveur avec les frameworks Maven, Hibernate
et Spring, la deuxième application est une application mobile hybride développée avec les
technologies Ionic/Angular JS. La méthodologie de travail adaptée est la méthode du
développement agile à cause de son agilité, son approche flexible et efficace et aussi de sa
définition des objectifs à court terme qui résulte à une pression constate sur les développeurs.
Mots-clés: Ionic, Angular JS, API, JEE, Application web, Application mobile
Graduation Project Report 5 2015/2016
CONTENT
Dedication 2
Acknowledgments 3
Abstract 4
Résumé 5
Introduction 11
1 General Context 12
1.1 Project motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2 Presentation of the host company . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.3 History of the host company. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.4 Group’s top management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15
1.5 Presentation of the Jorf Lasfar site. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16
1.6 Presentation of the Research and Development center. . . . . . . . . . . . . . . . . . . . . 16
1.7 R&D Center’s top management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17
1.8 Context of the project. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .17
1.8.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.8.2 Problem description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . .18
1.8.3 Expected results. . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2 Project Management 19
2.1 Software development methodology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2 Forward planning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..21
2.2.1 Project timeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 21
2.2.2 Gantt chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3 Actual planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . 24
3 Requirement Analysis and Specifications 27
3.1 Existing solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2 Beast Horn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28
3.3 Free market solutions comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28
Graduation Project Report 6 2015/2016
3.4 Identifying actors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.5 Informal requirements specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..30
3.5.1 Nonfunctional requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.5.2 Functional requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.5.2.1 Storekeeper. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.5.2.2 Supply Manager. . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31
3.5.2.3 General Manager. . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31
3.6 Use Case diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31
3.6.1 System administration Use Case. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32
3.6.2 Storekeeper Use Case. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.6.3 Supply Manager Use Case. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.6.4 General Manager Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.7 Sequence diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34
3.8 Class diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35
4 Workspace environment 37
4.1 Workspace environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37
4.1.1 Hardware environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.1.2 Software environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.1.2.1 Web application . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
A. Programming language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
B. Development tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
C. Application architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
D. Project structure . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.1.2.1 Mobile application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
A. Native vs. Hybrid application development approach . . . . . . . . .45
B. Development tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . 47
C. Application architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
D. Project structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..51
5 Achievements 52
5.1 Workspace environment . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.1.1 Web application . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.1.1.1 Authentication interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52
5.1.1.2 Products’ management interface . . . . . . . . .. . . . . . . . . . . . . . . . . . . 53
5.1.1.3 Product categories’ management interface . . . . . . . . . . . . . . . . . . ..53
5.1.1.4 Suppliers’ management interface . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54
5.1.1.5 Employees’ management interface . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.1.1.6 Input orders’ management interface . . . . . . . . .. . . . . . . . . . . . . . . .56
5.1.1.7 Output orders’ management interface . . . . . . . . . . . . . . . . . . . . . . .58
5.1.1.8 Inventory management interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.1.1.8 Inventory chart interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Graduation Project Report 7 2015/2016
5.1.1.8 Reporting interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..60
5.1.2 Mobile application. . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . .61
5.1.2.1 Authentication interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61
5.1.2.2 Geolocation interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.1.2.3 Suppliers interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.1.2.3 Products technical and security sheets interface . . . . . . . . . . . . . . . 62
General Conclusion 64
Glossary 65
Netography 66
Graduation Project Report 8 2015/2016
LIST OF FIGURES
1.1 OCP Group units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2 OCP at 1920. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.3 OCP at current time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15
1.4 OCP Group’s top management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.5 R&D center’s Top Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . 17
2.1 Waterfall diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2 Agile software Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20
2.3 Agile vs. Waterfall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 20
2.4 Agile vs. Waterfall statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21
2.5 Scheduled project plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.6 Forward planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . 23
2.7 Actual planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . 25
3.1 Beast Horn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3 Administrator Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . 32
3.4 Storekeeper Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . 32
3.5 Supply Manager Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.6 General Manager Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.7 Sequence diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.8 Class diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.1 Spring Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2 Application architecture. . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3 Web application structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . 45
4.4 Native vs. Hybrid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.5 Angular JS structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.6 Stack Overflow Developer Survey 2015. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.7 Cordova structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.8 Ionic supported technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.9 Mobile application structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.10 Mobile application project structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.1 Authentication interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.2 Adding a product interface . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.3 List of products interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.4 Adding a product’s category interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Graduation Project Report 9 2015/2016
5.5 List of categories interface . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.6 Adding a supplier interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.7 List of suppliers interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . 55
5.8 Adding an employee interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.9 List of employees interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.10 Adding an input order interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.11 list of input orders interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.12 Adding an output order interface. . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . 58
5.13 List of output orders interface. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.14 Inventory interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . 59
5.15 Inventory chart interface. . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . 60
5.16 Reporting interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . 60
5.17 Mobile App authentication interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.18 Geolocation interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.19 Mobile App suppliers interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.20 Suppliers Geolocation interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . .62
5.21 Products forms interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.22 Products sheets interface. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . .. . . . 63
Graduation Project Report 10 2015/2016
LIST OF TABLES
3.2 Market solutions comparison . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Graduation Project Report 11 2015/2016
INTRODUCTION
An inventory management tool is known as a recommended or even an essential tool
to any successful business, and it’s even more important when you have an inventory
composed of chemical products that you need to keep track on their spans and environment
conditions. I was a bit surprised that the Research and Development department of OCP did
not have a computerized system that manage all the inventory inputs and outputs, all the
orders coming in and out of the inventory were managed by hand which leaded to an non
organized warehouse, a higher cost and a low efficiency and productivity.
The project consists in the implementation of a User Interface tools to be served as an aid in
decision making. First, we will need to study and provide a detailed description about possible
features in our software after studying the existing management system in the Research and
Development department. Then, we will deal with the implementation of the solution
following the design proposed by the supervisor. Finally, we will have to test the tools to check
that it meets the initially fixed requirements.
In the first chapter, we will introduce the host company and go through its main highlights,
then we will present the project overview. Throughout the second chapter, we will explain
some important concepts in the inventory management in order to be able to understand the
following chapters. At the end we will specify the main features that will be implemented.
The third and the fourth chapters will explain respectively the architecture and the
implementation of our management tools. Finally we will conclude with the future prospects
of the project and some possible improvements which could be made in the future.
Graduation Project Report 12 2015/2016
CHAPTER 1
GENERAL CONTEXT
This chapter will introduce the general context of our work and our project motivation.
We will also be presenting the host company and then we will describe the goal of this project,
and the expected results.
1.1 Project motivation
I have always been fascinated by computer science in general and software
development in particular since a very young age, it became not just a job or another day for
me in the office, but a passion and an obsession, it started as curiosity and developed into a
way of thinking.
My first confrontation with this field was through hardware, learning how to fix things around
us from TV to refrigerators and of course computers. And once I learned how to code and
how to create from scratch my first software, I knew that this is what I want to do for the rest
of my life, I still remembers the satisfaction of it to this day, and as they say, the rest is history.
I want to take a moment to thank the National School of Applied Sciences in Kenitra for giving
me the opportunity to study and pursue my path there in computer science, without its help
I wouldn’t be one step away from becoming a software engineer.
1.2 Presentation of the host company
OCP Group has a special place in Morocco’s industrial history, as the leading global
exporter of phosphate ore, a market leader in phosphoric acid and a major player in solid
fertilizers. This leadership has been made possible by our long history and the 94 years of
experience accumulated since the formation of Office Chérifien des Phosphates in 1920. The
Chapter 1. General Context
Graduation Project Report 13 2015/2016
Company legally became the OCP Group in 1975 and a Limited Company named OCP SA in
January 2008.
With phosphate rock mining and processing as the main activities since OCP inception, it has
since become integrated across the entire phosphate value chain: from the production of
fertilizer to phosphoric acid to its derivative products.
It has grown from several hundred people at its creation and revenues of three million USD
to revenues of 59.4 billion MAD (2012), and nearly 24,000 employees.
Figure 1.1: OCP Group units
1.3 History of the host company
The development of OCP Group was marked by some great dates. Geologically,
there are:
1920: Creation of OCP Group.
1921: Start of underground mining of phosphate in the Khouribga region. First shipment from
the phosphate port of Casablanca.
Chapter 1. General Context
Graduation Project Report 14 2015/2016
1932: Beginning of the underground phosphate mining in Youssoufia zone.
1934: descent recipe 1 Youssoufia.
1942: Drying phosphates in furnaces with coal in Youssoufia. Creating a calcination unit in
Youssoufia.
1951: the era of open pit mining. Sidi Daoui mine in the region of Khouribga.
1965: Creation of Maroc Chimie.
1965: Extension of the open pit mining Merah Lahrach.
1965: Inauguration of the Chemical Plant Fire Safi by SM King Hassan 2.
1973: Creation of Morocco Phosphorus.
1976: Launch of the first center for research and development of OCP, the Cerphos.
1980: Launch of the mine Benguerir.
1984: Launch of the Jorf Lasfar platform.
1998: Start of production of purified phosphoric acid Emaphos on the Jorf Lasfar site.
1996-2004: Creation of several joint ventures: Indo Morocco Phosphorus (IMACID), Zuari
Morocco Phosphates (ZMPL), Morocco Euro Phosphorus (EMAPHOS), Pakistan Morocco
Phosphorus (PAKPHOS)
2000: Turning on the washing-flotation plant in Khouribga.
2006: Start of the new line DAP 850 000 t / year jorf Lasfar.
2007-2009: Launch of new urban centers in Khouribga and Benguerir: green Mine and green
city.
2008: OCP becomes a limited company.
2008: Inauguration by His Majesty King Mohammed VI of Morocco Pakistan factory
Phosphorus.
2009: Start of Bunge Morocco Phosphorus.
2010: Partnership with Jacobs Engineering Inc. and JESA creation, launch of 4 units of fertilizer
in Jorf Lasfar.
2011-2011: Opening of 2 representative offices in Brazil and Argentina. Starting several
industrial units (Laundry Merah Lahrach, STEP ....).
2011: Launch of a desalination plant seawater at Jorf Lasfar.
2014: Start of the programmed Slurry Pipeline project on the axis Khouribga-Jorf Lasfar over
a length of 235 km.
2019: Scheduled launch of the slurry pipeline between Benguerir, Youssoufia and Safi.
Chapter 1. General Context
Graduation Project Report 15 2015/2016
Figure 1.2: OCP at 1920 figure 1.3: OCP at current time
1.4 Group’s top management
The Group’s top management is structured in two levels:
General Management, in charge of designing and implementing the long-term
strategy and transformation of the Group. The General Management is composed of
the Chairman and CEO, and the Deputy CEOs.
Executive Vice Presidents, in charge of the operational management of the Group.
Figure1.4: OCP Group’s top management
Chapter 1. General Context
Graduation Project Report 16 2015/2016
1.5 Presentation of the Jorf Lasfar site
The Jorf Lasfar complex has three entities from which the Maroc Phosphore III unit was
created in 1986. With the construction of the Emaphos plant in 1997, in partnership with
Prayon (Belgium) and CFB (Germany), OCP ushered in a new era in the diversification of their
finished products through the production of a high value-added acid: purified phosphoric
acid. Two years later, the commissioning of Imacid, in partnership with the Indian Birla Group,
enabled them to increase their phosphoric acid production capacity by 25 percent at the Jorf
Lasfar site.
1.6 Presentation of the Research and Development center
With more than 170 researchers - including PhDs, engineers and high level technicians-
R&D at OCP fully covers the Group’s integrated industrial value chain, from geology to the
end products.
The main mission of R&D at OCP:
To drive innovation in the phosphate industry.
To develop new products and technologies, create value and support OCP Group
leadership.
To improve OCP’s operations, performance and enhance OCP technological capacity.
To implement world class R&D practices to serve a world class Group.
Chapter 1. General Context
Graduation Project Report 17 2015/2016
1.7 R&D Center’s top management
Figure 1.5: R&D center’s Top Management
1.8 Context of the project
In this section, we will, first, present the context of our internship, then we will describe
briefly our problem and finally we will conclude with the expected results.
1.8.1 Scope
This project is a graduation requirement for obtaining the engineering diploma at the
National School of Applied Science in Kenitra. It involves doing an internship at a company
within the last four to six months prior to graduation. Our internship was conducted in OCP
Jorf Lasfar and particularly in the Research and Development department, from February 1,
2016 to May 31, 2016.
Chapter 1. General Context
Graduation Project Report 18 2015/2016
1.8.2 Problem description
One of the main concerns at the Research and Development department in OCP were
how to conduct a better system in managing the chemical products warehouse, their
environment conditions and lifespans, the inputs and outputs orders coming in and out the
inventory, the suppliers and the employees . The current system is a manual and non-efficient
one, which leads to a low productivity and a higher cost.
1.8.3 Expected results
Our goal is to implement an interface that will allow R&D department users to manage
various resources. This interface will consist of two applications: a web application for
inventory management, input and output orders and a mobile application to keep track on
the suppliers contact information and geolocation.
Conclusion
In this chapter we tried to present the hosting company, its history and the context of
the project. The next chapter will be devoted for our software development methodology,
the different stages of our project development through a detailed timeline, the forward
planning, the actual planning and the gap between both of them.
Graduation Project Report 19 2015/2016
CHAPTER 2
PROJECT MANAGEMENT
"Failing to plan means planning to fail" quote by Benjamin Franklin.
In this chapter, the timeline of the project will be covered, it is a way of displaying the
project artifact which is the list of events in chronological order. It is an essential phase in any
project management, it allows to see the problems early by having an up-to-date schedule,
increase productivity by examining the sequence of tasks and the resources assigned, and let
us know when we are off track by monitoring the baseline schedule. In other terms, it allows
us to control the project instead of the project having control of us. We will also be covering
the chosen software development methodology and the reasons why we chose this particular
plan.
2.1 Software development methodology
A lot of possibilities were faced when choosing the software development
methodology, they have been limited to two, the most obvious choice is the waterfall
method, it is a linear sequential model that is most effective when the problem statement is
well defined and highly structured and all the requirements are known before the
commencement of the project, which is not the case in our situation.
Figure 2.1: Waterfall diagram
Chapter 2. Project Management
Graduation Project Report 20 2015/2016
The other choice was the agile model that suits our project because of the lack of a
well-defined software requirements specification document. The principles and values of
agile software development were formed as a way to help teams to break the cycle of process
inflation and mainly focus on simple techniques for achieving their goals. And by goals it
means deliver the highest possible value to employers and customers.
Figure 2.2: Agile software Development
The key is in agile technique compressing the five sequences of the conventional
software development method - called the Waterfall method - to a one-week cycle. It
manages to do this by developing a system through repeated cycles (iterative) and in smaller
portions (incremental), allowing us to test and review during development. Speed, lower cost,
and flexibility are key benefits.
Figure 2.3: Agile vs. Waterfall
Chapter 2. Project Management
Graduation Project Report 21 2015/2016
According to the 2012 CHAOS report from the Standish Group. “The agile process is
the universal remedy for software development project failure. Software applications
developed through the agile process have three times the success rate of the traditional
waterfall method and a much lower percentage of time and cost overruns.” (Page 25).
Figure 2.4: Agile vs. Waterfall statistics
2.2 Forward planning
2.2.1 Project timeline
From 2/1/16 To 2/25/16 : Scope
From 2/1/16 To 2/2/16 : Determine project scope
From 2/2/16 To 2/4/16 : Define Preliminary resources
From 2/5/16 To 2/25/16 : Angular mobile and Ionic training
From 2/25/16 To 4/28/16 : Sprint 1
From 2/26/16 To 3/12/16 : Analysis/Software Requirements
From 2/26/16 To 2/27/16 : Conduct needs analysis
From 2/28/16 To 3/1/16 : Draft preliminary software specifications
From 3/1/16 To 3/12/16 : Design
Chapter 2. Project Management
Graduation Project Report 22 2015/2016
From 3/1/16 To 3/8/16 : Develop prototype based on functional
specifications
From 3/9/16 To 3/12/16 : Incorporate feedback into functional
specifications
From 3/14/16 To 4/25/16 : Development
From 3/14/16 To 4/20/16 : Develop code
From 3/14/16 To 4/25/16 : Developer testing (primary debugging)
From 3/14/16 To 4/25/16 : Testing
From 3/14/16 To 4/20/16 : Develop unit test plans using product
specifications
From 3/14/16 To 4/25/16 : Develop integration test plans using
product specifications
From 3/16/16 To 4/25/16 : Training
From 4/25/16 To 4/26/16 : Deployment
From 4/26/16 To 4/28/16 : Post Implementation Review
From 4/29/16 To 5/31/16 : Sprint 2
From 4/29/16 To 5/5/16 : Analysis/Software Requirements
From 4/29/16 To 5/1/16 : Conduct needs analysis
From 5/1/16 To 5/5/16 : Draft preliminary software specifications
From 5/5/16 To 5/10/16 : Design
From 5/5/16 To 5/8/16 : Develop prototype based on functional
specifications
From 5/9/16 To 5/10/16 : Incorporate feedback into functional
specifications
From 5/10/16 To 5/20/16 : Development
From 5/10/16 To 5/20/16 : Develop code
From 5/14/16 To 5/20/16 : Developer testing (primary debugging)
From 5/14/16 To 5/24/16 : Testing
From 5/14/16 To 5/24/16 : Develop unit test plans using product
specifications
From 5/16/16 To 5/24/16 : Develop integration test plans using
product specifications
Chapter 2. Project Management
Graduation Project Report 23 2015/2016
From 4/29/16 To 5/30/16 : Training
From 5/30/16 To 5/31/16 : Deployment
From 5/31/16 To 5/31/16 : Post Implementation Review
From 3/16/16 To 5/27/16 : Documentation
From 3/02/16 To 6/01/16 : Pilot
Figure 2.5: Scheduled project plan
2.2.2 GANTT Chart
The figure below shows the steps we have to accomplish during the period of the
training which began on February, 3th 2015 and finishes on June, 12th 2016.
Figure 2.6: forward planning
Chapter 2. Project Management
Graduation Project Report 24 2015/2016
2.3 Actual planning
Given the lack of a precise and a well-defined software requirements specification
document, the requirements were vague and unexpected, and new charges were added as
we went along, which leaded to a gap between the forward planning and the actual one, in
consequence of that, the phase Scope which contains the Analysis/Software Requirements
and Angular mobile and Ionic training took more than expected.
From 2/1/16 To 3/10/16 : Scope
From 2/1/16 To 2/2/16 : Determine project scope
From 2/2/16 To 2/4/16 : Define Preliminary resources
From 2/5/16 To 3/10/16 : Angular mobile and Ionic training
From 3/10/16 To 5/10/16 : Sprint 1
From 3/10/16 To 3/20/16 : Analysis/Software Requirements
From 3/10/16 To 3/14/16 : Conduct needs analysis
From 3/14/16 To 3/20/16 : Draft preliminary software specifications
From 3/21/16 To 3/27/16 : Design
From 3/21/16 To 3/25/16 : Develop prototype based on functional
specifications
From 3/27/16 To 3/27/16 : Incorporate feedback into functional
specifications
From 3/27/16 To 5/14/16 : Development
From 3/27/16 To 5/14/16 : Develop code
From 4/10/16 To 5/14/16 : Developer testing (primary debugging)
From 4/10/16 To 5/14/16 : Testing
From 4/10/16 To 5/12/16 : Develop unit test plans using product
specifications
From 5/12/16 To 5/14/16 : Develop integration test plans using
product specifications
From 3/21/16 To 5/14/16 : Training
From 5/14/16 To 5/15/16 : Deployment
From 5/15/16 To 5/15/16 : Post Implementation Review
Chapter 2. Project Management
Graduation Project Report 25 2015/2016
From 5/15/16 To 6/4/16 : Sprint 2
From 5/15/16 To 5/17/16 : Analysis/Software Requirements
From 5/15/16 To 5/16/16 : Conduct needs analysis
From 5/16/16 To 5/17/16 : Draft preliminary software specifications
From 5/17/16 To 5/20/16 : Design
From 5/17/16 To 5/19/16 : Develop prototype based on functional
specifications
From 5/19/16 To 5/20/16 : Incorporate feedback into functional
specifications
From 5/20/16 To 6/30/16 : Development
From 5/20/16 To 5/30/16 : Develop code
From 5/24/16 To 5/30/16 : Developer testing (primary debugging)
From 5/24/16 To 6/1/16 : Testing
From 5/24/16 To 5/28/16 : Develop unit test plans using product
specifications
From 5/28/16 To 6/1/16 : Develop integration test plans using product
specifications
From 5/15/16 To 6/1/16 : Training
From 6/1/16 To 6/2/16 : Deployment
From 6/2/16 To 6/4/16 : Post Implementation Review
From 3/21/16 To 5/28/16 : Documentation
From 3/14/16 To 6/01/16 : Pilot
Figure 2.7: Actual planning
Chapter 2. Project Management
Graduation Project Report 26 2015/2016
Conclusion
In this chapter we tried to outline our software development methodology, the
different stages of our project development through a detailed timeline, the forward
planning, the actual planning and the gap between both of them. In support of this conclusion,
we’ll leave you with some words General Dwight David Eisenhower the 34th President of the
United States:
"In preparing for battle I have always found that plans are useless, but planning is
indispensable."
Which means that the gap between the forward planning and the actual planning can always
tend towards 0 but never equals it, but this doesn’t mean that planning should not be
performed, it is indispensable. The next chapter will be devoted for the theoretical study and
a comparison between the current solutions.
Graduation Project Report 27 2015/2016
CHAPTER 3
REQUIREMENTS ANALYSIS AND
SPECIFICATION
This phase is strongly bound to the preliminary study led previously. After having
provided some general context about the project, the schedule and the development
methodology, we will define in this chapter our project specification. At first, we are going to
study the current solution then identify our actors characteristics. Then we will present the
functional and non-functional requirements of the project. At the end, we will conclude this
chapter with use cases and general sequence diagrams.
3.1 Existing situation
Currently the input and output orders management of the R&D department is done
manually, each Excel file represents a bunch of orders coming in or out the inventory or
technical characteristics of a given product. Those files are processed, analyzed and
distributed by emails between employees. This practice based on Microsoft Excel software,
and the least we can say about it is that it has no right to exist in such a reputed company.
We can spot many inconvenient of the current system management such as:
Requires heavy and manual sorting.
Unencrypted and unsecured files.
No use of System Data Base Management.
Files incompatible for automated usage.
Serious time and productivity loss due to the mismanagement of the chemical
products lifespans inside the inventory.
Loss of important data due to the volume of papers involved.
Chapter 3. Requirements Analysis and Specification
Graduation Project Report 28 2015/2016
3.2 Beast horn
The beast horn is a functional analysis tool that turns the required needs into simple
functions in order to complete the product or service desired.
We often find that projects managers prefer to operate on already made open source
solutions without concretely analyses the particular needs to justify the project. Before
imposing a "How" or a solution, the project manager must turn to the users and / or applicants
first to identify by a structured manner the desired solution because any project only makes
sense if it satisfies its needs. It is therefore appropriate to express the needs and nothing but
the needs from the project launch. For this it is essential to ask the following three questions:
Figure 3.1: Beast Horn
3.3 Comparing free market solutions
According to Capterra.com, the most downloaded open-source inventory
management softwares of 2016 are:
Chapter 3. Requirements Analysis and Specification
Graduation Project Report 29 2015/2016
inFlow inventory: is a freeware related to trade inventory. This
freeware manages and tracks the inventory, purchase and sales.
With the help of this freeware small trade owners control and
organize their inventory in a better way, can input details about the
product, purchase and sales records, stock details and also generate various reports for
business correspondence.
odoo: is free for two users, when hosted online, but it jumps up after
that. However, if it’s installed and maintain the software in house,
Odoo is totally free. The software covers the standard warehousing, manufacturing, and sales
channels.
inFlow Odoo Our Apps
Input/output orders Movement history Products T/S sheets Suppliers management Report generation Dynamic charting R&D specific needs
Table 3.2: market solutions comparison
3.4 Identifying actors
Based on the kind of services and permissions offered to employees inside the R&D
department, three potential users can be identified:
Storekeeper who is responsible of the products inside the inventory and who can
trigger an intervention if needed.
Supply manager who is responsible of the input and output orders, the suppliers and
the interventions triggered by the storekeeper.
The general manager who can have all access in the application and can monitor all
activities.
Chapter 3. Requirements Analysis and Specification
Graduation Project Report 30 2015/2016
3.5 Informal requirements specification
3.5.1 Non Functional requirements
According to the international standard ISO/IEC 9126 a software must achieve these
quality factors:
Expandability and Maintainability: The expandability of software plays an important
role in the software's survival on market and is able to lengthen software's lifespan. It
is important that the upgrades are easy to install and that the source code is well
documented because it is not guaranteed that the developer of the software is also
the same person that carries out the upgrades.
Reliability: The system has to operate at all times as expected. It is of high importance
that the system does not crash. When an error occurs, then the system must realize
this and give the user an appropriate error message, then return to normal operating
conditions and wait for a new command. Usability: The arguments and options used
in command line interface must be easy to remember, significant and expectable.
Performance: The communication between the user interfaces and the database must
be transparent. The client's query shall be processed in less than one second.
User friendliness: The web user interface should allow users to effectively and
efficiently manage its resources and makes them feel comfortable while using the
interface.
3.5.2 Functional requirements
3.5.2.1 Storekeeper
The web application should allow the storekeeper to:
List the products in the inventory.
Add a product in the inventory database.
Update a product from the inventory database.
Delete a product from the inventory database.
Add a new products family
Update an existing products family
Chapter 3. Requirements Analysis and Specification
Graduation Project Report 31 2015/2016
Trigger an intervention.
Generate an intervention ticket.
The mobile application should also allow the Storekeeper to:
List the products technical and security sheets by code.
3.5.2.2 Supply Manager
The supply manager should have the same permissions as the Storekeeper and in
addition to that he can also:
List the suppliers.
Manage the suppliers (Add/Update/Delete/Sort/Search from the database).
Manage the purchase orders (Add/Update/Delete/Sort/Search from the database).
Manage the employees orders (Add/Update/Delete/Sort/Search from the database).
Manage intervention tickets.
Manage billings.
Generate reports
Monitor the inventory products charts
The mobile application should also allow the Supply Manager to:
List the suppliers contact information and track their location.
3.5.2.3 General Manager
The general manager should have all access in the application including the
storekeeper and supply manager permissions. He can also:
Manage user’s roles.
Manage user’s accounts.
Monitor user’s activities.
3.6 Use Case diagrams
In general, the aim of presenting a use case diagram is to structure user needs and
the related objectives of the system. We will start by presenting the system administration
use case then we will detail and refine the project actor use cases.
Chapter 3. Requirements Analysis and Specification
Graduation Project Report 32 2015/2016
3.6.2 System administration Use Case
The complete system administration is insured by the administrator who is the general
manager. He is in charge of controlling users’ access and managing all system features, this is
modeled by the following use case diagram:
Figure 3.3: Administrator Use Case
3.6.3 Storekeeper Use Case
The Storekeeper should be allowed to manage the products including adding new
products or updating an existing ones. Also, he should be allowed to manage the inventory
change and report a non- available product by triggering an intervention.
Figure 3.4: Storekeeper Use Case
3.6.4 Supplies Manager Use Case
The Supplies Manager should be allowed to manage the suppliers, adding new ones
and updating the existing ones, manage the purchase orders related to specific suppliers,
Chapter 3. Requirements Analysis and Specification
Graduation Project Report 33 2015/2016
manage the output orders related to specific employees and unites inside the R&D center,
and finally manage the interventions tickets coming in from the Storekeeper.
The inventory system is of course an automated system which will be updated automatically
after every input or output order.
Figure 3.5: Supply Manager Use case
3.6.5 General Manager Use Case
The General Manager will have access to every part of the application, he can manage
the products, the suppliers, the input and output orders, trigger interventions tickets and in
addition to that he can generate reports and export them as a PDF or XLS format, and dynamic
charts of products available in the inventory.
Figure 3.6: General Manager Use Case
Chapter 3. Requirements Analysis and Specification
Graduation Project Report 34 2015/2016
3.7 Sequence diagram
In order to represent the graphical representation of the interactions between the
actors and the system in a chronological order, there is no better way than a sequence
diagram.
The Storekeeper expresses his needs to the Supply Manager first, the Supply Manager enters
the needs to the PO by the supply entity, and after its validation he assigns a DA number to
it. If the order is a framework agreement, he adds the purchase order in the application data,
update the inventory and deliver the amount desired to the Storekeeper. If not, the DA goes
back to the purchasing unit via PO and wait for its validation by the commission for opening
technical bids and commercial offers, if it’s validated the Supplies Manager adds the purchase
order in the application data, update the inventory and deliver the amount desired to the
Storekeeper.
Chapter 3. Requirements Analysis and Specification
Graduation Project Report 35 2015/2016
Figure 3.7: Sequence diagram
3.8 Class diagram
This diagram represents the classes needed for the proper implementation and
functioning of the system, the users who have access to the application are grouped into
groups, each group has its privileges allowing its registered users to access the required
features. The Supplies Manager can add the purchase orders coming in from the suppliers,
Chapter 3. Requirements Analysis and Specification
Graduation Project Report 36 2015/2016
each purchase contains a designated product with the amount desired and the amount
coming in. Since the application can manage the output orders going to employees and
specific unites as well, each order contains a designated product with the amount desired.
Intervention tickets can also be triggered by the referred user when needed.
Figure 3.8: Class diagram
Conclusion
In this chapter we tried to present our project specifications. We studied the current
solution and compared ours to the free and popular solutions in the market then we identified
our actors’ characteristics, the functional and non-functional requirements and we concluded
with the sequence and use cases diagrams for a better understanding the projects needs and
specifications. The next chapter will be dedicated for the project’s workspace environment.
Graduation Project Report 37 2015/2016
CHAPTER 4
Workspace environment
In this chapter, the work during the project's period, the hardware environment, the
platforms and the technologies used in the development of our project will be presented,
beside the reasons behind every choice of technology used. We will also show how the web
and mobile applications look like from each actor perspective.
4.1 Workspace environment
4.1.1 Hardware environment
For the achievement of our project, we have worked on an ultra-book:
Operating system : Windows 8.1 Pro
RAM : 8 Go
CPU : Intel Core I7-4500U 1.80 GHz
Graphic card : Intel HD Graphics Family
4.1.2 Software environment
We tried in this project to work with the latest technologies in the market, not only
to facilitate the application maintenance as these tools have a great community of
developers, but also to address security problems because the old development tools are
often targeted by several hackers. Regarding the architecture, we have chosen to use a client-
server architecture to differentiate the back-end side of the front-end side, this architecture
offers several advantages such as the easy maintenance, the proper management of data and
files, the easy accessibility and security.
I tried to make the most of this experience by using the most recent technologies possible in
the market that will be listed below.
Chapter 4. Workspace environment
Graduation Project Report 38 2015/2016
4.1.2.1 Web application
A. Programming language
Choosing the right programming
language to use for a project is one of
the most major decisions a programmer
will make during the entire
development process. Based on many
factors that we will be outlining after, we chose Java Platform, Entreprise Edition (JEE).
Java technology is both a programming language and a platform. The Java programming
language is a high-level object-oriented language that has a particular syntax and style. A Java
platform is a particular environment in which Java programming language applications run.
The Java EE platform is built on top of the Java SE platform. The Java EE platform provides an
API and runtime environment for developing and running large-scale, multi-tiered, scalable,
reliable, and secure network applications.
B. Development tools
-Apache Maven project: Apache Maven is a
software project management and
comprehension tool. Based on the concept
of a project object model (POM), Maven can manage a project's build, reporting and
documentation from a central piece of information. Maven’s primary goal is to allow a
developer to comprehend the complete state of a development effort in the shortest period
of time. In order to attain this goal there are several areas of concern that Maven attempts
to deal with:
Making the build process easy
Providing a uniform build system
Providing quality project information
Providing guidelines for best practices development
Allowing transparent migration to new features
Chapter 4. Workspace environment
Graduation Project Report 39 2015/2016
-Hibernate: Hibernate is an Object-Relational
Mapping(ORM) solution for JAVA and it
raised as an open source persistent
framework created by Gavin King in 2001. It is a powerful, high performance Object-
Relational Persistence and Query service for any Java Application. Hibernate maps Java
classes to database tables and from Java data types to SQL data types and relieve the
developer from 95% of common data persistence related programming tasks. Hibernate sits
between traditional Java objects and database server to handle all the work in persisting
those objects based on the appropriate O/R mechanisms and patterns.
Supported databases by Hibernate:
HSQL Database Engine
MySQL that will be using in our project
PostgreSQL
Oracle
Microsoft SQL Server Database
Sybase SQL Server
Supported Technologies:
XDoclet Spring
JEE
Eclipse plug-ins
Maven
-Spring Framework: The Spring Framework is
an application framework and inversion of
control container for the Java platform. The
framework's core features can be used by any
Java application, but there are extensions for building web applications on top of the Java
EE platform. Although the framework does not impose any specific programming model, it
has become popular in the Java community as an alternative to, replacement for, or even
addition to the Enterprise JavaBeans (EJB) model. The Spring Framework is open source.
Chapter 4. Workspace environment
Graduation Project Report 40 2015/2016
The Spring Framework provides about 20 modules which can be used based on an application
requirement.
Figure 4.1: Spring Architecture
The Data Access/Integration layer in our web application consists of
The JDBC module which provides a JDBC-abstraction layer that removes the need to
do tedious JDBC related coding, plus the ORM module which provides integration
layers for popular object-relational mapping APIs, including JPA, JDO, iBatis and in our
case Hibernate.
The web layer in our project consists of The Web-MVC module that contains Spring's
model-view-controller (MVC) implementation for web applications.
There are few other important modules like The Test module which supports the
testing of Spring components with JUnit or TestNG frameworks.
-Spring Security: Spring Security is a framework that
focuses on providing both authentication and
authorization to Java applications. Like all Spring
projects, the real power of Spring Security is found in
how easily it can be extended to meet custom requirements. It provides:
Chapter 4. Workspace environment
Graduation Project Report 41 2015/2016
Comprehensive and extensible support for both Authentication and Authorization
Protection against attacks like session fixation, clickjacking, cross site request forgery,
etc
Servlet API integration
Optional integration with Spring Web MVC
-Apache Tomcat: often referred to as Tomcat, is
an open-source web server developed by
the Apache Software Foundation (ASF). Tomcat
implements several Java EE specifications
including Java Servlet, JavaServer Pages (JSP),Java
EL, and WebSocket, and provides a "pure Java" HTTP web server environment in
which Java code can run.
Apache Tomcat offers users a lot of flexibility when deploying web applications. Tomcat is
lightweight, and starts up in seconds, as opposed to the minutes it takes a stack-based Java
EE server to start, so traditional startup deployment is feasible. However, Tomcat also
supports a variety of hot deploymentoptions, allowing users to roll out new applications, or
even update existing ones, while the server is still running.
-MYSQL: MySQL is the world's most popular open
source database. With its proven performance,
reliability and ease-of-use, MySQL has become the
leading database choice for web-based
applications, used by high profile web properties
including Facebook, Twitter, YouTube, Yahoo! and many more.
The following list describes some of the important Features of MySQL Database Software.
Internals and Portability
o Works on many different platforms.
o APIs for C, C++, Eiffel, Java, Perl, PHP, Python, Ruby, and Tcl are available.
o Provides transactional and non-transactional storage engines.
Chapter 4. Workspace environment
Graduation Project Report 42 2015/2016
o The server is available as a separate program for use in a client/server
networked environment. It is also available as a library that can be embedded
(linked) into standalone applications. Such applications can be used in isolation
or in environments where no network is available.
Security
o A privilege and password system that is very flexible and secure, and that
allows host-based verification. Passwords are secure because all password
traffic is encrypted when you connect to a server.
Scalability and Limits
o Handles large databases. We use MySQL Server with databases that contain
50 million records. We also know of users who use MySQL Server with 60,000
tables and about 5,000,000,000 rows.
o Up to 64 indexes per table are allowed (32 before MySQL 4.1.2). Each index
may consist of 1 to 16 columns or parts of columns. The maximum index width
is 1000 bytes (500 before MySQL4.1.2). An index may use a prefix of a column
for CHAR, VARCHAR, BLOB, or TEXT column types.
-JasperReports: The JasperReports Library is the world's most
popular open source reporting engine. It is entirely written in
Java and it is able to use data coming from any kind of data source and produce pixel-perfect
documents that can be viewed, printed or exported in a variety of document formats
including HTML, PDF, Excel, OpenOffice and Word.
JasperReports is distributed under two licenses, an Apache-style license and the LGPL license.
Due to its flexible licensing, JasperReports is the perfect candidate to complete the reporting
features for any commercial or open-source application.
-JfreeChart: JFreeChart is a free 100% Java chart library that makes
it easy for developers to display professional quality charts in their
applications. JFreeChart's extensive feature set includes:
a consistent and well-documented API, supporting a wide range of chart types;
a flexible design that is easy to extend, and targets both server-side and client-side
applications;
Chapter 4. Workspace environment
Graduation Project Report 43 2015/2016
support for many output types, including Swing and JavaFX components, image files
(including PNG and JPEG), and vector graphics file formats (including PDF, EPS and SVG);
JFreeChart is open source or, more specifically, free sortware. It is distributed under the
terms of the GNU Lesser General Public Licence (LGPL), which permits use in proprietary
applications.
C. Application architecture
The architecture used in our project is a layered architecture, it is a very well-known
software development model, suitable to support enterprise-level client/server applications
by resolving issues like scalability, security, fault tolerance…
Figure 4.2: Application architecture
This type of architecture has many advantages such as:
Scalable: this is due to its capability of multiple tier deployment and the tier
decoupling it brought. For example, the data tier can be scaled up by database
clustering without other tiers involving. The web client side can be scaled up by load-
balancer easily without affecting other tiers.
Better and finer security control to the whole system: we can enforce the security
differently for each tier if the security requirement is different for each tier. For
example, business tier and data tier usually need higher security level than
Chapter 4. Workspace environment
Graduation Project Report 44 2015/2016
presentation tier does, then we can put these two high security tiers behind firewall
for protection
Better fault tolerance ability: for example, the databases in data layer can be
clustered for failover or load balance purpose without affecting other layers.
Independent tier upgrading and changing without affecting other tiers: in object-
oriented world, Interface-dependency implementation can decouples all layers very
well so that each layer can change individually without affecting other layers too
much. Interface-dependency means a layer depends on another layer by interfaces
only, not concrete classes. Also, the dependency of a layer only on its directly-below
layer also minimizes the side effect of a layer’s change on the whole system. For
example, if keep the interfaces unchanged, we can update or replace the
implementation of any layer independently without affecting the whole system.
Friendly and efficient for development: the decoupled layers are logic software
component groups mainly by functionality, they are very software development
friendly and efficient. Each layer can be assigned individually to a team who specializes
in the specific functional area; a specialized team can handle the relevant task better
and more efficiently.
Friendly for maintenance: N-Tier architecture groups different things together mainly
by functionality and then makes things clear, easily understandable and manageable.
Friendly for new feature addition: due to the logical grouped components and the
decoupling brought by N-Tier architecture, new features can be added easily without
affecting too much on the whole system.
Better reusability: this is due to the logically grouped components and the loose
couplings among layers. Loosely-coupled component groups are usually implemented
in more general ways, so they can be reused by more other applications.
D. Project structure
The following configuration approaches are used in our project:
Spring MVC: Annotations for controller and XML for bean definitions.
Hibernate: XML mapping for model class.
Web Application: using web.xml deployment descriptor file.
Chapter 4. Workspace environment
Graduation Project Report 45 2015/2016
The following technologies and pieces of software are used throughout this project:
Java 8
Spring framework 4.24.RELEASED
Hibernate Entity Manager 5.1.0 Final
Spring Tool Suite IDE 4.2.4
Maven 4.0.0
Tomcat 8.0
Figure 4.3: Web Application structure
4.1.2.2 Mobile application
A. Native vs. Hybrid application development approach
Chapter 4. Workspace environment
Graduation Project Report 46 2015/2016
A native application is a mobile application developed specifically for a mobile operating
system (Java for Android vs. Swift for iOS). Since the app is developed within a mature
ecosystem following the technical and user experience guidelines of the OS (e.g. swipes, app
defined gestures, left aligned header on Android, centrally aligned header on iOS, etcetera),
it not only has the advantage of faster performance but also “feels right”. What feeling right
means is that the in-app interaction has a look and feel consistent with most of the other
native apps on the device. The end user is thus more likely to learn how to navigate and use
the app faster. Finally, native applications have the significant advantage of being able to
easily access and utilize the built-in capabilities of the user’s device (e.g., GPS, address book,
camera, etcetera). When a user sends text messages, takes pictures using the device’s default
app, set reminders, or uses the device’s music app (the one that came with the phone),
they’re using native apps In short, native apps are exactly that, native to the user’s OS and
hence built per those guidelines.
Hybrid are HTML5 applications packaged into a native wrapper. They look and feel like a
native app, but ultimately outside of the basic frame of the application (typically restricted to
the controls/navigational elements) they are fueled by a company’s website. Basically, a
hybrid app is a web app built using HTML5 and JavaScript, wrapped in a native container which
loads most of the information on the page as the user navigates through the application
(Native apps instead download most of the content when the user first installs the app). Usual
suspects here are Facebook, Twitter, Instagram, your mobile banking app, etcetera.
Figure 4.4: Native vs. Hybrid
Chapter 4. Workspace environment
Graduation Project Report 47 2015/2016
According to the TechValidate survey of 177 users of OutSystems 64% of surveyed IT
organizations intend on using hybrid architecture in 2015. After that being said, we may
conclude that the hybrid development approach is a better choice due to its popularity and
ease in deployment across multiple platform and it is the cheaper and faster solution.
B. Developpement tools
-AngularJS: (commonly referred to as "Angular" or "Angular.js") is an open-source web
application framework mainly maintained by Google and
by a community of individuals and corporations to
address many of the challenges encountered in
developing single-page applications. It aims to simplify
both the development and the testing of such
applications by providing a framework for client-side
model–view–controller (MVC) and model–view–view model (MVVM) architectures, along
with components commonly used in rich Internet applications.
The AngularJS framework works by first reading the HTML page, which has embedded into it
additional custom tag attributes. Angular interprets those attributes as directives to bind
input or output parts of the page to a model that is represented by standard JavaScript
variables. The values of those JavaScript variables can be manually set within the code, or
retrieved from static or dynamic JSON resources.
Figure 4.5: AngularJS structure
Chapter 4. Workspace environment
Graduation Project Report 48 2015/2016
The model: is the data shown to the user in the view and with which the user interact.
The directives: extend HTML with custom attributes and elements.
The controllers: the business logic behind views.
The services: reusable business logic independent of views.
The filters: formats the value of an expression for display to the user.
-Node.JS: Node.js, often called simply "Node" in
conversation, is a development platform built on top
of Google's V8 JavaScript virtual machine. While
JavaScript engines (including V8) are traditionally
run in Web browsers to form the client side of a
client/server application, the Node.js libraries are
focused on building server-side applications in JavaScript.
Node.js is intended to run on a dedicated HTTP server and to employ a single thread with one
process at a time. Node.js applications are events-based and run asynchronously. Code built
on the Node platform does not follow the traditional model of receive, process, send, wait,
receive. Instead, Node processes incoming requests in a constant event stack and sends small
requests one after the other without waiting for responses.
Figure 4.6: Stack Overflow Developer Survey 2015
Chapter 4. Workspace environment
Graduation Project Report 49 2015/2016
According to the Stack Overflow Developer Survey 2015, a 34-question long survey
reached 250 developers. Here’s the first interesting fact: 247 out of 250 use Node.js regularly
in 52 countries.
-Apache Cordova: formerly called as Phone Gap is a platform
to build Native Mobile Applications using HTML5, CSS and Java
Script.
In other words it acts like a container for running a web
application written in HTML, CSS, JS Typically Web applications
cannot use the native device functionality like Camera, GPS,
Accelerometer, Contacts etc. . With Cordova we can very much
achieve this and package the web application in the devices installer format.
Technically the User Interface of a Cordova Application is effectively a WebView that occupies
the complete screen and runs in the native Container. So, it is the same web view that is used
by the Native Operating systems. This purely means that only the Native Containers changes
according to the OS and internally the web pages remain the same. (Since the browser
rendering of webpages are different for each operating systems). UIWebView class for IOS,
android.webkit.webview for Android and WebViewClass for Windows Phone or other
platforms.
Figure 4.7: Cordova Architecture
Chapter 4. Workspace environment
Graduation Project Report 50 2015/2016
The previous figure demonstrates the architecture of Apache Cordova. It supports and
interacts with various device-specific APIs and combining the essence of all native APIs in one
JavaScript API that is accessible by the hybrid app. Hybrid apps are running inside a WebView
which is controlled by the Cordova framework. This is a complicated job considering the
amount of platforms out in the wild.
-Ionic Framework: Ionic is a complete open-source SDK for hybrid
mobile app development. Built on top of AngularJS and Apache
Cordova, Ionic provides tools and services for developing hybrid
mobile apps using Web technologies like CSS, HTML5, and Sass.
Apps can be built with these Web technologies and then
distributed through native app stores to be installed on devices by
leveraging Cordova. Ionic was created by Max Lynch, Ben Sperry, and Adam Bradley of Drifty
Co. in 2013.
Figure 4.8: Ionic supported technologies
C. Application architecture
Our app sits in inner square of Ionic / AngularJs since we build the app using these both
frameworks. Ionic uses ngcordova underneath to build and emulate the specific platform app.
Apache Cordova is set of APIs which will help us access native functions of iOS or Android
platform. And it's all wraped around node js wich obviously will be installed first.
Figure 4.9: Mobile app architecture
Chapter 4. Workspace environment
Graduation Project Report 51 2015/2016
D. Project structure
Inside of the folder that was created after the creation of our project, we have a typical
Cordova project structure where we can create platform-specific project files and install
native plugins. The bulk of our application lives inside the www folder, and so we are going to
be busier there.
Figure 4.10: Mobile app project structure
Conclusion
In this chapter we tried to present the hardware environment, the platforms and the
technologies used in the development of our project and the reasons behind every choice of
technology used. We also presented both the web and mobile application architectures and
structures for a better understanding of the development phase. The next chapter will be
dedicated to the final results of our implementations with a collection of screenshots for both
applications.
Graduation Project Report 52 2015/2016
CHAPTER 5
ACHIEVEMENTS
5.1 Overview of the achieved work
In this chapter, final results of our implementation will be presented. We will present
both our applications interface through a collection of screenshots and comments.
*Due to confidential reason, R&D center suppliers’ data couldn’t be implemented in the
application screenshot.
5.1.1 Web application
5.1.1.1 Authentication interface
As I stated before, the project consists of several roles therefore several interfaces
and abilities for each of these roles. But the authentication interface is unique.
This interface allows the Storekeeper, Store Manager and General Manager to access the
application by entering their confidentials which are their login and their password.
Figure 5.1: Authentication interface
Chapter 5. Achievements
Graduation Project Report 53 2015/2016
5.1.1.2 Products’ management interface
The product management interface is allowed to all roles and users, it is where the
Storekeeper adds a new product to the list of products, every product is characterized by its
code, name, picture, packaging and its category of products. He can also update or delete the
existing products.
Figure 5.2: Adding a product interface
Figure 5.3: List of products interface
5.1.1.3 Product categories’ management interface
The product categories management interface is allowed also to all roles and users, it
is where the Storekeeper updates, deletes or adds a new category of products, it is
characterized by its name, description and its picture.
Chapter 5. Achievements
Graduation Project Report 54 2015/2016
Figure 5.4: Adding a product’s category interface
Figure 5.5: List of categories interface
5.1.1.4 Suppliers’ management interface
The suppliers’ management interface is allowed to the Supply Manager and the
General Manager, each supplier is characterized by its name, email, phone number, address,
city and country. It is an indispensable step in the process of the application’s workflow, the
Supply manager cannot enter an input order without the existence of the appropriate supplier
in the application database.
Chapter 5. Achievements
Graduation Project Report 55 2015/2016
Figure 5.6: Adding a supplier interface
Figure 5.7: List of suppliers interface
5.1.1.5 Employees’ management interface
The employees’ management interface is allowed to the Supply Manager and the
General Manager, each employee is characterized by its full name, phone number, email and
it’s picture. It is also an indispensable step in the process of the application’s workflow, the
Supply manager cannot enter an output order without the existence of the appropriate
employee or unit in the application database.
Chapter 5. Achievements
Graduation Project Report 56 2015/2016
Figure 5.8: Adding an employee interface
Figure 5.9: List of employees interface
5.1.1.6 Input orders’ management interface
The input orders management interface is allowed to both the Supply Manager and
General Manager, each input order is characterized by its supplier, the product purchased, its
ACC number, order call number, measurement unit, amount of the delivery, unit price,
quantity requested, quantity received, approval state, date of requirement and date of
receipt. An input order cannot be entered unless the product purchased and its supplier are
already in the database, which can be done in their specific interfaces.
Chapter 5. Achievements
Graduation Project Report 57 2015/2016
Figure 5.10: Adding an input order interface
Figure 5.11: list of input orders interface
Chapter 5. Achievements
Graduation Project Report 58 2015/2016
5.1.1.7 Output orders management interface
The output orders management interface is allowed to both the Supply Manager
and General Manager, each input order is characterized by its entity, the product required,
its BR number, measurement unit, amount of the delivery, quantity requested, quantity
received, date of requirement and date of receipt. An output order cannot be entered unless
the product required and the entity requiring the product are already in the database, which
can be done in their specific interfaces also.
Figure 5.12: Adding an output order interface
Figure 5.13: List of output orders interface
Chapter 5. Achievements
Graduation Project Report 59 2015/2016
5.1.1.8 Inventory management interface
The inventory management interface is allowed to all users, it’s where the user can
keep track of the inventory, the list of the products inventory contains their codes, names,
packaging, available quantity, unit price and expiration date.
Figure 5.14: Inventory interface
5.1.1.9 Inventory Chart interface
The inventory chart interface is a dynamic pie chart realized by Jfreechart to keep track
on the products quantities, it changes automatically after any inventory movements. The
charting functionality in any application not just ours eases the understanding of large
quantities of data and the relationships between parts of the data. Charts can usually be read
more quickly than the raw data that they are produced from.
Chapter 5. Achievements
Graduation Project Report 60 2015/2016
Figure 5.15: Inventory chart interface
5.1.1.10 Reporting interface
The user can generate and export dynamic reports as pdf or xls formats from the
application by Jasper Reports, due to its large community and universal uses, Jasper Reports
is by far the best free reporting tool in the market.
Figure 5.16: Reporting interface
Chapter 5. Achievements
Graduation Project Report 61 2015/2016
5.1.2 Mobile application
5.1.2.1 Authentication interface
The authentication interface in the mobile application is more for security and
confidential reasons than to separate roles. It is used so that even if an outsider uses the
application he cannot have access to the confidential data stored.
5.1.2.2 Geolocation interface
The geolocation interface is where the user locates its current geographic location,
latitude and longitude, and track his path if he is changing locations by markers. This service
is provided by Google Maps JavaScript API, it retrieves data from Google Maps and embeds
them into our application, since our application is not for commercial uses, and will not
exceed 25 000 map loads per day for 90 consecutive days. According to the Google Maps APIs
terms of service, it is free to use.
Figure 5.17: Mobile App authentication interface Figure 5.18: Geolocation interface
5.1.2.3 Suppliers interface
The suppliers interface is where all the suppliers’ data are stored, each supplier is
characterized by its name, email, phone number, address, city and country. The user can also
show each of the suppliers’ geographic location.
Chapter 5. Achievements
Graduation Project Report 62 2015/2016
*Due to confidential reason, R&D center suppliers’ data couldn’t be implemented in the
application screenshot.
Figure 5.19: Suppliers geolocation interface Figure 5.20: Mobile App suppliers interface
5.1.2.3 Products technical and security sheets interface
This interface is where the user can have access to the products technical and security
sheets by entering the specific product’s code. It is accessible by authentication due to
confidentiality reasons. It transfers the user then to an interface composed of two frames
loaded in the server, each one is for a specific type of sheet.
Chapter 5. Achievements
Graduation Project Report 63 2015/2016
Figure 5.21: Products forms interface Figure 5.22: Products sheets interface
Conclusion
In this final chapter, most of the web and mobile applications’ interfaces were
subsequently presented, with an explanation of how the users interacted with each one.
These interfaces are the results of many models that were studied and approved in the design
phase.
Graduation Project Report 64 2015/2016
GENERAL CONCLUSION
Along this report, I presented different steps of my internship inside OCP’s Research
and Development Center in JORF LASFAR, I definitely learnt a lot during this experience, and
it has been a wonderful step up in my career.
Just like it was stated before, the Research and Development Center of OCP did not have a
computerized system that manage all the inventory inputs and outputs, all the orders coming
in and out of the inventory were managed by hand which leaded to an non organized
warehouse, a higher cost and a low efficiency and productivity. The risk and drawbacks are
more important because the inventory is composed of chemical products that need to be
tracked on.
The first chapter was devoted to the general context of the project and its motivation. The
host company was presented beside the goal of the project and the expected results. The
second chapter was devoted to the timeline of the project, the chosen software development
methodology and the reasons behind that particular plan. The third chapter explained the
project specification, it contains a study of the current solution and a comparison between
two of the best free open-source market solutions and an identification of the actors
characteristics, the chapter was concluded by the functional and non-functional
requirements. The fourth chapter is all about the hardware and software environment, the
platforms and the technologies used in the development phase and the reasons behind every
choice made. The final chapter was devoted to the final results of the implementation, it
contains a collection of screenshots and comments of both the applications interfaces.
At the end of this internship, all the initial requirements were met and all the challenges had
been successfully overcome. However, the implemented applications are just considered as
a first release version. Many new features could be added later on like the mobile notification
system.
Graduation Project Report 65 2015/2016
GLOSSARY
A API Application Programming Interface
C CSS Cascading Style Sheets
H HTML Hyper Text Mark-Up Language
I IT Information Technology
J JEE Java Enterprise Edition
JS Java Script
O OCP Office Chérifien des Phosphates
R R&D Research and Development
Graduation Project Report 66 2015/2016
NETOGRAPHY
OCP Groups presentation. Consulted March 21st
[N1] http://Ocpgroup.ma
Development methods discussion. Consulted March 22nd
[N2] http://www.codeproject.com/Articles/604417
Agile vs. Waterfall statistics. Consulted March 24th
[N4] https://www.standishgroup.com/
Software quality factors. Consulted March 24th
[N5] https://en.wikipedia.org/wiki/ISO/IEC_9126
Maven. Consulted April 2rd
[N7] https://maven.apache.org/
Hibernate. Consulted April 4th
[N8] http://www.tutorialspoint.com/hibernate/
Spring. Consulted April 4th
[N9] https://en.wikipedia.org/wiki/Spring_Framework
Tomcat. Consulted April 10th
[N10] http://tomcat.apache.org/
Mysql. Consulted April 10th
[N11] https://en.wikipedia.org/wiki/MySQL
Angular JS. Consulted April 11th
[N12] https://en.wikipedia.org/wiki/AngularJS
Node JS. Consulted April 11th
[N13] http://whatis.techtarget.com/definition/Nodejs
Cordova. Consulted April 11th
Graduation Project Report 67 2015/2016
[N14] https://blog.codecentric.de/en/2014/11/ionic- angularjs-framework-on-the-rise/
Stack overflow developer survey. Consulted April 24th
[N15] http://blog.stackoverflow.com/2015/04/stack-overflow-developer-survey-2015-
the-results/
Ionic. Consulted April 24th
[N16] https://en.wikipedia.org/wiki/Ionic_(mobile_app_framework)
Native vs. Hybrid discussion. Consulted May 6th
[N17] http://www.ymedialabs.com/hybrid-vs-native-mobile-apps-the-answer-is-clear/
JfreeChat. Consulted May 10th
[N18] http://www.jfree.org/jfreechart/
JasperReports. Consulted May 20th
[N19] http://community.jaspersoft.com/project/jasperreports-library