Visualiser
publicité
Conseil, Etudes et Edition de logiciels NORMES & CONVENTIONS DE DEVELOPPEMENT JAVA ET SQL Table des matières Système d'exploitation ...................................................... Environnement de développement intégré ...................................... Le workspace ................................................................ Le serveur applicatif ....................................................... Règles de nommages des objets ............................................... Les tables .................................................................. Les colonnes ................................................................ Les index ................................................................... Introduction ................................................................ Normalisation des projets ................................................... Normalisation des noms de packages .......................................... Normalisation des noms de fichiers .......................................... Normalisation des noms des classes .......................................... Règles communes .......................................................... Nommage des objets métiers ............................................... Nommage des DAO .......................................................... Nommage des services .................................................... Nommage des Contrôleurs .................................................. Nommage des JSPX ......................................................... Normalisation des noms des méthodes ...................................... Normalisation des noms des variables ..................................... Normalisation des noms des constantes .................................... Taille limite des éléments .................................................... Organisation du code .......................................................... 183 avenue Georges Clemenceau – 92000 NANTERRE – Tél. : 01 40 90 97 71 E-mail : [email protected] – Site : http://www.phoenix-access.com Phoenix Access SARL au capital de 30 000 € - 417 781 028 RCS Nanterre - Code NAF 721 Z 3 3 3 3 4 4 5 5 5 6 6 6 6 6 6 7 7 7 7 8 8 8 9 9 1. Introduction Les normes sont importantes pour les développeurs, et ce pour différentes raisons : •La maintenance d’un logiciel représente environ 80% de son coût total, •Il est rare que la personne ayant développé le logiciel à l’origine le maintienne pendant toute sa durée de vie. •L’utilisation des normes permet d’accroître la lisibilité du code, tout en aboutissant à une industrialisation et à une standardisation du code. 2. Objectif du document Ce document décrit l'environnement de travail du poste de développement, et recense les normes, standards et conventions à appliquer lors des développements des projets. 3. Environnement de travail Système d'exploitation Le système d'exploitation du poste de développement est Microsoft Windows XP. Environnement de développement intégré L'environnement de développement utilisé est Eclipse : Eclipse IDE for Java EE Developers téléchargeable depuis : http://www.eclipse.org/downloads/packages/eclipseide-java-ee-developers/heliossr2. Plu-gins Plugin Jbosstools : pour installer ce plugin suivez l'une des deux procédures proposé sur cette page : http://www.jboss.org/tools/download/installation Le workspace L'environnement de développement nécessite la définition d'un espace de travail où est sauvegardé l'ensemble des codes sources des différents projets. Chaque développeur du projet dit disposer un répertoire nommé workspace. Le serveur applicatif Le serveur tomcat doit être installé sur chaque poste de développement. L'installable de tomcat est téléchargeable depuis: http://tomcat.apache.org/download-70.cgi#7.0.14 Remarque : Aucune bibliothèque autre que celles déjà existantes le répertoire tomcat\common\lib ne doit être copié. 4. Normes de réalisation SQL Règles de nommages des objets Les identifiants Les identifiants servent à nommer les objets SQL tels que : Tables, Procédures, Triggers… . Les règles syntaxiques générales qui s’appliquent à ces identifiants sont les suivantes : La longueur maximale d'un identifiant est de 50 caractères. Un nom d'identifiant commence nécessairement par une lettre. Les caractères qui peuvent être utilisés sont : les lettres non accentués, les chiffres, le caractère _ (underscore). Les tables Les seules contraintes existant sur les identifiants des tables sont la conformité aux règles syntaxiques générales des objets SQL. Toutefois, il est recommandé de respecter les bonnes pratiques suivantes : Le nom de la table doit être court et permettre d’identifier rapidement l’entité fonctionnelle concernée. Exemple : Poste, Pays, … Si le nom de la table est trop long pour une utilisation simple, une abréviation dont la signification reste aisée à déchiffrer peut être utilisée. Exemple : ImpBud pour Imputation Budgétaire Il est préférable, dans le cas d’un nombre important de tables, d’utiliser un préfixe de 3 caractères suivi du caractère souligné faisant référence à un domaine fonctionnel particulier. Ex : prv_budget pour budget prévisionnel, rea_budget pour budget réalisation. Les colonnes Le nom d’une colonne de table doit être court et permettre d’identifier rapidement l’information. Exemple : Nom, Adresse, … Le type de données de la colonne doit correspondre de préférence à un type de données utilisateur Chaque table possède une colonne identifiant considérée comme clé primaire. Son nom est défini sous la forme : <id> 5. Normes de réalisation Java/J2ee Introduction Chaque Mini projet développé est composée de deux parties : Une partie métier, qui implémente les fonctionnalités de l'application (données, traitements, règles de gestion), sachant que cette partie peut utiliser des parties métier tierces. Une partie interface (web) qui utilise la partie métier et qui représente la partie visuelle de l'application. Normalisation des projets Le répertoire principal du module applicatif est composé de deux sous-répertoires : un répertoire pour l'application métier, dont le nom est composé de la concaténation du code du mini projet et de CORE. Exemple : MP_HABILITATION_01_CORE. un répertoire pour l'application web, dont le nom est composé de la concaténation du mini projet et de RIA. Exemple: MP_HABILITATION_01_RIA. Le mini projet est un projet Maven, qui contient deux modules : le module CORE le module RIA. Les deux modules sont regroupe dans un parent. Normalisation des noms de packages Il est important de noter que le nom du package de l'application est celui utilisé dans le dossier de conception ; de plus, le package principal est nommé : com.gol . Normalisation des noms de fichiers Les fichiers JAVA ne contiennent qu’une seule classe (ou interface). Ainsi, le nom du fichier et le nom de la classe sont identiques. Normalisation des noms des classes La normalisation des noms de classes dans les packages est la suivante : Règles communes Les noms de classes commencent par une majuscule · Une majuscule doit être utilisée pour séparer des mots (il ne faut pas utiliser le caractère underscore ‘ _’) ex : MaClasse Nommage des objets métiers Un objet métier est une représentation atomique persistante (insécable), qui représente des informations persistantes. L'information persistante est sauvegardée dans un champ d'une table donnée dans le modèle physique. Le nom d'une classe d'objets métiers doit avoir le nom de la classe PIM (Plateform Independent Model) issue d'un diagramme de classe de l'analyse. Le comportement d'un objet métier est réduit à des méthodes d'accès en lecture et écriture des données encapsulées (attributs). Les seules méthodes permises à ce niveau sont de type getNomAttribut et setNomAttribut(Type valeur). Exemple : La classe Bien identifiée lors de la phase analyse a pour classe métier dans la partie réalisation la classe Bien, qui reprend les mêmes attributs et getters/setters. Nommage des DAO Un DAO est une classe d'objets qui manipule des objets métiers (persistants). Elle fournit un ensemble de méthodes de type CRUD, qui permettent de créer, sauvegarder, modifier, rechercher et supprimer des objets métiers. Elle dérive de la classe générique com.gol.socle.persistence.hibernate.AbstractHibernateGenericDao , et qui redéfinie les méthodes de manipulation CRUD des ObjetMetier. Nommage des services Les services métier « Business Service » Les Interface Homme Machine ne communiquent qu'avec des services métiers, qui implémentent la logique applicative, et ont accès aux DAO. A règle de nommage des contrôleurs est la suivante : tous les noms classes de la couche service doivent se terminer par «Service» Nommage des Contrôleurs Un contrôleur (managedbean) représente un flux d'informations en provenance d'une IHM. La couche JSF traduit les informations saisies dans un écran dans un bean. La règle de nommage des contrôleurs est la suivante : tous les noms contrôleurs doivent se terminer par « Controller » Nommage des JSPX Nom Type de page view Pour les pages d'affichage d'une entité edit Pour les pages de modification d'entité list Pour les pages de recherche d'entités Normalisation des noms des méthodes La normalisation des noms de méthodes est la suivante : Elles commencent par une lettre minuscule Normalisation des noms des variables La normalisation des noms de variables, valables également pour les instances d’objet, sont les suivantes : Elles commencent par une lettre minuscule, ex : maVariable Une majuscule est utilisée pour séparer plusieurs mots ex : maVariable les attributs de classe sont toujours accédés avec « this » ex : this.monAttributDeClasse Les arguments des fonctions sont préfixés par « arg » ex : argMonArgument Normalisation des noms des constantes La normalisation des noms de constantes est la suivante : Les noms de constantes sont toujours en lettre majuscule, o ex : CONSTANTE · Un caractère ( _ ) est utilisé MA_CONSTANTE_PI pour séparer plusieurs mots, exemple : Normalisation des noms des livrables Le formalisme des livrables est le suivant : Livrables Client : livrable-<nomprojet>-core-<X.Y>-aaaammjj.zip Livrables Serveur : livrable-<nomprojet>-all-<X.Y>-aaaammjj.war Livrables SGBD : livrable-<nomprojet>-ddl-<X.Y>-aaaammjj.zip avec <X.Y> au format suivant : X : version majeure Y : version mineure Taille limite des éléments Afin de conserver une bonne lisibilité du code source, la taille des éléments est limitée. La taille des différents éléments d'un code source java doit se conformer à règles suivantes : Un fichier (classe java ou autre) doit contenir moins de 1000 lignes. Taille des Une méthode doit contenir moins de 100 lignes. Dans un fichier, une ligne doit contenir moins de 50 caractères. Une méthode doit accepter au plus 7 paramètres.
