Mais conteúdo relacionado
Semelhante a atam guide de developpement v1.3 (20)
atam guide de developpement v1.3
- 2. Guide de développement
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.
DO C U ME NT ET A BL I SO U S L A RES PO N S AB I L I TE DE S S I G N AT A IR ES
Rédaction
Vérification
Approbation
Nom : Nicouleau Sébastien
Nom : : Nicouleau Sébastien
Nom :
Date : 27/04/2012
Date : 14/05/2012
Date :
Signature :
Signature :
Signature :
H IS T O R IQ U E DE S VE RS IO N S
Aprè s ré daction, tou t docu men t doit être approu vé pour être diffusé e t applicable .
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
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx
Document confidentiel
© Copyright 2012 JeetConsulting, tous droits réservés
Page : 2/28
- 3. Guide de développement
Sommaire
1
INTRODUCTION
5
1.1
Objectif du document
5
1.3
Documents de référence
5
1.4
3
5
1.2
2
Contexte
Lexique
5
OBJECTIFS
6
ENVIRONNEMENT DE DEVELOPPEMENT
7
3.1
Usine de développement
7
3.2
Poste de développement
8
3.2.1
8
3.2.2
Structure répertoire Projects
9
3.2.3
4
Structure des répertoires de travail
IDE
9
ARCHITECTURE APPLICATIVE
4.1
4.1.1
4.1.2
4.2
4.2.1
5
Architecture en couche
Définition
Décomposition Logique
10
10
10
10
Socle Technique
12
Framework
12
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
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
6
Encodage
Tests unitaires
NOUVEL ARRIVANT
22
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
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx
Document confidentiel
© Copyright 2012 JeetConsulting, tous droits réservés
Page : 3/28
- 4. Guide de développement
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
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx
Document confidentiel
© Copyright 2012 JeetConsulting, tous droits réservés
Page : 4/28
- 5. Guide de développement
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
Livraison Jeet Consulting.pdf
V
1.12
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
ATAM
Classe de service
Métadonnées
Définition
Application de Traitement des Archives Mixtes
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.
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 État déclaratif des catégories d’éléments éligibles à une conservation durable produit par
ou
Tableau
de 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
gestion
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
Versement
l’application de traitement des archives.
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
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx
Document confidentiel
© Copyright 2012 JeetConsulting, tous droits réservés
Page : 5/28
- 6. Guide de développement
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.
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx
Document confidentiel
© Copyright 2012 JeetConsulting, tous droits réservés
Page : 6/28
- 7. Guide de développement
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 :
3.1
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.
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
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx
Document confidentiel
© Copyright 2012 JeetConsulting, tous droits réservés
Page : 7/28
- 8. Guide de développement
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
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx
Document confidentiel
© Copyright 2012 JeetConsulting, tous droits réservés
Page : 8/28
- 9. Guide de développement
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.
2.
3.
4.
Subclipse (http://subclipse.tigris.org/) pour la communication avec l’outil de versioning
Mylin pour avoir le suivi des anomalies de l’outil de Bug Tracker
SpringIde (http://springide.org/blog/)
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.
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx
Document confidentiel
© Copyright 2012 JeetConsulting, tous droits réservés
Page : 9/28
- 10. Guide de développement
4
ARCHITECTURE APPLICATIVE
4.1
4.1.1
Architecture en couche
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 :
Communicatio
n
Créé
Services
spécialisés
IHM
active
Services
commun
s
active
Persistanc
e
Manipule
Manipule
Appelle
Métier
BO Objets
métiers
Synchronis
e
Contrôleur
IHM - CR
BR
Ecrans
Service
Utilis
e
VO
Données à
afficher
Contrôle
DS
Service de
persistance
Synchronise
Appelle
Utilis
e
Services
d’écoute
Contrôleur
active Messages CR
Services
spécialisés
messages
Manipule
Base de
données
Figure 4 : Architecture logique en couche
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx
Document confidentiel
© Copyright 2012 JeetConsulting, tous droits réservés
Page : 10/28
- 11. Guide de développement
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.
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx
Document confidentiel
© Copyright 2012 JeetConsulting, tous droits réservés
Page : 11/28
- 12. Guide de développement
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.
Services Métiers POJO
Gilead
Domain model
Injection de dépendances
Services Métiers
Spécialisés Editique
Activiti - Workflow
Librairies Apache Commons
Spring
Services Métiers Spécialisés
IHM
Gestion des droits
WebServices
(API)
SpringSecurity
Jasper Reports –
Editique /Reporting
GTW + EXT-GWT
Couche vue
/ contrôleur
Couche
Services
Spring - Data
JPA – Couche d’abstraction
Couche
Persistence
Hibernate
Hibernate-Envers (Piste d’audit)
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
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx
Document confidentiel
© Copyright 2012 JeetConsulting, tous droits réservés
Page : 12/28
- 13. Guide de développement
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 :
Objets
métiers
Paramétrage
hibernate
IHM
Interfaces
Services
Paramétrage
spring
Figure 5 : Spring - IOC
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
plus complet et le plus performant.
le Framework de Web Services la
Il peut être utilisé conjointement avec Spring, afin d’exposer directement des Services POJO Spring
en tant que Web Services.
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx
Document confidentiel
© Copyright 2012 JeetConsulting, tous droits réservés
Page : 13/28
- 14. Guide de développement
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
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx
Document confidentiel
© Copyright 2012 JeetConsulting, tous droits réservés
Page : 14/28
- 15. Guide de développement
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
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx
Document confidentiel
© Copyright 2012 JeetConsulting, tous droits réservés
Page : 15/28
- 16. Guide de développement
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.
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx
Document confidentiel
© Copyright 2012 JeetConsulting, tous droits réservés
Page : 16/28
- 17. Guide de développement
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.
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx
Document confidentiel
© Copyright 2012 JeetConsulting, tous droits réservés
Page : 17/28
- 18. Guide de développement
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
5.2.1.3
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
Fichier de configuration Spring
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx
Document confidentiel
© Copyright 2012 JeetConsulting, tous droits réservés
Page : 18/28
- 19. Guide de développement
Le nom des fichiers de configurations Spring doivent être de la forme suivante :
applicationContext-<nom-application>-<module>-<couche>.xml
Concernant le
l’application) :
fichier
de
définissant
les
différents
ressources (le
fichier
est
unique
dans
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
5.3.2.1
Formatage du code
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
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx
Document confidentiel
© Copyright 2012 JeetConsulting, tous droits réservés
Page : 19/28
- 20. Guide de développement
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
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx
Document confidentiel
© Copyright 2012 JeetConsulting, tous droits réservés
Page : 20/28
- 21. Guide de développement
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,
devra être explicite.
5.3.7
chaque traitement de type d’Exception
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.
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx
Document confidentiel
© Copyright 2012 JeetConsulting, tous droits réservés
Page : 21/28
- 22. Guide de développement
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
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx
Document confidentiel
© Copyright 2012 JeetConsulting, tous droits réservés
Page : 22/28
- 23. Guide de développement
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.
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx
Document confidentiel
© Copyright 2012 JeetConsulting, tous droits réservés
Page : 23/28
- 24. Guide de développement
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
6.2.2
6.2.3
6.2.4
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.
Importer le « Code Templates » de sources pour l’application
Récupérer le Fichier à l’adresse suivante : Importer le Fichier importé :
Préférences -> Code Style -> Code Templates->Import
Windows ->
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 »
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
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx
Document confidentiel
© Copyright 2012 JeetConsulting, tous droits réservés
Page : 24/28
- 25. Guide de développement
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 »
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx
Document confidentiel
© Copyright 2012 JeetConsulting, tous droits réservés
Page : 25/28
- 26. Guide de développement
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 » .
.
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx
Document confidentiel
© Copyright 2012 JeetConsulting, tous droits réservés
Page : 26/28
- 27. Guide de développement
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 :
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx
Document confidentiel
© Copyright 2012 JeetConsulting, tous droits réservés
Page : 27/28
- 28. Guide de développement
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.
Référence : 20120524-ATAM-Guide-De-Developpement-V1.3.docx
Document confidentiel
© Copyright 2012 JeetConsulting, tous droits réservés
Page : 28/28