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





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



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



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



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.



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



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



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.

http://subclipse.tigris.org/

http://springide.org/blog/

http://m2eclipse.sonatype.org/

http://www.jboss.org/tools

http://checkstyle.sourceforge.net/



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



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.



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



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

http://cxf.apache.org/



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

http://dozer.sourceforge.net/

http://www.slf4j.org/

http://logging.apache.org/log4j/



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

http://www.sencha.com/examples/#overview

http://noon.gilead.free.fr/gilead/



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.



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.



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



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



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



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.

http://www.slf4j.org/

http://logging.apache.org/log4j/



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



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.



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



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 »



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 » .



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 :



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.

http://www.01net.com/telecharger/windows/Internet/navigateur/fiches/38617.html