La phase I de l'industrialisation peut-être divisée en trois chantiers indépendants :

• Contrôle de syntaxe et de cohérence des éléments entrants
• Robustification et normalisation du code
• Mise à disposition et complétion de la documentation

Pour chacun de ces chantiers nous allons décrire les actions à mettre en place et l'ordre de mise en place

Ce chantier peut-être subdivisé en deux parties :

• Réalisation d'une classe de test indépendante permettant de tester le contenu d'une famille Dynacase avant son importation
• Intégration de cette classe dans le contenu existant, notamment lors de l'étape d'import d'une classe

Pour ce faire, un nouvelle classe sera intégrée dans Dynacase, cette nouvelle classe permettra de tester la cohérence et la syntaxe des éléments composants une famille.

• Cette classe sera composée des structures de données adéquates pour stocker l'ensemble des éléments d'une familles dans une de ses instances.
  
• Cette classe possédera deux fonctions publiques principales :
  • Une fonction de test de la syntaxe
  • Une fonction de test de la cohérence

Ces fonctions retourneront un tableau associatif contenant les données suivantes :

• intitulé du test : chaîne de caractère
• résultat du test : Erreur/Alerte/OK
• commentaire : chaine de caractère contenant un commentaire permettant de résoudre le problème s'il y a lieu
• De plus, un ensemble de fonction publique annexes seront mises en place :
• des getteurs et des setteurs pour l'ensemble des attributs de la classe ayant attrait aux éléments de la famille en cours
• une fonction par test décrit dans la spécification d'industrialisation qui a le même retour que les fonctions principales
• une fonction de log permettant de tracer les résultats d'un test passé en entrée dans le log applicatif de Dynacase
• une fonction de transformation du résultat d'un test en chaine de caractère utilisable pour l'affichage en CLI
• une fonction de transformation du résultat d'un test en html utilisable pour l'affichage en HTML

Optionnel : De plus, la classe sera accompagnée d'une classe de test unitaire permettant de tester toutes ces fonctions publique permettant de s'assurer de la fiabilité de chacun des tests tout au long de versions de Dynacase (notamment pour les tests de cohérence)

Faible : la classe crée étant nouvelle est aucune classe ne dépend de celle-ci en tant que tel

Aucun

La classe de test sera intégrée au fonctionnement de Dynacase via deux moyens :

• Dans le fonctionnement de Dynacase lors de l'importation de famille
• Via une une action permettant de vérifier un fichier ODT ou CSV soit en CLI soit en HTTP

Faible : pour la création de l'action Important/Moyen : pour l'intégration de la classe dans le processus d'import de Dynacase

Il faut analyser les éléments importés dans les applications des versions précédentes via l'action mise en place et corriger les éventuels points invalides

Cette partie peut-être découpée en trois phases distinct :

• Norme de codage et mise en conformité du code
• Gestion des erreurs et des comportements inattendus
• Niveau de log/Verbosité

Cette étape peut être décomposée en deux sous étapes indépendantes :

• Utilisation de la norme de codage PEAR et mise en conformité du code existant
• Mise en place de l'encapsulation, de la distinction des méthodes internes externes et respect de la compatibilité du code avec le niveau E_STRICT

La norme de codage PEAR est utilisée sur le projet Dynacase, il faut donc mettre en place les points suivants :

1. Vérifier et mettre à jour si besoin le coding style de Zend pour qu'il prenne en compte la norme PEAR
2. Analyser le code de Dynacase grâce à l'outil http://pear.php.net/package/PHP_CodeSniffer/ pour détecter les points ne respectant pas la norme
3. Corriger le code de Dynacase ne respectant pas la norme soit manuellement, soit à l'aide de Zend
4. Analyser le code de Dynacase modifié pour vérifier que tous les points ne respectant pas la norme ont été traités

Moyen : difficulté de faire des diff entre la version mise en conformité et les versions précédentes plus un faible risque de régression

Néant

Différents autres éléments sont mis en place pour permettre de rendre le code plus robuste et plus lisibles sans pour autant apporter de fonctionnalités :

1. Localiser dans chaque classe les attributs non encapsulés et les passer en private puis les encapsuler (à l'aide des fonctions de génération de get et set de Zend ou manuellement)
2. Analyser le code Dynacase pour localiser tous les appels aux éléments non encapsulé et modifier le code pour le rendre compatible
3. Vérifier le fonctionnement de la classe après modification

Élevé : risque de régression

Fournir la liste des attributs qui ne sont plus utilisables tel quel pour les différentes classes de Dynacase + un outil parsant le code et indiquant les éventuels problèmes (toutes les occurences →nom_d_un_attribut_plus_accessible)

1. Lister les méthodes de chaque classe qui sont maintenu tel quel (entrants et sortants) par Dynacase (méthode public/accessible pour le développement d'application Dynacase)
2. Préfixer toutes les autres méthodes par INT_ et indiquer dans le descriptif de la méthode quelle est interne
3. Chercher dans le code toutes les occurrences aux méthodes internes et les préfixer par INT_

Élevé : risque de régression

Fournir la liste des méthodes qui ne sont plus utilisables les différentes classes de Dynacase + un outil parsant le code et indiquant les éventuels problèmes (toutes les occurrences →nom_d_un_attribut_plus_accessible)

1. Mise en place au niveau de index.php et de wsh.php d'un error_handler qui intercepte l'ensemble des erreurs déclenchés qui ne respectent pas le niveau de compatibilité et qui les stocke dans un fichier de log spécifique

Faible : risque de régression

Aucun

Un système permettant la gestion des erreurs et des comportements inattendus est mis en place, pour cela il faut :

1. Lister les fonctions permettant d'accéder ou de modifier un attribut ou une famille ou un paramètre (voir methode_get_et_set.ods)
2. Créer une classe d'exception Dynacase dans un fichier à part
3. Intégrer les tests correspondant aux exigences présentés dans les fonctions listés en 1 et déclencher soit l'erreur soit l'exception attendue (voir spécification fonctionnelle pour le détail)
4. Mettre à jour le descriptif de la méthode

Moyen : risque de régression

Fournir la liste des méthodes impactées avec les comportements prévu pour chacune de ces méthodes

1. Création d'une classe de log applicatif (utilisation de Zend_log http://zendframework.com/manual/fr/zend.log.html)
2. Ajout d'un paramètre dans Dynacase indiquant l'emplacement et le mode de stockage des logs applicatifs
3. Ajout d'un emplacement de consultation des logs dans Dynacase-control par contexte (voir le mode de fonctionnement de ZendServeur dans la gestion du error.log de apache2)
4. Ajout d'un support de FirePHP à la classe de log applicatif (voir http://www.firephp.org/Wiki/)

Faible : risque de régression

Aucun

1. Création d'une classe de log technique (utilisation de Zend_log http://zendframework.com/manual/fr/zend.log.html)
2. Ajout d'un paramètre dans Dynacase indiquant l'emplacement et le mode de stockage des logs techniques, ajout d'un paramètres indiquant le niveau de log désiré
3. Ajout d'un emplacement de consultation des logs dans Dynacase-control par contexte (voir le mode de fonctionnement de ZendServeur dans la gestion du error.log de apache2)
4. Ajout d'un support de FirePHP à la classe de log techniques (voir http://www.firephp.org/Wiki/)

Impact Faible : risque de régression

Éléments pour la compatibilité Aucun

1. Lister les fonctions permettant d'accéder ou de modifier un attribut ou une famille ou un paramètre (voir methode_get_et_set.ods)
2. Ajouter une fonction de log applicatif dans chaque fonction ne se déclenchant qu'en mode Debug et effectuant ce qui est décrit dans les exigences PHP_LOG_04 et PHP_LOG_05

Impact Faible : risque de régression

Éléments pour la compatibilité Aucun

1. Lister les méthodes spécifiques aux documents (voir PHP_LOG_06)
2. Ajouter une fonction de log applicatif dans chaque fonction ne se déclenchant qu'en mode Debug et effectuant ce qui est décrit dans les exigences PHP_LOG_06

Impact Faible : risque de régression

Éléments pour la compatibilité Aucun

1. Identifier l'emplacement où s'effectue les appels aux fonctions spécifiques aux familles des applications []
2. Instrumenter cette partie du code pour identifier les appels aux fonctions contrainte et d'attribut calculé
3. Identifier l'emplacement où s'effectue les appels aux fonctions d'aide à la saisie
4. Instrumenter cette partie du code

Impact Faible : risque de régression

Éléments pour la compatibilité Aucun

1. Identifier le(s) emplacement(s) où s'effectue les appels aux actions
2. Instrumenter cette partie du code

Impact Faible : risque de régression

Éléments pour la compatibilité Aucun