Projet Webase

I. La définition du projet

1. L’existant : 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

I.1. L'existant, Webase4

I.1. Les défauts de Webase4

Framework Base de données Fonctionnalités Code

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

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

Viabase BDU Topologie

Krishna Illusion Cerbère

Webase

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

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

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

I.5. Choix des outils

Critères :outils Open Sourceoutils multiplateformesconseils

Nos choix :Postgresql (base de données)Tomcat (serveur d’applications)Java, Acegi, Hibernate, Tiles

II. Le fonctionnement

1. Schéma global

2. MVC et architecture 3-tier

3. L’organisation « pratique »

4. La sécurité, …

5. De l’utilité de Spring

6. L’interface

II.1. Fonctionnement de Webase 5

Organisation interne des différents outils composant Webase 5

II.1. Accès aux données

Sources multiples Object Relational Mapping Data Access Object

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ées Traitement Présentation

II.2. Le modèle MVC

MVC : Modèle, Vue,

Contrôleur Permet de séparer

affichage et récupération des données

Navigateur

Contrôleur Vue

Modèle

Base de données

Requête

HT

TP

Rép

onse

HT

TP

II.2. MVC + 3-tier

Couche données

Couche présentation

Navigateur

Contrôleur Vue

Modèle

Base de données

Couche métier

II.3. Organisation du code

Classes de : - Modèle - Formulaire- DAO - Action- Service

II.4. La sécurité, …

Modules de : - Sécurisation (Acegi)- Journalisation (Log4j)- Accès aux données (DAO, Hibernate)- Services web distants…

Spring !

II.5. L’IOC

Classe DAO 1

Classe contrôleur

Classe de connexion BdD

Classe DAO 2

Classe Service 2Classe service 1

Classe DAO 3

Classique

IOC

II.5. L’AOP

Ajoute des fonctionnalités « transverses » à des classes existantes :SécuritéLogsAspect transactionnel

Un aspect fonctionne comme un filtre ou un calque.

II.6. Interfaces

Différentes interfaces possibles Interface web classique Service web : simple API AJAX ?

XHTML

XML

HTTP

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

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 »

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

III.3. Le déploiement

1. Installation de PostgreSQL, de la JVM, de Tomcat (SSL)

2. Migration de l’ancienne base de données

3. Utilisation d’Eclipse (fichier .war)

4. Déploiement via le Tomcat Manager

Bilan: Extrême facilité de déploiement

III.4. La documentation

Formations au cours de l’année Achats de livres Utilisation du wiki:

Documentation des outils utilisésDocumentation des étape d’installation de

Webase5. Génération d’une Javadoc

IV. Bilan du Projet

1. Bilan fonctionnel

2. Observations sur l’architecture retenue

3. Poursuite du projet

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

Fonctionnalités Clés : trésorerie

Fonctionnalités clés : fiche de membre

Fonctionnalités clés : fin de permanence

IV.2. Observations sur l’architecture retenue Lourdeur de la mise en place des

frameworks

Code « propre » dû aux frameworks

Maintenabilité plus aisée

IV.2. Observations sur l’architecture retenue

Courbe d’apprentissage plus lente à décoller

Le modèle MVC s’apprend par la pratique

Code volontairement « contraignant »

IV.3. Poursuite du projet

Formations de la nouvelle génération de développeurs de Webase5

Capitalisation des connaissances acquises pendant le projetGuide utilisateur et guide développeurFormations effectuées et à faire perdurer

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