- Règle de Non Regression des prototypes (RNR) -

Cette règle doit être considérée comme un garde-fou pour éviter que les programmeurs modifient les classes au gré de leur humeur d'un prototype à l'autre.

En effet, il ne faut pas oublier que la recette d'un prototype par les utilisateurs signifie qu'ils donnent leur accord sur le fonctionnement des programmes qu'ils ont eux-même testés. Procéder à de nouvelles modifications de ces programmes sans les en informer équivaudrait à une supercherie. Si par contre, ils sont informés de modifications, cela signifie qu'ils devront refaire tous les tests pour vérifier qu'aucune autre anomalie n'a été introduite en conséquence de ces modifications (tests de non régression). On ne peut pas croire un seul instant que les utilisateurs seront ravis d'apprendre cela. Quoi qu'il en soit, procéder à des tests de non-régression sur tous les prototypes précédents lors de chaque nouvelle livraison relève de la gageure. Tous les délais prévus seront largement dépassés et le projet tombera rapidement en déliquescence.

Donc, compte tenu de l'impossibilité que nous avons de réaliser tous les tests nécessaires, le non-respect de la RNR signifierait à coup sûr que l'on s'apprête à livrer un logiciel rempli de bogues. Par contre, son respect permettra d'une part de ne pas introduire de nouveaux bogues dans des programmes déjà testés, d'autre part de limiter les tests utilisateurs uniquement aux nouvelles fonctionnalités apportées par chaque nouveau prototype. Il y a fort à parier que cette règle sera bien accueillie par les utlisateurs.

Le problème à résoudre est alors de savoir comment nous allons procéder pour rajouter ou améliorer des fonctions sans toucher à celles déjà livrées. La réponse à ce problème se trouve dans les principes mêmes de la programmation orientée-objets et essentiellement dans deux possibilités offertes que sont l'héritage et le polymorphisme.

Lorsqu'une classe développée dans le prototype N-1 doit être complétée ou modifiée pour le prototype N (ajout d'attributs ou de méthodes, changement de comportement d'une méthode…), on procèdera en créant une nouvelle classe qui héritera de la précédente de façon à conserver les acquis, mais qui contiendra des caractéristiques complémentaires.

Afin de garder une trace précise de l'avancement du développement, il est conseillé de nommer les classes dérivées de la façon suivante : elles auront le même nom que la classe racine auquel on rajoute le numéro de prototype. Les classes du premier prototype peuvent également être suffixées par _1 pour garder une certaine homogénéité.

Exemple :

La classe racine Contrat_1 qui est définie dans le prototype 1 sera dérivée en Contrat_2 dans le prototype 2.

La classe racine Dossier_2 qui est définie dans prototype 2 sera dérivée en Dossier_4 dans le prototype 4 (dans ce cas Dossier_1 et Dossier_3 n'existeront pas).

Toutes les classes d'un même prototype seront regroupées dans un même paquetage afin d'assurer une bonne lisibilité de l'ensemble.

Afin de pouvoir accéder aux attributs des classes à partir de classes dérivées définies dans les prototypes ultérieurs, il est fortement conseillé de placer tous les attributs en mode "protected" ou bien de prévoir des méthodes accesseur (getters et setters) pour les attributs privés.

Les différents cas de dérivation d'une classe dans un nouveau prototype sont les suivants :

• Ajout de nouveaux attributs
• Ajout de nouvelles méthodes
• Redéfinition d'une méthode.

La redéfinition d'une classe pourra être envisagée pour trois raisons principales : pour étendre, pour restreindre ou pour optimiser.

Pour étendre : La nouvelle classe traite plus de cas que la précédente par ajout d'attributs et de méthodes (c'est le cas le plus fréquent).

Pour restreindre : Certaines méthodes limitent le nombre de cas traités par les méthodes d'origine.

Pour optimiser : Une nouvelle opération possède une méthode différente dans le but d'améliorer son exécution dans un environnement particulier (l'utilisation du Design Pattern Strategie permet de programmer cet aspect de façon élégante).

Inconvénients de la RNR

Il existe deux inconvénients à l'application de la RNR :

- une multiplication des classes car chaque évolution aportée à une classe entraîne la création d'une classe dérivée,

- l'apparition de code mort dans les classes des divers prototypes puisque chaque modification d'une méthode implique la création d'une nouvelle méthode polymorphe dans une classe dérivée.

Cependant ces deux inconvénients sont minimes comparés aux avantages procurés.

Avantages de la RNR

- obligation de mettre en oeuvre le principe d'ouverture/fermeture qui reste souvent un voeu pieux,

- limitation des tests de non régression aux fonctionnalités du dernier prototype développé,

- possibilité de rejouer un prototype quelconque dans l'état de sa recette (ceci est très utile si des tests de non regression doivent être mis en oeuvre),

- conservation de l'historique de développement qui pourra être parfois utile lors des opérations de maintenance corrective,

- facilitation de la maintenance évolutive qui s'effectuera à partir du dernier prototype recetté et pourra faire l'objet d'un nouveau prototype appelé "version".