atam guide de developpement v1.3

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


1.3

24/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


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


Page : 3/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


Page : 4/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
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


Page : 5/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.


Page : 6/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 :






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


Page : 7/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


Page : 8/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.
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.


Page : 9/28

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

Page : 10/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.


Page : 11/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.

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


Page : 12/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 :

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.


Page : 13/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
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




Page : 14/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


Page : 15/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.


Page : 16/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.


Page : 17/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

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


Page : 18/28

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


Page : 19/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


Page : 20/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,
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.


Page : 21/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


Page : 22/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.


Page : 23/28

6

NOUVEL ARRIVANT

Vous êtes nouvel arrivant, ce chapitre déroule les différentes étapes de la mise en place de votre

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


Page : 24/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 »


Page : 25/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 » .

.


Page : 26/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 :


Page : 27/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.


Page : 28/28

atam guide de developpement v1.3

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie atam guide de developpement v1.3

Ähnlich wie atam guide de developpement v1.3 (20)

atam guide de developpement v1.3