Namaa.APA.Report

213 vues

Publié le

Most Developed Zakat Calcuation Plateform

Publié dans : Ingénierie
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
213
Sur SlideShare
0
Issues des intégrations
0
Intégrations
6
Actions
Partages
0
Téléchargements
0
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Namaa.APA.Report

  1. 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. 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. 3. 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
  4. 4. 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.
  5. 5. 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.
  6. 6. 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.
  7. 7. 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
  8. 8. 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.
  9. 9. 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.
  10. 10. 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 :
  11. 11. 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
  12. 12. 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
  13. 13. 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
  14. 14. 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
  15. 15. 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
  16. 16. 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
  17. 17. 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).
  18. 18. 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.
  19. 19. 20

×