GUIDE DE DEVELOPPEMENT
ATAM
Guide de développement
PRECAUTIONS D’USAGE
Dès réception, le destinataire doit :
 Détruire les versions et révisions préc...
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

...
Guide de développement
Tableau 3 : Composants de l'usine de développement

8

Tableau 4 : Définition des dossiers du poste...
Guide de développement
1

INTRODUCTION

1.1

Contexte

Dire dans quel contexte on se place pour rédiger le document

1.2

...
Guide de développement
2

OBJECTIFS

L’ensemble des développements pour le projet ATAM sont encadrés par des normes et une...
Guide de développement
3

ENVIRONNEMENT DE DEVELOPPEMENT

L’environnement de développement est constitué en son centre d’u...
Guide de développement
Serveur D’application

Glassfish3

Sgbd

Postgres

Tests unitaires

Junit 4

Couverture de Tests

C...
Guide de développement
3.2.2

Structure répertoire Projects

Pour homogénéiser la structure des répertoires des différents...
Guide de développement
4

ARCHITECTURE APPLICATIVE

4.1
4.1.1

Architecture en couche
Définition

Lors de la conception d’...
Guide de développement
4.1.2.1

La couche « persistence »

Elle fournit les services de base nécessaires à la synchronisat...
Guide de développement
4.2

Socle Technique

4.2.1

Framework

Un ensemble de Framework ont été retenus pour constitués le...
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...
Guide de développement
4.2.1.2.4 Dozer
Dozer (http://dozer.sourceforge.net/) est un Framework qui permet la transformation...
Guide de développement






Une approche de développement qui génère des gains de productivité importants
Développer...
Guide de développement
Nous proposons l’outil Open de génération des états JasperReport/IReport. Cet outil est considéré
c...
Guide de développement
5

REGLES DE DEVELOPPEMENT

5.1

Structure projet

La gestion de projets s’effectue par l’outils Ma...
Guide de développement


Couche Service :
Les interfaces Service sont suffixées par «Service »
Leurs implémentations sont...
Guide de développement
Le nom des fichiers de configurations Spring doivent être de la forme suivante :
applicationContext...
Guide de développement
Ne pas écrire les méthodes des accesseurs à la main. Les générer avec Eclipse.
5.3.4

Documentation...
Guide de développement

Figure 9 : Communication Service Complexe

5.3.6

Gestion des exceptions

5.3.6.1

Exceptions

<TO...
Guide de développement

Remarque : Pour satisfaire cette règle, il est important d’exclure des dépendances des
application...
Guide de développement
Nous n’imposons pas un fonctionnement TDD, mais chaque méthode doit être accompagnée un d’un
test u...
Guide de développement
6

NOUVEL ARRIVANT

Vous êtes nouvel arrivant, ce chapitre déroule les différentes étapes de la mis...
Guide de développement
Ajouter chacun des patterns suivants :
target , .project , .classpath , .pmd , .checkstyle

6.2.5

...
Guide de développement



Décocher l’option “Use default Workspace location”, et spécifier la location de votre
répertoir...
Guide de développement



File -> Import ->Existing Maven Project




Indiquer le chemin de l’application concernée.
Un...
Guide de développement




La variable ${project_loc} permet à Eclipse de sélectionner le projet à partir de la
ressourc...
Prochain SlideShare
Chargement dans…5
×

atam guide de developpement v1.3

773 vues

Publié le

0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
773
Sur SlideShare
0
Issues des intégrations
0
Intégrations
2
Actions
Partages
0
Téléchargements
16
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

atam guide de developpement v1.3

  1. 1. GUIDE DE DEVELOPPEMENT ATAM
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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

×