Projet Webase. I. La définition du projet 1. Lexistant : Webase 4 2. Cahier des charges 3. La répartition des données 4. Le modèle de données 5. Le choix.

Présentation au sujet: "Projet Webase. I. La définition du projet 1. Lexistant : Webase 4 2. Cahier des charges 3. La répartition des données 4. Le modèle de données 5. Le choix."— Transcription de la présentation:

1 Projet Webase

2 I. La définition du projet 1. Lexistant : Webase 4 2. Cahier des charges 3. La répartition des données 4. Le modèle de données 5. Le choix des outils

3 I.1. L'existant, Webase4

4

5

6

7

8 I.1. Les défauts de Webase4 Framework Base de données Fonctionnalités Code

9 I.2. Cahier des charges de Webase5 Code et base de données robustes et maintenables Pas de pertes de fonctionnalités Utilisation des nouveaux outils (CAS, BDU) Trésorerie Permanences

10 I.3. La répartition des données

11 I.4. Le modèle de données

12

13

14 I.5. Choix des outils Critères : outils Open Source outils multiplateformes conseils Nos choix : Postgresql (base de données) Tomcat (serveur dapplications) Java, Acegi, Hibernate, Tiles

15 II. Le fonctionnement 1. Schéma global 2. MVC et architecture 3-tier 3. Lorganisation « pratique » 4. La sécurité, … 5. De lutilité de Spring 6. Linterface

16 II.1. Fonctionnement de Webase 5 Organisation interne des différents outils composant Webase 5

17 II.1. Accès aux données Sources multiples Object Relational Mapping Data Access Object

18 II.2. Architecture 3-tier 3-tier : Couches présentation, traitement (services) et accès aux données (dao) Indépendance des processus métiers DonnéesTraitementPrésentation

19 II.2. Le modèle MVC MVC : Modèle, Vue, Contrôleur Permet de séparer affichage et récupération des données

20 II.2. MVC + 3-tier

21 II.3. Organisation du code Classes de :- Modèle- Formulaire - DAO- Action - Service

22 II.4. La sécurité, … Modules de :- Sécurisation (Acegi) - Journalisation (Log4j) - Accès aux données (DAO, Hibernate) - Services web distants… Spring !

23 II.5. LIOC

24 II.5. LAOP Ajoute des fonctionnalités « transverses » à des classes existantes : Sécurité Logs Aspect transactionnel Un aspect fonctionne comme un filtre ou un calque.

25 II.6. Interfaces Différentes interfaces possibles Interface web classique Service web : simple API AJAX ? XHTML XML HTTP

26 III. Le développement 1. La méthode adoptée 2. Eclipse : un outil de développement 3. Le déploiement de Webase 4. La documentation

27 III.1. La méthode : une version par développeur Outil : Subversion travail indépendant mais coordonné Avantages : possibilité de travailler à distance pas de gêne entre les développeurs possibilité de tests Inconvénients : tendance à « l'isolation »

28 III.2. Eclipse, un outil libre très puissant : Nombreux plugins : XML, Tomcat, SVN Débugage facile Nombreuses fonctions très pratiques : formatage des fichiers sources génération automatique (getters/setters, import) correction de la syntaxe en temps réel compilation automatique

29

30

31

32 III.3. Le déploiement 1. Installation de PostgreSQL, de la JVM, de Tomcat (SSL) 2. Migration de lancienne base de données 3. Utilisation dEclipse (fichier.war) 4. Déploiement via le Tomcat Manager Bilan: Extrême facilité de déploiement

33

34 III.4. La documentation Formations au cours de lannée Achats de livres Utilisation du wiki: Documentation des outils utilisés Documentation des étape dinstallation de Webase5. Génération dune Javadoc

35

36 IV. Bilan du Projet 1. Bilan fonctionnel 2. Observations sur larchitecture retenue 3. Poursuite du projet

37 IV.1. Bilan fonctionnel Respect du cahier des charges Webase5 est livrée « à temps » Toutes les fonctionnalités centrales sont implémentées Interface plus pertinente, plus aisée à prendre en main

38 Fonctionnalités Clés : trésorerie

39 Fonctionnalités clés : fiche de membre

40 Fonctionnalités clés : fin de permanence

41 IV.2. Observations sur larchitecture retenue Lourdeur de la mise en place des frameworks Code « propre » dû aux frameworks Maintenabilité plus aisée

42 IV.2. Observations sur larchitecture retenue Courbe dapprentissage plus lente à décoller Le modèle MVC sapprend par la pratique Code volontairement « contraignant »

43 IV.3. Poursuite du projet Formations de la nouvelle génération de développeurs de Webase5 Capitalisation des connaissances acquises pendant le projet Guide utilisateur et guide développeur Formations effectuées et à faire perdurer

44 IV.3. Poursuite du projet Approfondissement de la Javadoc Exploiter les possibilités de Spring Mettre en place de nouvelles fonctionnalités en plus du cœur déjà fonctionnel