atam guide de developpement v1.3
-
Upload
abdessamad-hamouch -
Category
Documents
-
view
460 -
download
2
description
Transcript of atam guide de developpement v1.3
GUIDE DE DEVELOPPEMENT
ATAM
Guide de développement
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx Document confidentiel © Copyright 2012 JeetConsulting, tous droits réservés Page : 2/28
PRECAUTIONS D’USAGE
Dès réception, le destinataire doit :
Détruire les versions et révisions précédentes en sa possession.
Remplacer les documents détruits par le présent document.
Appliquer cette règle (destruction/remplacement) à l’ensemble des documents copiés sous sa responsabilité. S’assurer, en cas d’obligation de conservation, que les versions- précédentes ne peuvent plus être utilisées.
DOCUMENT ETABLI SOUS LA RESPONSABILITE DES SIGNATAIRES
Rédaction Vérification Approbation
Nom : Nicouleau Sébastien
Date : 27/04/2012
Signature :
Nom : : Nicouleau Sébastien
Date : 14/05/2012
Signature :
Nom :
Date :
Signature :
HISTORIQUE DES VERSIONS Après rédact ion , t ou t documen t do i t ê t re approuvé pour ê t re d i f fusé e t app l i cab le .
Version Date Observations
01-R 27/04/2012 Création du document
1.0 14/05/2012 Validation du document
1.1 18/05/2012 Modification du document suite aux remarques remontées par AT2O le 15/05/2012
1.2 21/05/2012 Modification du document suite aux remarques remontées par AT2O le 21/05/2012
1.3 24/05/2012 Modification du document suite aux remarques remontées par AT2O le 22/05/2012
Guide de développement
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx Document confidentiel © Copyright 2012 JeetConsulting, tous droits réservés Page : 3/28
Sommaire
1 INTRODUCTION 5
1.1 Contexte 5
1.2 Objectif du document 5
1.3 Documents de référence 5
1.4 Lexique 5
2 OBJECTIFS 6
3 ENVIRONNEMENT DE DEVELOPPEMENT 7
3.1 Usine de développement 7
3.2 Poste de développement 8 3.2.1 Structure des répertoires de travail 8 3.2.2 Structure répertoire Projects 9 3.2.3 IDE 9
4 ARCHITECTURE APPLICATIVE 10
4.1 Architecture en couche 10 4.1.1 Définition 10 4.1.2 Décomposition Logique 10
4.2 Socle Technique 12 4.2.1 Framework 12
5 REGLES DE DEVELOPPEMENT 17
5.1 Structure projet 17
5.2 Règles de nommage des Fichiers 17
5.3 Règles de codage 19 5.3.1 Encodage 19 5.3.2 Formatage du code 19 5.3.3 Règle de nommage 19 5.3.4 Documentation 20 5.3.5 Communication des différentes couches 20 5.3.6 Gestion des exceptions 21 5.3.7 Log 21 5.3.8 Ressources 22 5.3.9 Tests unitaires 22
6 NOUVEL ARRIVANT 24
6.1 Espace de travail 24
6.2 Créer un nouveau Workspace 24 6.2.1 Importer le « Formatteur » de sources pour l’application 24 6.2.2 Importer le « Code Templates » de sources pour l’application 24 6.2.3 Importer le fichier de configuration Checkstyle de sources pour l’application 24 6.2.4 Exclure les fichiers de l’outil de versionning. 24 6.2.5 Configurer le formatage automatique 25
6.3 Import des projets 25
6.4 Exécuter les tests unitaires 27
6.5 Multiple IE 28
Tableaux et figures
Tableaux :
Tableau 1 : Tableau des documents de référence 5 Tableau 2 : Lexiques 5
Guide de développement
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx Document confidentiel © Copyright 2012 JeetConsulting, tous droits réservés Page : 4/28
Tableau 3 : Composants de l'usine de développement 8 Tableau 4 : Définition des dossiers du poste de travail 8
Figures :
Figure 1 : Usine de développement 7 Figure 2 : Structure du poste de travail 8 Figure 3 : Structure du répertoire Projects 9 Figure 4 : Architecture logique en couche 10 Figure 7 : Spring - IOC 13 Figure 7 : Widgets EXT-GWT 15 Figure 8 : Structure Projet Maven 17 Figure 9 : Communication Service Simple 20 Figure 10 : Communication Service Complexe 21 Figure 11 : Les différentes phases de tests 22
Guide de développement
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx Document confidentiel © Copyright 2012 JeetConsulting, tous droits réservés Page : 5/28
1 INTRODUCTION
1.1 Contexte
Dire dans quel contexte on se place pour rédiger le document
1.2 Objectif du document
Ce document sert de document de référence sur l’environnement et sur les méthodologies de développement.
1.3 Documents de référence
Titre Référence
Spécifications fonctionnelles 20120427 Spécifications fonctionnelles V 1.12 - Livraison Jeet Consulting.pdf
Dossier D’architecture Technique 20120414-ATAM-Dossier-Architeture-Technique.pdf
Spécifications Techniques 20120514-ATAM-Spécifications-Techniques.pdf
Tableau 1 : Tableau des documents de référence
1.4 Lexique
Terme Définition
ATAM Application de Traitement des Archives Mixtes
Classe de service La classe de service désigne le processus de traitement (conforme à la politique d’archivage) affecté à une famille d’objets éligibles à l’archivage en fonction de son niveau de criticité et sa durée de conservation.
Métadonnées Le mot signifie « donnée de/à propos de donnée ». C’est un ensemble
structuré d'informations associées à l’objet versé quel que soit son support (papier ou électronique). On distinguera les métadonnées : de description, de provenance, de système (format technique), de maintien de l’intégrité
Liste de références
ou Tableau de gestion
État déclaratif des catégories d’éléments éligibles à une conservation durable produit par chaque activité ou service selon son organisation, les contraintes applicables et la granularité optimale. La liste de références donne des indications sur la durée de
conservation, le support de l’archive, les classes de services et règles de communicabilité applicables. Le tableau de gestion, imposé par les archives de France à l’organisme public, définit le sort, l’organisation et les contraintes applicables aux archives publiques. Celui-ci peut être librement complété par le service concerné. La liste de références constitue l’interface normalisée entre les besoins de production et
l’application de traitement des archives.
Versement Opération technique qui réalise : Le référencement des objets versés dans le catalogue archive (méta description) Le transfert des objets versés dans l’espace de conservation durable (papier ou
numérique). Dès le versement la responsabilité de l’intégrité et la disponibilité des objets versés est affectée au service prestataire (en complément de la responsabilité du service verseur vis à
vis du contenu dont il reste propriétaire
Tableau 2 : Lexiques
Guide de développement
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx Document confidentiel © Copyright 2012 JeetConsulting, tous droits réservés Page : 6/28
2 OBJECTIFS
L’ensemble des développements pour le projet ATAM sont encadrés par des normes et une méthodologie de travail qui permettent :
D’homogénéiser techniquement les diverses applications
D’encadrer les développements De pouvoir suivre la qualité des développements produits. De Limiter les régressions en phase de production.
Guide de développement
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx Document confidentiel © Copyright 2012 JeetConsulting, tous droits réservés Page : 7/28
3 ENVIRONNEMENT DE DEVELOPPEMENT
L’environnement de développement est constitué en son centre d’une usine de développement qui permet de tenir les objectifs suivants :
Automatiser le maximum de taches dans le processus d'échanges MOE/MOA
Donner de la visibilité du travail des équipes pour la direction. S'assurer en permanence de la qualité et de l’intégrité du code produit. Facilité la vie quotidienne du développeur en proposant une intégration avec son
environnement de travail. Sécuriser les droits d’accès aux différents outils.
3.1 Usine de développement
Figure 1 : Usine de développement
L’usine de développement est constituée des applications et outils suivants :
Composant Outil
Intégration Continue Hudson
Gestion de sources Maven
Bug Tracker Jira
Gestion de configuration Projet Maven 2
Guide de développement
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx Document confidentiel © Copyright 2012 JeetConsulting, tous droits réservés Page : 8/28
Serveur D’application Glassfish3
Sgbd Postgres
Tests unitaires Junit 4
Couverture de Tests Cobertura
Tests d’intégration IHM Sélénium
Règles de Programmation CheckStyle , PMD
Tableau 3 : Composants de l'usine de développement
3.2 Poste de développement
Afin d’améliorer la maintenance et de contrôler les versions des outils utilisés, les postes de
développements sont normalisés.
3.2.1 Structure des répertoires de travail
L’ensemble des répertoires de travail sont situés sur le lecteur « D » :
Figure 2 : Structure du poste de travail
Le tableau suivant précise l’utilisation des différents répertoires :
Dossier Définition
ApplicationServers Dossier d’installation du ou des serveurs d’applications.
Ide Dossier d’installation des Ides Java (eclipse).
Java Dossier d’installation des machines virtuelles
Misc Dossier d’installation des librairies tierces (doc + sources)
Projects Dossier de travail des différents projets.
Sgbd Dossier d’installation des serveurs de base de données Locales
Tmp Dossier temporaire de travail
Tools Dossier d’installation des différents outils (Maven, Putty …)
Tableau 4 : Définition des dossiers du poste de travail
Guide de développement
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx Document confidentiel © Copyright 2012 JeetConsulting, tous droits réservés Page : 9/28
3.2.2 Structure répertoire Projects
Pour homogénéiser la structure des répertoires des différents projets, chaque projet sera identifier par un répertoire dénommé atam-<le nom du projet> ; ce dernier contiendra deux sous répertoires Sources et Workspaces.
Sources contient les sources du projet. Workspaces contient le ou les Workspaces Eclipse propres au projet.
Suivant les besoins d’autres sous répertoires peuvent être ajoutés, comme Documentations pour les documentations relatives au projet.
Figure 3 : Structure du répertoire Projects
3.2.3 IDE
L’environnement de développement des équipes, repose sur l’utilisation de L’IDE Eclipse, cet
environnement largement utilisé et connu de tous développeurs JAVA/JEE. La bonne intégration de cet IDE repose essentiellement à l’installation de plugin-ins complémentaires qui facilitent le travail
du développeur.
Le poste de développement est livré avec un Eclipse installé et configuré avec les versions de plugins adaptés. Voici les plugins fondamentaux préinstallés.
1. Subclipse (http://subclipse.tigris.org/) pour la communication avec l’outil de versioning 2. Mylin pour avoir le suivi des anomalies de l’outil de Bug Tracker
3. SpringIde (http://springide.org/blog/) 4. M2clipse (http://m2eclipse.sonatype.org/) permet de gérer nativement des projets maven2
sous eclipse 5. JBossTools (http://www.jboss.org/tools) 6. Checkstyle (http://checkstyle.sourceforge.net/) permet de vérifier les règles de
programmation. Le même fichier de configuration est utilisé entre le poste de développement
et l’intégration continue. La particularité sur le poste de développement est que certaines règles définies et non respectées font apparaitre le fichier en erreur aux développeurs ; ces derniers doivent donc corriger leur fichier.
Remarque : L’installation de nouveau plugin ou la mise à jour d’un plugin, ne pourra se faire que sous acceptation du Chef de projet.
Guide de développement
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx Document confidentiel © Copyright 2012 JeetConsulting, tous droits réservés Page : 10/28
4 ARCHITECTURE APPLICATIVE
4.1 Architecture en couche
4.1.1 Définition
Lors de la conception d’une application, il est d’usage de penser à l’organisation des développements mais également au cycle de vie de l’application après la mise en production.
L’architecture retenue doit permettre de faciliter l’évolution, l’extension et la maintenance du système.
L’architecture en couches, comme son nom l’indique, consiste à organiser l’application par couches fonctionnelles indépendantes et complémentaires, chacune communiquant avec les couches qui l’entourent. Ce principe peut être appliqué sur tout type d’application, et particulièrement sur les
applications J2EE.
Chaque couche fournit aux autres couches des services par l’intermédiaire d’interfaces, en masquant le détail de ses opérations. L’implémentation des services est masquée et peut changer sans impacter les autres couches, aussi longtemps que les interfaces associées restent inchangées. Concrètement, une couche pourrait donner accès à un service non développé (développement en cours ou reporté pour cause de lotissement). Ce pseudo-service (appelé « bouchon ») mis en place
temporairement permettra aux équipes ayant besoin du service de poursuivre leur développement dans une logique incrémentale. La bascule du bouchon vers le service réel n’impactera pas les couches utilisatrice du service.
4.1.2 Décomposition Logique
L’architecture applicative se définit en 5 couches logiques, le schéma ci-dessous illustre ce découpage en couches :
Base de données
Communication
Contrôle Service Métier Persistance
VO Données à
afficher
BR Ecrans
Contrôleur IHM - CR
Services commun
s
BO Objets métiers
Contrôleur Messages -
CR
DS
Service de persistance
Services spécialisés
IHM
Services spécialisés messages
Services d’écoute
Syn
ch
ron
is
e
active
active
active
Créé
Utilis
e
Appelle
Appelle
Utilis
e
Man
ipu
le
Manipule
Manipule
Synchronise
Figure 4 : Architecture logique en couche
Guide de développement
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx Document confidentiel © Copyright 2012 JeetConsulting, tous droits réservés Page : 11/28
4.1.2.1 La couche « persistence »
Elle fournit les services de base nécessaires à la synchronisation des objets métiers avec la base de données (consultation, création, modification, suppression). Elle est également responsable du mapping entre les objets métiers et la base de données.
La couche « Persistance » est la moins visible du point de vue de l’utilisateur. Elle est également la plus technique car elle peut être fortement dépendante du mode de stockage persistant utilisé (base
de données relationnelle, fichiers, …)
4.1.2.2 La couche « métier »
Cette couche décrit les objets purement métiers traités par l’application.
La couche « Métier » est la couche de données métiers de l’application correspondant au modèle de composants métiers et de classes des spécifications fonctionnelles.
4.1.2.3 La couche « services »
Cette couche contient l’ensemble des services métiers qui manipulent les objets métiers.
Chaque traitement de la couche « Service » devrait correspondre à une activité apparaissant dans un ou plusieurs diagrammes d’activités.
4.1.2.4 La couche « contrôleur »
Cette couche prend en charge la séquence des traitements fournis par la couche « Service ». C’est la couche intermédiaire entre les services métiers et les entrées/sorties de l’application. C’est elle qui reçoit les requêtes provenant des utilisateurs (humain ou machine).
Cette couche est à rapprocher des diagrammes d’activités des spécifications fonctionnelles détaillées.
4.1.2.5 La couche « communication »
4.1.2.5.1 Interface Homme-Machine
Cette interface décrit les écrans vus et utilisés par les utilisateurs, tant aux niveaux graphique et
ergonomique (écran) que fonctionnel (contenu). Cette interface ne communique qu’avec la couche « Contrôle » qui reçoit les requêtes de l’utilisateur, les traites et détermine l’écran à afficher.
4.1.2.5.2 Interface Machine-Machine
Cette interface est le pendant de l’IHM pour des utilisateurs non-humains, communiquant avec l’application via un MOM. Elle est composée d’un service d’écoute (listener) et d’un service producteur de messages
Remarque : Pour la suite du document, les couches logiques Contrôleur et Communication
sont regroupées au sein de la couche Présentation.
Guide de développement
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx Document confidentiel © Copyright 2012 JeetConsulting, tous droits réservés Page : 12/28
4.2 Socle Technique
4.2.1 Framework
Un ensemble de Framework ont été retenus pour constitués le socle technique de l’application.
Cette liste est non exhaustive ; l’application pourra intégrer d’autres Framework suivant leurs besoins.
GTW + EXT-GWTJasper Reports –
Editique /Reporting
Services Métiers POJO
Sp
ring
Inje
ctio
n d
e d
ép
en
da
nce
s
Couche vue
/ contrôleur
Couche
Services
Couche
Persistence
Sp
ring
-
Se
cu
rityG
estio
n d
es d
roits
JPA – Couche d’abstraction
Do
ma
in m
od
el
Hibernate
Services Métiers Spécialisés
IHM
Services Métiers
Spécialisés Editique
Activiti - Workflow
Spring - Data
Hibernate-Envers (Piste d’audit)
WebServices
(API)
Lib
rairie
s A
pa
ch
e C
om
mo
ns
Gile
ad
4.2.1.1 La couche « persistence »
4.2.1.1.1 Mapping Objet / Relational – Framework Hibernate / JPA
Hibernate est un outil de mapping objet/relationnel pour le monde Java. Le terme mapping objet/relationnel (ORM) décrit la technique consistant à faire le lien entre la représentation objet des
données et sa représentation relationnelle basée sur un schéma SQL.
Dans le cadre de ce projet, nous utiliserons Hibernate en version 3.3 Hibernate est utilisé avec la couche d’abstraction JPA (Java Persistence API).
L’utilisation de JPA présente les avantages :
De découpler l’application de l’implémentation Objet/Relationnel mise en œuvre (par exemple, possibilité de modifier ultérieurement Hibernate par Toplink sans refactoring lourd de l’application).
De respecter les bonnes pratiques en termes de mise en œuvre de couche de mapping
Objet/Relationnel
Guide de développement
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx Document confidentiel © Copyright 2012 JeetConsulting, tous droits réservés Page : 13/28
4.2.1.2 La couche « services »
4.2.1.2.1 Framework d’Injection de dépendances - Spring
Spring est un outil complet et complexe qui implémente, entre autres, le design pattern « Dependency Injection », anciennement appelé « Inversion of Control » (IoC).
Spring peut également être mis en œuvre afin de faire de l’AOP (Programmation Orientée Aspect).
Dans le cadre du socle technique, nous utiliserons Spring 3.0
De façon macro, Spring sera utilisé de la façon suivante :
Les différentes autres librairies sont également déclarées via Spring :
Moteur d’ordonnancement Quartz
4.2.1.2.2 Spring security
Le Framework Spring-Security (anciennement Acegi) est un Framework de sécurité qui permet de gérer les 2 grandes problématiques liées à la sécurité applicative :
Qui es-tu toi qui parles à mon application ? Ça c'est l'authentification
Qu'as-tu le droit de faire avec mon application ? Ça c'est l'autorisation
4.2.1.2.3 Apache CXF (Web Services)
Apache XCF (http://cxf.apache.org/) anciennement XFire , est le Framework de Web Services la plus complet et le plus performant.
Il peut être utilisé conjointement avec Spring, afin d’exposer directement des Services POJO Spring en tant que Web Services.
Paramétrage hibernate
Paramétrage spring
Services
Objets métiers
Interfaces IHM
Figure 5 : Spring - IOC
Guide de développement
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx Document confidentiel © Copyright 2012 JeetConsulting, tous droits réservés Page : 14/28
4.2.1.2.4 Dozer
Dozer (http://dozer.sourceforge.net/) est un Framework qui permet la transformation de graphe d’objets.
4.2.1.2.5 Activi
Activiti est un projet open source de gestion des processus métier (BPM), lancé en 2010 sous licence Apache, pour implémenter le nouveau standard BPMN 2.0 de l’OMG (Object Management Group) et pour permettre de supporter de manière optimale les nouveaux défis technologiques comme l’interopérabilité et le mode cloud.
L’environnement de développement est constitué en son centre d’une usine de développement qui
permet de tenir les objectifs suivants :
Automatiser le maximum de taches dans le processus d'échanges MOE/MOA Donner de la visibilité du travail des équipes pour la direction. S'assurer en permanence de la qualité et de l’intégrité du code produit.
Facilité la vie quotidienne du développeur en proposant une intégration avec son environnement de travail.
Sécuriser les droits d’accès aux différents outils.
4.2.1.2.6 SL4J
La gestion des logs s’effectue avec le Framework d’abstraction SL4j (http://www.slf4j.org/), cette couche d’abstraction sera utilisée conjointement avec l’implémentation Log4 (http://logging.apache.org/log4j/)
L’utilisation de sl4j remplace l’utilisation de commons-logging. Tout simplement parce que Commons
Logging a ses défauts. Le premier gros défaut de Commons Logging concerne le chargement de l'implémentation de journalisation. En effet, la recherche de l'implémentation se fait dynamiquement à l'implémentation via un système de classloader. Or cette méthode peut poser problèmes dans certaines situations, par exemple lorsque l'application utilise des classloaders personnalisés ou alors au sein d'une architecture OSGi. De plus, l'implémentation utilisée par Commons Logging peut causer des fuites mémoires.
4.2.1.3 La couche « Présentation »
4.2.1.3.1 GWT
GWT est un framework open source édité par Google ; il présente les caractéristiques suivantes :
Un framework web RIA (Rich Internet Application) open source Supporter par Google et par une communauté d’utilisateurs importante En voie de standardisation (JSR 404 proposée par Sun)
Très bonne scalabilité – Le serveur d’application est stateless ; c'est-à-dire qu’il ne gère pas de session au sens traditionnel MVC.
Un rendu utilisateur Web 2.0 à base d’AJAX Des avancées par rapport à l’ergonomie des applications web traditionnelles : possibilité de
faire du « multi desktop », du multi-fenêtrage De nombreux composants graphiques beaux et efficaces
Guide de développement
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx Document confidentiel © Copyright 2012 JeetConsulting, tous droits réservés Page : 15/28
Une approche de développement qui génère des gains de productivité importants Développer la couche présentation en java / Compiler le Java en Javascript/CSS => Rapidité
de développement et Support natif multi-navigateurs Mode Host pour faciliter le debug (modifications à la volée de l’application) Possibilité de développer des composants graphiques métiers réutilisables Facile à appréhender pour des développeurs / utilisation des environnements de
développement classiques (Eclipse / Netbeans)
4.2.1.3.2 Ext-GWT
EXT-GWT est une librairie complémentaire de composants http://www.sencha.com/examples/#overview) qui permet de construire des IHMs avec des composants proches de ce que l’on pourrait réaliser avec une interface client lourd.
Figure 6 : Widgets EXT-GWT
4.2.1.3.3 Gilead
Dans le cas d’utilisation de GWT, Gilead (http://noon.gilead.free.fr/gilead/) , est un Framework qui permet d’utiliser directement les objets métiers dans la couche de présentation GWT.
L’emploi de la librairie Gilead est indispensable en termes de gain de temps de développement ; ne pas l’utiliser implique de développer des objets supplémentaires DTO ou Data
Transfer Object (à la fois pour le domainmodel et les services) et qui sont des objets purement
techniques (transfert de données vers la couche services / présentation) construits à partir des objets métiers correspondants.
Tandis qu'avec Gilead nous réutilisons les objets métiers existants définis au niveau du domainmodel => Gain en termes de temps de développement et de maintenance
4.2.1.3.4 Jasper Report
Guide de développement
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx Document confidentiel © Copyright 2012 JeetConsulting, tous droits réservés Page : 16/28
Nous proposons l’outil Open de génération des états JasperReport/IReport. Cet outil est considéré comme le plus fréquemment utilisé ces dernières années. En effet, JasperReport est le fruit d’une Communauté Open extrêmement forte qui a parfaitement compris le problème de reporting dans le domaine orienté objet et des structures XML (DOM), lesquelles restent incontournables pour réaliser des états conviviaux et sur mesure.
JasperReports est un moteur open source de reporting. Il permet via un studio graphique de
modéliser et mettre en page des rapports (création de templates à destination PDF, XML, CSV, …).
JasperReport existe sous forme de plugin Eclipse ce qui rend la solution de développement sous forme d’un package cohérent.
JasperReport prétend avoir été adopté pour plus de 3500 projets de développement.
Guide de développement
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx Document confidentiel © Copyright 2012 JeetConsulting, tous droits réservés Page : 17/28
5 REGLES DE DEVELOPPEMENT
5.1 Structure projet
La gestion de projets s’effectue par l’outils Maven, le respect de la structure standard des répertoires
Maven est à respecter.
Pour rappel :
Figure 7 : Structure Projet Maven
Le répertoire src contient plusieurs sous-répertoires, chacun avec une utilité précise :
src/main/java: Votre code java va ici (étonnamment) src/main/resources: Les autres ressources dont votre application a besoin
src/main/filters: Les filtres de ressources, sous forme de fichier de propriétés, qui peuvent être utilisés pour définir des variables connues uniquement au moment du build.
src/main/config: Les fichiers de configuration src/main/webapp: Le répertoire d'application web pour les projets WAR. src/test/java: Les tests unitaires src/test/resources: Les ressources nécessaires aux tests unitaires, qui ne seront pas
déployées src/test/filters: Les filtres nécessaires aux tests unitaires, qui ne seront pas déployées src/site: Les fichiers utilisés pour générer le site web du projet Maven
5.2 Règles de nommage des Fichiers
5.2.1.1 Classe
Les règles de nommage doivent respecter les règles définies par Sun.
Les Classes doivent posséder un nom explicite afin de pouvoir les retrouvées rapidement.
Couche persistence :
Les interfaces Dao sont suffixées par « Dao »
Leurs implémentations sont suffixés par « JpaDao » dans le cas d’un ORM type JPA.
Guide de développement
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx Document confidentiel © Copyright 2012 JeetConsulting, tous droits réservés Page : 18/28
Couche Service :
Les interfaces Service sont suffixées par «Service »
Leurs implémentations sont suffixées par « ServiceImpl »
Couche Présentation :
Les Controllers de type MVC sont suffixés par « Controller »
5.2.1.2 Package
Les noms de packages sont toujours en minuscules.
Afin de pouvoir se déplacer rapidement dans les différentes couches d’un projet, on essaye autant que cela soit possible d’organiser les packages entre les différentes couches de manière symétrique :
Considérons un objet métier Application dans le package
com.at20.atam.domainmodel.application.iApplication
Sur la couche persistence nous aurons :
com.at20.atam.dao.application.ApplicationDao
com.at20.atam.dao.application.jpa.ApplicationJpaDao
Sur la couche service :
com.at20.atam.service.application.ApplicationService
com.at20.atam.service.application.impl.ApplicationServiceImpl
Sur la couche présentation suivant le Framework utilisé, nous pourrions avoir différentes nommage :
o Présentation MVC classique :
com.at20.atam.presentation.web.controller.application
o Présentation GWT :
o Pour l’Interface :
com.at20.atam.presentation.web.gwt.<module-gwt>.client.ui
o Pour le Remote Service (on reprend le nom du package de la couche service)
com.at20.atam.presentation.web.gwt.<module-gwt>.client.service.application
5.2.1.3 Fichier de configuration Spring
Guide de développement
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx Document confidentiel © Copyright 2012 JeetConsulting, tous droits réservés Page : 19/28
Le nom des fichiers de configurations Spring doivent être de la forme suivante :
applicationContext-<nom-application>-<module>-<couche>.xml
Concernant le fichier de définissant les différents ressources (le fichier est unique dans l’application) :
applicationContext-<nom-application>-resources.xml
5.3 Règles de codage
Les règles définies ci-dessous, sont surveillé en permanence par le processus d’intégration continue qui contrôle le respect des bonnes pratiques décrit dans ce document.
5.3.1 Encodage
Tous les codes sources doivent être en UTF-8. Afin de ne pas le vérifier à chaque fois, il est préférable de positionner directement le Workspace en UTF-8, pour cela sous Eclipse :
Windows -> Eclipse -> General - > Workspace -> Positionner le Text File Ecoding sur UTF-8
5.3.2 Formatage du code
5.3.2.1 Formatage Source
Un Formateur a été spécialement défini, il est disponible à cette adresse : xxxxxx
Utiliser systématiquement le formateur sur les fichiers Java.
Ne jamais commiter un fichier non formaté : les mises en formes futures apparaîtraient comme des différences cachant les vraies modifications de version à version.
Afin d’éviter que les fichiers ne soit pas formaté, il est nécessaire d’activer l’option Format Source Code sur l’action de sauvegarder. Ce paramétrage est défini dans le chapitre Nouvel Arrivant.
s
5.3.2.2 Entête des fichiers sources
Mettre l'en-tête dans tous les fichiers sources.
Un code Template a été spécialement défini, récupérer le fichier codetemplates.xml à l’adresse xxxxxx, et l'importer dans Eclipse (Window -> Préférences -> java -> Code Style -> Code Templates).
Mettre des accolades ouvrantes et fermantes pour tout bloc, même pour 1 ligne.
5.3.2.3 Tri des méthodes
Avant de commiter, il est important d’effectuer un tri des méthodes via Eclipse.
Remarque : Attention de sélectionner dans TOUS LES CAS la première option « Do no sort fields, enum constant an initializers », car dans le cas contraire le tri pourrait affecter le comportement de l’initialisation ainsi que de la persistance de l’objet le cas échéant.
5.3.3 Règle de nommage
Les règles de nommage doivent respecter les règles définies par Sun
Guide de développement
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx Document confidentiel © Copyright 2012 JeetConsulting, tous droits réservés Page : 20/28
Ne pas écrire les méthodes des accesseurs à la main. Les générer avec Eclipse.
5.3.4 Documentation
Chaque méthode doit être clairement décrite dans la Javadoc. Utiliser cet emplacement pour décrire les pré-conditions d'appel de la méthode.
Optimiser les commentaires : ils doivent permettre de naviguer plus rapidement dans une méthode en la découpant en unités de traitements. Exemple : remontée des informations, Parcours de la liste
remontée pour en extraire les informations utiles, ... sont des commentaires ayant la granularité adéquate. Un commentaire par ligne rend le code illisible. Des commentaires supplémentaires doivent être ajoutés pour expliciter les points «difficiles» du code (algorithmes, code «technique», ...).
5.3.5 Communication des différentes couches
Afin que l’architecture en couche reste efficace et utile, il est important de respecter les règles de
communication entre ces différentes couches.
Cette communication s’effectue toujours de couche en couche
5.3.5.1 Communication Service Métier Simple
Figure 8 : Communication Service Simple
Guide de développement
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx Document confidentiel © Copyright 2012 JeetConsulting, tous droits réservés Page : 21/28
Figure 9 : Communication Service Complexe
5.3.6 Gestion des exceptions
5.3.6.1 Exceptions
<TODO>
5.3.6.2 Catch Exception
Les « Catch » génériques des exceptions sont à proscrire, chaque traitement de type d’Exception devra être explicite.
5.3.7 Log
La gestion des logs s’effectue avec le Framework d’abstraction SL4j (http://www.slf4j.org/), cette
couche d’abstraction sera utilisée conjointement avec l’implémentation Log4 (http://logging.apache.org/log4j/)
L’utilisation de sl4j remplace l’utilisation de commons-logging. Tout simplement parce que Commons Logging a ses défauts. Le premier gros défaut de Commons Logging concerne le chargement de
l'implémentation de journalisation. En effet, la recherche de l'implémentation se fait dynamiquement à l'implémentation via un système de classloader. Or cette méthode peut poser problèmes dans certaines situations, par exemple lorsque l'application utilise des classloaders personnalisés ou alors au sein d'une architecture OSGi. De plus, l'implémentation utilisée par Commons Logging peut causer des fuites mémoires.
Guide de développement
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx Document confidentiel © Copyright 2012 JeetConsulting, tous droits réservés Page : 22/28
Remarque : Pour satisfaire cette règle, il est important d’exclure des dépendances des applications, la dépendance commons-logging. Notamment sur les dépendances.
5.3.8 Ressources
Toutes les ressources externes aux applications doivent être pouvoir configurable en fonction des
différents environnements. Cette gestion de configuration est réalisé par la gestion des profiles de Maven.
5.3.8.1 Datasource
Les connexions aux datasources sur les différents environnements (Intégration continue, Recette, Pré-Production et Production devront s’effectuer via JNDI, afin de garantir la sécurité sur les
identifiants de connexion aux bases de données.
D’une manière générale toutes les ressources utilisées ayant un caractère à risque en
termes de sécurité devront passer via l’utilisation de l’arbre JNDI du Serveur D’application.
5.3.8.2 Accès FileSystem
Tous les chemins d’accès à un ou des FileSystem(s) devront pouvoir être configurés.
L’utilisation de ce type de ressource doit être validée par Le Chef de Projet, afin de ne pas en faire une utilisation abusive.
5.3.8.3 Connexion Externe (Mail, Web Services …)
Toutes les paramètres de connexion (host, login, password), sur les serveurs de Mails, sur des serveurs de Web Services, devront pouvoir être configurés ; et de préférence via l’arbre JNDI du Serveur d’application quand les paramètres nécessitent un login/password.
5.3.8.4 Scheduler
Toutes expressions liées à l’utilisation d’un Scheduler (Cron Expression …), devront pouvoir être paramétrées.
5.3.9 Tests unitaires
L’inspection de la qualité du code passe également par les tests unitaires.
Figure 10 : Les différentes phases de tests
Guide de développement
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx Document confidentiel © Copyright 2012 JeetConsulting, tous droits réservés Page : 23/28
Nous n’imposons pas un fonctionnement TDD, mais chaque méthode doit être accompagnée un d’un test unitaire. Ce test doit être pertinent et pouvoir être en tout temps :
Le test doit être maintenu comme le code associé Le test ne doit pas dépendre de données de test de la base de données associée. Dans
certain cas, si cela n’est pas envisageable, on peut admettre une exception suite à l’approbation du chef de projet.
Le test doit être pouvoir exécuté localement ou sur le serveur d’intégration continue , ce qui impose dans certains cas l’utilisation des profils Maven pour la gestion des différents environnement d’exécution des tests unitaires.
Guide de développement
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx Document confidentiel © Copyright 2012 JeetConsulting, tous droits réservés Page : 24/28
6 NOUVEL ARRIVANT
Vous êtes nouvel arrivant, ce chapitre déroule les différentes étapes de la mise en place de votre environnement de travail.
6.1 Espace de travail
Avant de récupérer les sources de l’application concernée, Assurez-vous que vos répertoires de travails soient correctement configurés selon le schéma suivant :
6.2 Créer un nouveau Workspace
Une fois Eclipse exécuté, créer un nouveau Workspace dans le répertoire Workspace, nommez le par exemple « Default »
Positionnez de suite votre Workspace en UTF-8
6.2.1 Importer le « Formatteur » de sources pour l’application
Récupérer le Fichier à l’adresse suivante : Importer le Fichier importé : Windows -> Préférences -> Code Style -> Formatter -> Import Activer le profile importé par Défaut.
6.2.2 Importer le « Code Templates » de sources pour l’application
Récupérer le Fichier à l’adresse suivante : Importer le Fichier importé : Windows -> Préférences -> Code Style -> Code Templates->Import
6.2.3 Importer le fichier de configuration Checkstyle de sources pour l’application
Importer le Fichier importé : Windows -> Préférences ->Checkstyle -> New -> Remote
Configuration Dans Location indiquez l’adresse suivante : Activer par défaut le « jeet-checkstyle »
6.2.4 Exclure les fichiers de l’outil de versionning.
Certains fichiers ne doivent être jamais commités pour cela un ensemble de fichiers doit être exclu de l’outil de versionning.
Pour cela : Windows -> Préférences -> Team->Ignored Resources
Guide de développement
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx Document confidentiel © Copyright 2012 JeetConsulting, tous droits réservés Page : 25/28
Ajouter chacun des patterns suivants :
target , .project , .classpath , .pmd , .checkstyle
6.2.5 Configurer le formatage automatique
Dans la partie Java/Editor/Save Actions de Window/Preferences, on peut demander à ce que le code qu'on vient de modifier soit automatiquement formaté. À chaque Ctrl-S, le code modifié et
uniquement celui-ci va subir le formatage adéquat.
6.3 Import des projets
Pour Importer les nouveaux projets dans votre Workspace :
File -> Import -> SVN -> Checkout Projects from SVN Indiquer l’url du Repository de l’application concernée. Sélectionnez le ou les projets de l’application concernée.
Sélectionnez l’option « Chek out as project in the workspace »
Guide de développement
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx Document confidentiel © Copyright 2012 JeetConsulting, tous droits réservés Page : 26/28
Décocher l’option “Use default Workspace location”, et spécifier la location de votre
répertoire Sources de l’application concernée :
Si le projet n’est pas reconnu en tant que projet Maven :
Sélectionner tous les dossiers et faire un clic droit .
Ne pas cocher « Delete project contents on disk » .
Guide de développement
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx Document confidentiel © Copyright 2012 JeetConsulting, tous droits réservés Page : 27/28
File -> Import ->Existing Maven Project
Indiquer le chemin de l’application concernée. Une fois le projet importer : clic droit -> Maven -> Update Project Configuration.
6.4 Exécuter les tests unitaires
Les applications peuvent avoir des ressources en mode Tests qui sont filtrés en fonction de l’environnement de Test, ce qui est vrai notamment pour l’intégration continue. Pour cela, avant de
pouvoir exécuter des tests unitaires Junit sur le poste de développement, il convient d’exécuter la phase test-process-resources de Maven ; pour faciliter cette tache, il vous faut créer un nouveau Maven Build :
Icon Run -> Run Configuration
Séléctionner Maven Build , puis créer un nouveau Run :
Guide de développement
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx Document confidentiel © Copyright 2012 JeetConsulting, tous droits réservés Page : 28/28
La variable ${project_loc} permet à Eclipse de sélectionner le projet à partir de la ressource active
Cocher la case « Resole Workspace Artefacts » , afin qu’Eclipse utilise les projets présent dans le Workspace comme dépendances vis-à-vis des dépendances de votre Repository local.
Remarque : Ce type de Run peut être effectué avec n’importe quel Goals de Maven , notamment pour des « install » sans exécution de tests unitaires.
6.5 Multiple IE
« Multiple IE installer » est un logiciel bien pratique qui permet d’installer des versions différentes d’Internet Explorer et toutes les lancer sans qu’il y’ait de conflit. Les différentes versions sont IE3, IE4.01, IE5.01, IE5.5 et IE6, elles sont bien sur toutes installées avec différents « fixs » propres à chaque version afin de corriger certains bugs.
Télécharger ce logiciel à partir de ce lien :
http://www.01net.com/telecharger/windows/Internet/navigateur/fiches/38617.html.