coo poo 1 3 2 Fiabilite

Fiabilité: définition: C'est pas faux. Quand c'est faux, l'erreur est facile à localiser. Quand c'est faux c'est rapide à corriger. Quand c'est faux, ça ne se propage pas partout. Quand c'est faux, ça se voit facilement que c'est faux.

    La fiabilité vient d'une série de mesures de sécurité et de vigilance comprenant: la modularité, l'encapsulation, la séparation des modules, l'introduction de frontières et de garde-frontières, d'interfaces d'entrée sortie, de check-points, de la standardisation et normalisation, de lois, règles et interdictions (ex:interdit à deux modules de mettre à jour la même table).

Vérificabilité

    La modularité donne des frontières de modules.

    Les frontières de modules donnent des possibilités de checkpoint.

    L'existance de checkpoint donne la vérificabilité.

    La facilité de vérification donne la vitesse de développement, l'exactitude des résultats de tests, la sécurité de la mise en oeuvre et la qualité du logiciel livré.

Résistances aux propagation de bugs et aux pannes:

    L'encapsulation, le faible couplage entre modules, l'indépendance des objets, les coupe feux, les check-points donnent la résistance aux propagations de bugs.

    Si c'est faux dans un objet, le check point à la sortie le révèle.

    Si c'est faux à l'entrée, l'interface d'entrée le révèle car l'entrée est fixe, standardisée, normalisée, connue.

    Si c'est faux à l'extérieur, le bug ne peut pas entrer car l'entrée est gardée.

    Si le module est validé, ca ne peux plus être faux à l'intérieur car la fonctionnalité est fiabilisée.

    Si c'est faux par les données en entrée ca se voit facilement.

    Si c'est faux en aval, on ne peut soupconner la sortie de l'objet qui est fixe aussi et facilement vérifiable.

    Donc à chaque erreur, la zone de soupcon est réduite aux développements nouveaux, cela ne remet pas en cause les développements déjà validés. Dans un système non orienté objet toutes les lignes de codes sont suspects il n'y a pas de distinction entre lignes validées et lignes pas encore validées.

    Dans un programme sauvage, chaque erreur cause la revérification de toutes les lignes et la recherche fastidieuse des bugs dans tout le système.

    La résistance aux pannes vient de l'indépendance des modules: quand un module est faux, l'erreur est localisée, elle se propage moins que si c'était linéaire sans frontière.

Coupe feux:

    La frontière entre modules fonctionne comme un coupe feux dans un système orienté objets. il y a une porte blindée constituée par l'interface d'entrée sortie qui est standardisé et donc refuse de laisser passer tout ce qu'il n'attend pas c'est à dire tout ce qui est anormal.

Check-point

   A chaque sortie d'un petit module de traitement il y a un check-point permanent bien connu qu'on peut vérifier à tout moment. Dans RTGE 96 le check-point est une table permanente qui n'est pas détruite à la fin de l'exécution. Cette table permanente aux colonnes bien définies peut être vérifiée après le job. Si on détecte une anomalie au niveau d'un check-point alors il y a une erreur en amont du check-point.

   Une table permanente peut être calculée et modélisée au préalable avant le lancement du job. On peut modéliser toutes les 16 bases du RTGE pour générer un jeu d'essai (indépendant de DB2) de vérification beaucoup plus fin que les seules tables finales et états édités. La multiplication des check-point multiplie la vérificabilité et validité du logiciel, sa fiabilité et la facilité de maintenance et débugging.

   Dans le nouveau RTGE 96 les check-points sont:

   Les check-point sont comme autant de lumières et de clignotants sur un réseau: imaginez la même application sans check-point, sans points de lumières: ça serait l'obscurité.

Les check-points permettent de faire de la recherche dichotomique en cas de dépannage de bugs. par exemple

• si on trouve une erreur au niveau de TA1 c'est à dire au centre, on peut vérifier au niveau du siège en sautant le groupe car si le siège est bon c'est le groupe qui est mauvais

• par contre si le siège est mauvais on peut sauter tout de suite à la vérification des données et paramètres en entrée de la BDR. Si les données et paramètres en entrée sont en erreur alors on regarde plus loin de ce côté

• mais si les données et paramètres sont bons et que les résultats du niveau siège sont mauvais au niveau de TF1 alors on vient de borner les deux extrêmes de notre recherche dichotomique qui consiste à viser constamment en plein milieu de la zone suspecte pour la diviser en deux tranches égales de population suspecte.

• étant donné que la BDR est bonne et TF1 est en erreur on va donc viser en plein milieu c'est à dire BD1

• Si BD1 est bon alors on va vérifier BS1

• Si BD1 est faux alors on va regarder BF1

    avec cette méthode et en profitant des tables permanentes persistantes on peut débugger après que la chaîne a tourné en vérifiant tour à tour tous nos principaux check-points qui sont faits pour cela check veut dire vérifier et check-point veut dire points de vérifications.

    Etant donné qu'on connaît les points sensibles de notre logiciel où on a précisé les résultats exacts à sortir d'après nos calcul mathématiques à la main et sous Excel alors il est clair et pratique d'utiliser ces tables vivantes (pas effacées) et fraîches (qui viennent d'être renseignées) pour nous éclairer sur les problèmes d'erreur logiciel

Faible couplage:

    Plus le couplage est faible entre modules et plus les bugs ont de difficulté de voyager de module à module.

Lorsque, face à la base existante B11+B19 on ajoute les

BDROO BF1 BD1 BD2 BF5 BD5 BD6 cela crée des séparations, barrières et tourniquets; lorsqu'un bug sort d'un module, on le voit.

Un couplage faible permet de tester un module indépendamment des autres.

Un couplage faible permet de relancer un module planté indépendamment des

autres.

Un couplage faible permet de comprendre un module indépendamment des autres.

Un couplage fort oblige à comprendre tous les modules couplés, et à scanner tous les modules couplés en cas de bug et de mobiliser sur le pont tous les responsables des modules touchés en cas de bug.

Un couplage fort oblige à lancer le module quand on n'a besoin que de lancer le module aval.

Un couplage fort oblige à rendre suspect le module amont lorsqu'il apparaît un bug dans le module aval.

Un couplage fort oblige à finir parfaitement le développement du module amont avant de bien tester et déduire le module aval.

Un couplage faible permet de mieux développer en parallèle chaque module.

Un couplage fort rend plus complexe l'établissement d'un PERT et d'un GANTT.

Un couplage faible rend plus simple plus sûr le PERT, le GANTT, le planning, le suivi des tâches, la gestion des ressources et la conduite de projet car les tâches sont indépendantes, peuvent être développées en parallèle, ont peu de contraintes de finition et départ en ordre chronologique.

La COO et POO permet d'optimiser la conduite de projet en souplesse selon la disponibilité des ressources et permet de mieux distribuer les tâches.

Exactitude des résultats.

    Lorsque le traitement est bien découpé en objets, les vérifications et validations des résultats sont plus précis plus logiques, plus sûr, plus exacts.

    On peut calculer par multiplan ou Excel ou Excel Access et comparer avec les bases en sortie de chaque étape; s'il y a 4 étapes principales on peut les vérifier toutes au lieu de ne pouvoir vérifier que la fin. on peut sortir les données de db2 vers Access faire des calculs avec Excel VB pointer les calculs à la main puis utiliser les tables résultantes de niveau siège groupe centre des étapes lecture calculs totaux consolidation pour les différents datamart axes et dimensions puis on peut comparer à l'étape d'expérimentation entre la chaîne Access Excel VB et la chaîne Cobol DB2 sur des petits exemples tests peu volumineux au niveau du micro de développement

    Les humains se trompent moins quand ils programment des petits modules de trois queries que quand ils pataugent dans des gros batch de 400 queries.

    Les sorties de petits modules sont plus faciles à pointer que les sorties de procédures volumineuses.

   Méthode de vérification par comparaison

   entre l'application en SQL et le calcul théorique sous EXCEL