1. Table des matières
Contents
TABLE DES MATIERES I
TABLE DES FIGURES II
INTRODUCTION 4
1.1 CAHIER DES CHARGES 4
1.2 OBJECTIF DU PROJET 4
1.3 PRESENTATION DE L'ORGANISME D'ACCUEIL 4
1.4 DESCRIPTION DU TRAVAIL DEMANDE 4
1.5 SPECIFICATION DES BESOINS 5
1.5.1 Les besoins fonctionnels ....................................................................................5
1.5.2 Les besoins non fonctionnels ..............................................................................5
1.6 MODELISATION DES BESOINS 6
1.6.1 Les diagrammes des cas d'utilisation ...................................................................6
1.7 LA CONCEPTION GLOBALE 6
1.7.1 Architecture physique .......................................................................................7
1.7.2 Architecture logique .........................................................................................7
1.8 CONCEPTION DETAILLEE 8
1.8.1 Schéma de la base de données ...........................................................................8
1.8.2 Description de quelques scenarios.......................................................................9
CONCLUSION 9
2 JOURNAL DE STAGE 10
3 TRAVAIL REALISE 10
3.1 CHOIX TECHNOLOGIQUES 10
3.1.1 Choix du Java EE ............................................................................................ 10
3.1.2 Choix du générateur Yeoman:........................................................................... 11
3.1.3 JHipster « Java Hipster ».................................................................................. 12
3.2 REALISATION 14
3.2.1 Architecture globale du projet: ......................................................................... 14
3.2.2 Namaa - Home Page:...................................................................................... 14
3.2.3 Namaa - Services Page:................................................................................... 15
4 CONSOLIDATION DES ACQUIS ........................................................... 15
5 CONCLUSION 16
BIBLIOGRAPHIES 16
NETOGRAPHIES 16
ANNEX A: 17
1 INSTALLING YO AND SOME GENERATORS ........................................... 17
1.1 BASIC SCAFFOLDING 17
ANNEX B: 18
2. 2 GENERATING A JHIPSTER APPLICATION QUICKLY ................................. 18
2.1 OPTIONS AVAILABLE WHEN GENERATING AN APPLICATION 18
2.1.1 What is the base name of your application?........................................................ 18
2.1.2 What is your default Java package name? .......................................................... 18
2.1.3 Do you want to use Java 8?.............................................................................. 18
2.1.4 Which *type* of authentication would you like to use? ......................................... 18
2.1.5 Which *type* of database would you like to use?................................................. 19
2.1.6 Which *production* database would you like to use? ........................................... 19
2.1.7 Which *development* database would you like to use? ........................................ 19
2.1.8 Do you want to use Hibernate 2nd level cache? ................................................... 19
2.1.9 Do you want to use WebSockets?...................................................................... 19
2.1.10 Would you like to use Maven or Gradle?............................................................. 19
2.1.11 Would you like to use Grunt or Gulp.js for building the frontend? ............................ 19
2.1.12 Would you like to use the LibSass stylesheet preprocessor for your CSS? ................... 19
2.1.13 Would you like to enable translation support with Angular Translate? ..................... 19
Table des figures
FIGURE 1 : DIAGRAMME DES CAS D'UTILISATION 6
FIGURE 2 : ARCHITECTURE PHYSIQUE DE L'APPLICATION 7
FIGURE 3 : SCHEMA DE LA BASE DE DONNEES 8
FIGURE 4 : DIAGRAMME DE SEQUENCE "CALCULER PORTION" 9
FIGURE 5 : CHRONOGRAMME DU TRAVAIL 10
FIGURE 6 : YEOMAN GENERATOR 11
FIGURE 7 : YEOMAN WORKFLOW 12
FIGURE 8 : JHIPSTER FULL TECHNOLOGIES STACK 13
FIGURE 9 : NAMAA HOME PAGE 14
FIGURE 10 : NAMAA SERVICE PAGE 15
3.
4. 4
Introduction
1.1 Cahier des charges
Le cahier des charges est établi dans le cadre du projet de conception et développement de la
plateforme du calcul du Zakat de la récolte au sein de l’entreprise “iTesLab” étant donné
l’importance du Zakat, l’un des piliers de l’Islam, et aussi la complexité du calcul d’Héritage,
l’entreprise envisage, à travers ce projet, de fournir un moyen performant et surtout fiable aux
musulmans.
1.2 Objectif du projet
L’objectif du projet est de concevoir et développer une plateforme permettant de :
· Calculer les portions du Zakat
· Assurer le suivi du Zakat
1.3 Présentation de l'organisme d'accueil
iTesLab a été créé sur 2012 par des ingénieurs hautement qualifiés ayant acquis des expériences
fortes de plusieurs années de travail dans les centres multinationaux de Recherche &
Développement. Les activités principales se concentrent sur :
• Offrant aux clients des solutions adaptées et pour les besoins de services d'information de
géolocalisation, de sécurité et de la circulation routière personnalisés.
• Développons des solutions et des services pour être utilisés à partir de portail web,
applications mobiles ou de bureau.
1.4 Description du travail demandé
Dans le cadre de son travail, l’entreprise est amenée à réaliser une plateforme du calcul du
Zakat de la récolte, c'est dans ce contexte que s'inclus notre projet intitulé « Conception et
développement de la plateforme du calcul du Zakat de la récolte » qui consiste à la conception et
la réalisation du module destiné à l'utilisateur (l’agriculteur) de cette plateforme avec un couplage
faible basé sur la spécification REST (Representational state transfer)1
.
1 REST (REpresentational State Transfer) est un style d’architecture pour les systèmes hypermédia distribués. Ce
style d'architecture est particulièrement bien adapté au World Wide Web mais n'en est pas dépendant
5. 5
1.5 Spécification des besoins
Dans ce paragraphe nous allons citer les différents besoins fonctionnels et non fonctionnels
que le système doit assurer.
1.5.1 Les besoins fonctionnels
Notre Solution doit permettre un ensemble de fonctionnalités répondant aux besoins de notre
acteur unique pour ce module de l'application « l’agriculteur».
Une rubrique personnalisé pour l’ajout de ses ressources qui peuvent se résumer en trois grandes
catégories : Fruits (Raisin, Dattes), Olive et huiles, Grains.
Une Timeline de suivis des activités de ses ressources: L'utilisateur en se connectant va voir dans
sa Timeline toutes un résumé de l’historique de ses ressources.
La gestion du profil de l'utilisateur et ses ressources: L'utilisateur peut mettre à jour les
informations sur son profil, ajouter/modifier ses ressources en récolte.
Le calcul de sa portion en Zaket : C’est la fonctionnalité essentiel de la plateforme qui se charge
de parcourir toutes les ressources de l’utilisateur connecté et calculer sa portion en fonction de :
• Type des ressources (Fruit, Olive ou autres…)
• Durée : (1 an ou plus)
• Type d’arrosage : (Pluit, puits ou autres)
1.5.2 Les besoins non fonctionnels
• Ergonomie :
La page d'accueil du portail présente une importance primordiale : elle doit donner à
l'utilisateur une vision de ce qu'il peut attendre de la plateforme.
Le module doit présenter une interface claire, simple et facile à utiliser.
• Rapidité :
Le système doit répondre à différentes requêtes dans un temps très réduit.
6. 6
• Robustesse et sécurité:
Le système doit évoluer avec l’augmentation de nombre des requêtes et garantir en même temps
la sécurité d’accès pour tous les clients.
1.6 Modélisation des besoins
La modélisation au niveau de la spécification est basée sur les diagrammes des cas d'utilisation.
Ces diagrammes décrivent les utilisations requises d'un système, ou ce qu'un système est supposé
faire.
1.6.1 Les diagrammes des cas d'utilisation
Figure 1 : Diagramme des cas d'utilisation
1.7 La conception globale
Dans cette section nous allons définir les architectures physique et logique que nous avons
utilisées pour réaliser notre plateforme.
7. 7
1.7.1 Architecture physique
L'architecture physique (également nommée architecture technique) décrit l'ensemble des
composants matériels supportant l'application. Pour le nôtre, nous avons opté pour l'architecture
3-tiers qui vise à faciliter le déploiement, la maintenance ainsi une amélioration de la sécurité des
données.
Ces trois composants sont :
− Un client, c'est-à-dire l'ordinateur demandeur de ressources, équipée d'une interface
utilisateur (généralement un navigateur web) chargée de la présentation.
− Le serveur d'application (appelé également middleware). chargé de fournir la ressource
mais faisant appel à un autre serveur.
− Le serveur des données, fournissant au serveur d'application les données dont il a besoin.
Le principe de l'architecture est illustré dans la figure suivante :
Figure 2 : Architecture physique de l'application
1.7.2 Architecture logique
L'architecture logique est la manière dont les composants logiques d'une solution sont
organisés et intégrés. Nous avons opté pour une architecture en couches.
Le principe des couches applicatives repose sur le fait que chaque couche ne traite de manière
autonome qu'une partie bien précise du système, un ensemble de fonctionnalités bien définies
dans un cadre de responsabilités restreint. Cela contribue à diviser un problème global complexe
en une suite de petits problèmes simples et permet une résolution plus facile, plus structurée et
plus pérenne de l'ensemble. Ainsi la couche d'accès aux données sera en charge des opérations de
lecture/écriture depuis ou vers des sources de données externes diverses ; la couche de services
(ou couche métier) fournira quant à elle la logique métier, etc.
8. 8
Chacune des couches publie ensuite ses services spécialisés à destination d'une autre couche du
système de niveau supérieur. Chaque couche se concentre donc sur ses préoccupations propres
(accès aux données, logique métier, présentation, etc.) et fait appel à une ou plusieurs couches de
niveau inférieur lorsqu'elle sort de sa sphère de responsabilités.
1.8 Conception détaillée
1.8.1 Schéma de la base de données
Ce diagramme sert à présenter d'une manière formelle les liaisons qui existent entre les
différents nœuds de la base de données. La figure 3 montre les différentes nœuds et relations de
la base de données graphique.
Figure 3 : Schéma de la base de données
9. 9
1.8.2 Description de quelques scenarios
On va présenter le scenario de calcul de la portion de la Zaket pour un internaute grâce au
diagramme de séquence système suivant :
Figure 4 : Diagramme de séquence "Calculer Portion"
Conclusion
Tout au long de cette partie, nous avons décrit les différents aspects conceptuels de notre
travail. Nous avons commencé par présenter l'architecture globale de l'application ensuite nous
avons illustré l'architecture détaillée.
10. 10
2 Journal de stage
Il est nécessaire de tracer un diagramme qui décrit la répartition des tâches du projet tout au
long de ces trois mois de stage, afin de donner une vue globale de la répartition du temps par
rapport au travail demandé. La figure suivante représente le chronogramme des tâches.
Figure 5 : Chronogramme du travail
3 Travail réalisé
3.1 Choix technologiques
3.1.1 Choix du Java EE
Plusieurs technologies capables de déployer une application web existent sur le marché. On
peut citer PHP, .NET et Java EE. Toutes ces technologies offrent sensiblement les mêmes
possibilités, mais utilisent un langage et un environnement bien adéquats à chacune. Le choix fixé
sur Java EE pour certaines raisons :
− La richesse de la documentation
− La richesse des librairies, Framework et composants que cette technologie permet
d'utiliser.
11. 11
3.1.2 Choix du générateur Yeoman:
Yeoman est une solution pensée pour répondre à différents besoins. L’idée de départ est de
fournir tous les outils permettant de faciliter la création et la gestion d’une application web :
génération de squelette, exécution des tests, compilation (et oui même pour du web statique se
compile...)
Figure 6 : Yeoman generator
Yeoman est un projet Open Source géré par l’équipe de développement de Chrome dont Paul
Irish (qui a travaillé sur JQuery, HTML5 Boilerplate...), Addy Osmani (Jquery) et Eric
Bidelman (html5rocks.com). La documentation liée au projet est très bien faite toutes les
informations nécessaires sont sur le site web.
Prérequis
Avant d’utiliser Yeoman on doit disposer de Node.js (la plateforme JS construite sur le moteur
JavaScript de Chrome) et de son gestionnaire de package npm.
Yeoman est en fait composé de trois outils :
• Yo : outil de scaffolding maintenu par Yeoman permettant de générer l’ossature de votre
application
• Bower : outil de gestion des dépendances
• Grunt : lanceur de tâche
Le schéma ci-dessous résume bien le workflow :
12. 12
Figure 7 : Yeoman Workflow
Il existe plusieurs générateurs de Yeoman tel que JHipster que nous avons utilisé.
3.1.3 JHipster « Java Hipster »
JHipster est un framework de développement rapide dédié à la création de web-app.
JHipster se veut performant, robuste et moderne.
JHipster n’est pas un framework au même titre que Spring ou Hibernate qui s’ajoutent comme
une dépendance au build ou au runtime. JHipster est un assemblage d’outils pour faciliter la
création/initialisation du projet, le développement et fournir des services standards d’une web
app (Authentification, MVVM, …). Pour utiliser JHipster il faut au minimum installer Nodejs,
Yeoman, Maven ou Gradle et un JDK. Il existe également une image Docker pour tester
facilement.
Choisir JHipster c’est adopter une stack technique moderne et robuste.
A. Technology stack on the client side
Single Web page application, Responsive Web Design
• HTML5 Boilerplate
• Twitter Bootstrap
• AngularJS
• Full internationalization support with Angular Translate
• Optional Sass support for CSS design
• Optional WebSocket support with Spring Websocket
• With the great Yeoman development workflow:
• Easy installation of new JavaScript libraries with Bower
• Build, optimization and live reload with Grunt or Gulp.js
• Testing with Karma and PhantomJS
• Support for the Thymeleaf template engine, to generate Web pages on the server side
13. 13
B. Technology stack on the server side
A complete Spring application:
• Spring Boot for easy application configuration
• Maven or Gradle configuration for building, testing and running the application
• Spring Security
• Spring MVC REST + Jackson
• Optional WebSocket support with Spring WebSocket
• Spring Data JPA + Bean Validation
• Database updates with Liquibase
• Elasticsearch support if you want to have search capabilities on top of your database
• MongoDB support if you'd rather use a document-oriented NoSQL database instead of
JPA
• Cassandra support if you'd rather use a column-oriented NoSQL database instead of JPA
C. Monitoring with Metrics
• Caching with ehcache (local cache) or hazelcast (distributed cache)
• Optional HTTP session clustering with hazelcast
• Optimized static resources (gzip filter, HTTP cache headers)
• Log management with Logback, configurable at runtime
• Connection pooling with HikariCP for optimum performance
• Builds a standard WAR file or an executable JAR file
Figure 8 : JHipster full technologies stack
14. 14
3.2 Réalisation
Nous avons recourt au Git comme outil de versionning ajoutant le projet dans une nouvelle
repository sur : https://github.com/hosnimed/namaa-apa que nous avons appellee « Namaa ».
3.2.1 Architecture globale du projet:
3.2.2 Namaa - Home Page:
Figure 9 : Namaa Home Page
15. 15
3.2.3 Namaa - Services Page:
Figure 10 : Namaa Service Page
4 Consolidation des acquis
ANS ce rapport nous avons mis en œuvre le bilan complet de notre travail qui se
situe dans le cadre du stage d'immersion en entreprise.
Ainsi, pour atteindre ces objectifs nous avons commencé par mettre le projet dans son cadre
général en présentant l'organisme d'accueil et en détaillant les objectifs de ce projet.
D
16. 16
Ensuite, nous avons effectué une étude théorique qui nous a permis de mettre l'accent sur les
différentes technologies qui feront l'objet de notre projet. Par la suite, nous avons entamé la
partie analyse et spécification des besoins permettant de tracer les objectifs à atteindre à partir des
besoins fonctionnels et non fonctionnels. Puis, nous avons passé à l'étude conceptuelle de la
future application et cela à travers la conception globale et détaillée de l'application. Enfin, nous
avons terminé par la réalisation qui nous a permis de recenser les différents outils matériels et
logiciels à utiliser pour développer l'application.
5 Conclusion
L'application réalisée reste un point de départ qui laisse des grandes possibilités d'extension
et d'amélioration voir d’autres types de Zakat citons les entreprises , l’or , l’argent … qui
constituent d’autres volets que la plateforme doit répondre pour devenir ainsi la première
plateforme internationale qui peut répondre aux différents besoins en Zakat pour la communauté
musulmane utilisant ainsi les technologies les plus récents et offrant une expérience utilisateur
agréable.
Bibliographies
[1] Matt Raible , Get Hip with JHipster!
[2] Amana Bank , The Zakat Guide
Netographies
[1] http://yeoman.io/learning/index.html consultée le 02/07/2015
[2] http://jhipster.github.io/ consultée le 03/07/2015
[2] https://github.com/jhipster consultée le 03/07/2015
[3] https://spring.io/blog/2015/02/10/introducing-jhipster consultée le 03/07/2015
[4] https://en.wikipedia.org/wiki/JHipster consultée le 06/07/2015
17. 17
ANNEX A:
1 Installing yo and some generators
First, you'll need to install yo and other required tools:
npm install -g yo bower grunt-cli gulp
npm is the package manager for Node.js and comes bundled with it.
1.1 Basic scaffolding
To scaffold a web application, you'll need to install the generator-webapp generator:
npm install -g generator-webapp
This is the default web application generator that will scaffold out a project containing HTML5
Boilerplate, jQuery, Modernizr, and Bootstrap. You'll have a choice during the interactive
prompts to not include many of these. This generator will use Grunt, while others may
use Gulp or other alternative set of build tools.
Now that the generator is installed, create a directory for your new project
mkdir my-yo-project
$ cd my-yo-project
and then run:
yo webapp
18. 18
Each project created with yo will also pull in relevant Grunt tasks which the community feels is
needed or useful for your workflow.
The webapp generator is considered the simplest possible start for a web app.
ANNEX B:
2 Generating a JHipster application quickly
To generate our application, type:
yo jhipster
And answer the questions asked by the generator to create an application taylored to your needs.
2.1 Options available when generating an application
2.1.1 What is the base name of your application?
This is the name of our application.
2.1.2 What is your default Java package name?
Our Java application will use this as its root package.
2.1.3 Do you want to use Java 8?
Depending on our choice, JHipster will either create a Java 7 or a Java 8 application. Java 8
comes with many new features, including lambdas,
2.1.4 Which *type* of authentication would you like to use?
We can either use a classical session-based authentication mechanism, like we are used to do in
Java (this is how most people use Spring Security), a OAuth 2.0 authentication mechanism
(JHipster then provides the necessary OAuth2 server code and database tables), or a token-
based approach (similar to OAuth 2.0, but uses a custom token system that does not require
database tables). The OAuth 2.0 and the token approaches allow to use a stateless application
architecture (they do not rely on the HTTP Session).
19. 19
2.1.5 Which *type* of database would you like to use?
We can choose between a classical SQL database, which you will access with Spring Data JPA,
or a NoSQL approach with MongoDB or Cassandra.
2.1.6 Which *production* database would you like to use?
This is the database we will use with our "production" profile. To configure it, modify
our src/main/resources/config/application-prod.yml file.
2.1.7 Which *development* database would you like to use?
This is the database we will use with our "development" profile. To configure it, modify our
src/main/resources/config/application-dev.yml file.
2.1.8 Do you want to use Hibernate 2nd level cache?
Hibernate is the JPA provider used by JHipster. For performance reasons, we highly recommend
you to use a cache, and to tune it according to our application's needs.
If we choose to do so, we can use either ehcahce (local cache) or Hazelcast (distributed cache,
for use in a clustered environnement)
2.1.9 Do you want to use WebSockets?
Websockets can be enabled using Spring Websocket.
2.1.10 Would you like to use Maven or Gradle?
We can build your generated Java application either with Maven or Gradle. Maven is more stable
and more mature. Gradle is more flexible, easier to extend, and more hype.
2.1.11 Would you like to use Grunt or Gulp.js for building the frontend?
Grunt is the most widely used and most mature build tool for our JavaScript and CSS
assets. Gulp.js is a more recent alternative, which is easier to use and learn.
2.1.12 Would you like to use the LibSass stylesheet preprocessor for your
CSS?
Node-sass a great solution to simplify designing CSS. To be used efficiently, wee will need to run
a Grunt or Gulp server, which will be configured automatically.
2.1.13 Would you like to enable translation support with Angular Translate?
By default JHipster provides excellent internationalization support, both on the client side
with Angular Translate and on the server side. However, internationalization adds a little
overhead, and is a little bit more complex to manage, so you can choose not to install this feature.
