inventory management web and mobile applications (jee/ionic/angular)

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.


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.


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


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


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


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


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


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


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


LIST OF TABLES

3.2 Market solutions comparison . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29


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.


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


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.



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.



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



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.



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.



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.


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


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



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



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 5/5/16 To 5/10/16 : Design


specifications


specifications




From 5/14/16 To 5/24/16 : Testing


specifications








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



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/21/16 To 3/27/16 : Design


specifications


specifications




From 4/10/16 To 5/14/16 : Testing


specifications








From 5/15/16 To 6/4/16 : Sprint 2




From 5/17/16 To 5/20/16 : Design


specifications


specifications




From 5/24/16 To 6/1/16 : Testing


specifications

From 5/28/16 To 6/1/16 : Develop integration test plans using product

specifications




From 3/21/16 To 5/28/16 : Documentation

From 3/14/16 To 6/01/16 : Pilot

Figure 2.7: Actual planning



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.


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


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:



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.



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



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.



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,



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



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.



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,



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.


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


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



-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.

https://en.wikipedia.org/wiki/Application_framework

https://en.wikipedia.org/wiki/Inversion_of_control

https://en.wikipedia.org/wiki/Inversion_of_control

https://en.wikipedia.org/wiki/Servlet_container

https://en.wikipedia.org/wiki/Java_platform

https://en.wikipedia.org/wiki/Java_EE

https://en.wikipedia.org/wiki/Java_EE

https://en.wikipedia.org/wiki/Programming_model

https://en.wikipedia.org/wiki/Enterprise_JavaBeans

https://en.wikipedia.org/wiki/Open_source



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:



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.

https://en.wikipedia.org/wiki/Apache_Software_Foundation

https://en.wikipedia.org/wiki/Java_Platform,_Enterprise_Edition

https://en.wikipedia.org/wiki/Java_Servlet

https://en.wikipedia.org/wiki/JavaServer_Pages

https://en.wikipedia.org/wiki/Unified_Expression_Language

https://en.wikipedia.org/wiki/Unified_Expression_Language

https://en.wikipedia.org/wiki/WebSocket

https://en.wikipedia.org/wiki/Java_(programming_language)

https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol

https://en.wikipedia.org/wiki/Web_server

https://en.wikipedia.org/wiki/Java_(programming_language)



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;



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

http://www.gnu.org/licenses/lgpl.html



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.



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



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



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



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



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



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



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.


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


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.



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.



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.



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.



Figure 5.10: Adding an input order interface

Figure 5.11: list of input orders interface



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



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.



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



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.



*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.



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.


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.


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


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

http://ocpgroup.ma/

http://www.codeproject.com/Articles/604417

https://www.standishgroup.com/

https://en.wikipedia.org/wiki/ISO/IEC_9126

https://maven.apache.org/

http://www.tutorialspoint.com/hibernate/

https://en.wikipedia.org/wiki/Spring_Framework

http://tomcat.apache.org/

https://en.wikipedia.org/wiki/MySQL

https://en.wikipedia.org/wiki/AngularJS

http://whatis.techtarget.com/definition/Nodejs


[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

https://blog.codecentric.de/en/2014/11/ionic-%20ang%20ularjs-framework-on-the-rise/

http://blog.stackoverflow.com/2015/04/stack-overflow-developer-survey-2015-%20%20%20%20%20the-results/

http://blog.stackoverflow.com/2015/04/stack-overflow-developer-survey-2015-%20%20%20%20%20the-results/

https://en.wikipedia.org/wiki/Ionic_(mobile_app_framework)

http://www.ymedialabs.com/hybrid-vs-native-mobile-apps-the-answer-is-clear/

http://www.jfree.org/jfreechart/