Cette documentation ne peut pas être employée dans le cadre d'un cours ou d'une formation sans mon accord.

Objectif : Amélioration du codage par l'application de règles de programmation et une meilleure distribution des travaux par un framework.

Plan

I. Erreurs fréquentes :

a. Répétition du code (Effet Copier/Coller)

b. Absence de design

c. Mauvaise gestion des ressources

II. Solution :

a. "Modèle OSI" pour le développement

III Un exemple concret

a. Présentation du framework Airial

b. Exemple de code applicatif

I. Erreurs fréquentes :

3 niveaux :

Assimilation de la syntaxe et des bibliothèques
Assimilation des concepts objets
Assimilation des impacts de développements

a. Répétition du code (Effet Copier/Coller)

- Causes :

Sous - évaluation de la maintenance du code
Mauvaise maîtrise de la conception objet
Mauvaise structuration du code
Algoritme inadéquate
Code non maîtrisé d'un autre travail
Volonté de simplifier en répétant un code simple
Ré-architecture pour optimiser les performances
Contraintes de temps

La répétition du code peut être présente :

Dans une même classe : Si la classe n'est pas trop grande l'auteur conserve visuellement les répétitions en mémoire
Dans un même package : L'auteur ne souhaite pas utiliser de code statique
Entre différents packages : Circulation d'un code vers le même ou d'autres auteurs.

- Conséquences :

Mauvaise évolution du code (déficite de design)
Absence de réactivité
Accroissement de la complexité
Perte enorme de temps à corriger les bugs
Difficulté de compréhension des classes
Difficulté de retro-analyse des classes
Impossibilité de faire des tests unitaires efficaces
Risque de régression du code à chaque version
Incompatibilité avec le code précédent
Dispersion du code et des algorithmes
Ré-écriture des parties trop complèxes
Conception empirique
Ajout de code "de raccord"
Diminution des performances
Inadaptation au contexte (norme...)

b. Absence de design

Causes :

Manque de connaissance objet
Sous-évaluation de l'évolution du code
Sur-évaluation de la complexité objet
Pas de volonté de réutilisation <=> "code one shot"
Transcription des concepts d'un autre langage vers un autre (C vers Java)
Focalisation des développeurs sur la syntaxe et les bibliothèques
Manque de visibilité sur la plate-forme de conception (pas de vision d'ensemble)
Pas de transcription de concepts utilisation (toolkit, framework...)
Support sur des outils de générations de code (vaj, jbuilder...)

Conséquences :

Accroissement de la complexité du code
Absence de réactivité sur une demande d'évolution/correction
Indaptation à un code étranger
Ré-écriture du code à terme
Absence de visibilité du code
Pas de partage du code
Perte de temps sur la correction des bugs
Tests unitaires difficiles
Code réservé à des couches applicatives
Diminution de la coopération entre développeurs

c. Mauvaises ressources

Causes :

Pas de libération des handles de fichiers
Pas de libération des connexions de base de données
Occupation mémoire (collection...)
Allocation d'objets
Mauvaise gestion des exceptions
Oubli de libération des ressources
Absence de règles de programmation

Conséquences :

Ecroulement du système à terme
Tests souvent insuffisants pour trouver le problème et phénomène de compensation
Risque d'accumulation des problèmes à court terme (correction/mauvais design...)

II. Solution :

L'idée est de reprendre le modèle OSI (Open System Interconnection) dans les développements en séparant les responsabilités et en controlant les interfaces entre les niveaux de responsabilités

a. "Modèle OSI" de développement

Ce découpage sert à :

Adapter le niveau de codage en fonction des développeurs
Réduire les risques de copier/coller en fournissant aux développeurs des services (base de données...)
Garantir l'évolution de l'architecture vers d'autres versions et normes
Optimiser l'efficacité des traitements
Condenser tous les traitements délicats
Réduire les risques d'absence de libération des ressources
Offrir une documentation homogène

- Couche physique :

Cette couche représente l'architecture retenue pour le projet (J2EE par exemple). Cette couche doit etre relativement stable.

- Couche technique :

Cette couche abstraite fait le lien entre la couche physique et la couche métier.

Elle n'a pas de connaissance métier.

Elle réduit la connaissance de la couche physique en prenant en compte les problèmatiques de design et d'exploitation de la couche physique.

Elle anticipe sur les évolutions de la couche physique.

Elle prévoit les montées en charge (cache...)

Elle propose des interfaces de manipulation de l'environnement physique

Les interfaces de cette couche doivent etre stables.

- Couche métier :

Cette couche a connaissance des objectifs du projet. Elle prépare le terrain en gérant les objets les plus complèxes à l'aide de la couche technique.

Cette couche est une début de l'implémentation.

Les interfaces de cette couche doivent etre relativement stables.

- Couche applicative :

Cette couche est l'objectif de tout projet. Elle doit s'appuyer sur la couche métier. Elle peut etre reservée à des analystes/programmeurs.

III Un exemple concret

Présentation d'un framework J2EE

- Hierarchie principale

Exemple de code applicatif

Ce code représente un ejb (session bean) retournant une liste de pays (code + libelle)

import fr.gouv.education.antares.framework.ejb.session.*;

public class UnSessionBean extends SessionBeanCollectorAdapter {

  public UnSessionBean() {
    super( StaticTable.DataSource, "Pays", new String[] { "code", "libelle" } );
  }

}

Exploitation dans un TagLib :

import fr.gouv.education.antares.framework.jsp.tagLib.*;

public class ListeDePays extends CollectionTag {
  super();
  setCollection( (getFrameworkObject().getSessionBean( StaticTable.UnSessionBeanID ).getCollection() ); 
}

Exploitation dans une JSP :

...
<html>

  ...

 <airial:pays>
   
<tr><td>${code}</td><td>${libelle}</td></tr>

 </airial:pays>

</html>

Résultat HTML :

...
<html>

  ...
   
<tr><td>FR</td><td>France</td></tr>

...

<tr><td>US</td><td>Etats-Unis d'amérique</td></tr>

</html>