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

(c) 2005 - Alexandre Brillant

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 :

  1. Assimilation de la syntaxe et des bibliothèques
  2. Assimilation des concepts objets
  3. Assimilation des impacts de développements

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

- Causes :

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

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

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

- Conséquences :

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

b. Absence de design

Causes :

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

Conséquences :

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

c. Mauvaises ressources

Causes :

Conséquences :

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 à :

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