coo poo 1 3 4 evolutivite

Meilleure évolutivité

    Comme le système est découpé en petites parties, à chaque fois qu'arrive une demande de modification, on peut mieux repérer l'endroit à toucher, aller le modifier puis tester et livrer sans avoir à gêner d'autres parties ou être gêné par d'autres modules. Les modules sont faits de telle sorte qu'il sont le plus indépendants possibles les uns par rapport aux autres et le moins couplés possible. Leur entrées et sorties sont bien normalisées et standardisées. Les frontières de chaque objet sont bien nettes et les frontières entre modules sont bien définies.

    Exemple: avant le découpage en fonctions bien distinctes(une fonction ==> une tâche, une tâche ==> un module, un module ==> un objet), les lectures étaient mélangées avec les calcul, on ne savait pas où finissent les lectures et où commencent les calcul, c'est flou, il fallait aller à l'intérieur d'une procédure linéaire les endroits précis d'intervention sans détruire le les autres parties, sans générer des bugs en cascade.

   Après le découpage en objets bien clairs:(la fonction lecture ==> un objet lecture bien défini avec base, tables données, tables paramètres, queries) on peut facilement savoir où modifier sans détruire l'aval. D'où une meilleure évolutivité du modèle orienté objets comparé à la technique de programmation procédurale linéaire. Car dans la technique de programmation procédurale linéaire (style L3G) toute intervention sur une ligne affecte toute la ligne, tout bug se propage sans barrière, toute modification en amont oblige à des modification en cascade vers l'aval, toute fonction a des frontières floues qu'il faut chercher au cas par cas. Tandis que dans un système orienté objet il y a des frontières tout autour des objets ce qui fait que tout ce qu'on touche est bien localisé, tout ce qu'on cherche est bien déjà balisé avant qu'on le cherche.

Exemple: lorsqu'on cherche à modifier la lecture, la lecture est déjà identifiée au préalable, nommée, créée, elle existe bien physiquement. De même lorsqu'on cherche à modifier le calcul, le calcul est déjà créé, préexistant, construit et connu comme calcul, il n'y a aucun problème pour le voir il figure en clair dans le dessin de chaîne, dans l'organigramme des traitements.

    De même lorqu'on doit toucher à la mise en forme, elle est bien localisée au préalable, bien cadrée, il n'y a pas d'ambiguité possible. Alors qu'avant la programmation orientée objets qui crée des objets (objet lecture, objet calcul, objet mise en forme) on avait tout celà (lecture, calcul, mise en forme) en tas, en vrac, tout mélangé en fouillis dans une procédure à l'intérieur de laquelle on doit se plonger au cours de chaque modification pour trouver la query à toucher.

   La technique orientée objets permet de mettre de l'ordre dans l'analyse au moment où on programme et ensuite de figer cet ordre pour plus tard. Si on a bien décomposé le traitement en objets, alors plus tard, un an après une autre personne peut toujours retrouver ces mêmes objets physiquement et bénéficier de la bonne logique inscrite au début. Si on n'utilise pas la technologie orientée objet, alors au moment où on programme, on sait où est la lecture, où elle s'arrête, où commencent les calculs, où se trouve exactement la mise en forme mais trois ans après c'est moins frais on peut avoir oublié les frontières entres différentes tâches, et quelqu'un d'autre ne parvient pas à deviner rapidement l'implantation interne des fonctionnalités, alors toute personne amenée à intervenir sur le logiciel sera obligée de se plonger dans la mer de code pour trouver ce dont elle a besoin.

    Faire de l'orienté objets c'est comme ranger ses affaires dans des armoires, des classeurs, des dossiers. Ne pas faire orienté objets c'est comme mettre toutes ses possessions dans une grande piscine: les cassettes mélangées avec les photos, les livres avec les outils, les cd avec les équipements de sport. Alors chaque fois qu'on veut écouter la musique ou sortir au gymnase ou répondre aux impôts on doit chercher les choses utiles parmi les choses pas utiles. Par opposition à la technique sauvage de mettre toutes ses possessions dans une piscine, si on les rangeait dans l'ordre par catégorie, on pourrait chercher ses affaires de sport dans la zone dédiée au sport, ses affaires de vacances dans le sac de vacances, ses papiers de loyer et impôts dans la boîte de choses administratives. C'est un peu abhérent de mélanger les k7, cd, les outils dans la même malle mais en informatique beaucoup le font quotidiennement, ils mélangent les lectures, les calculs, les mises en formes dans des programmes linéaires procédurals algorithmiques énormes qui confondent tout en une salade sans séparation des codes pour chaque fonction, sans affectation en privé des données à chaque module, sans distinguer les bases pour folios de synthèse ou pour folios de détail, les bases pour folios du trimestre ou de comparaison, les objets lecture ou calculs.

    En fait ce qu'on trouve irrationnel de faire avec ses propres affaires (tout mélanger) on le fait souvent dans son programme informatique: par exemple dans les programmes COBOL sauvages, il n'y a pas d'interdiction à plusieurs sous-programmes de partager les même zones de données.

    Une application sauvage linéaire, algorithmique, L3G non structurée-modulaire, non orientée objet peut marcher mais elle est de mauvaise qualité peu maintenable, peu évolutive. Chaque fois qu'il y a une évolution il faut changer l'algorithme et les codes partout parceque ce n'est pas décomposé en modules. Historiquement 100 % des graves bugs dans RTGE viennent de la partie COBOL batch L3G.

    La programmation structurée modulaire c'est déjà bien, la programmation orienté objet c'est mieux. Car avec l'orienté objet, les données sont privées à chaque module, la modularité est poussée plus loin, la clarté est plus nette, le lieu d'intervention pour chaque évolution est plus précis. Car un objet est beaucoup plus encapsulé qu'un simple module sous-programme d'un grand programme principal. Un module classique peut partager ses données un objet ne partage pas ses données.

En conclusion: un RTGE orienté objets est beaucoup plus évolutif qu'un RTGE linéaire algorithmique procédural L3G.

    La technique orientée objet est de 5 ème génération.

    Le relationnel est de 4 ème génération.

    Si on veut optimiser le relationnel (4 ème génération) il faut tendre vers la 5 ème génération (techniques orientées objets) et non pas revenir 20 ans en arrière vers l'antiquité de l'informatique, vers la 3 ème génération.

    Imaginez que vous allez faire un marathon et vous ne trouvez pas vos NIKE, que vous avez besoin d'urgence d'un prêt et vous ne trouvez pas vos papiers d'impôts. C'est pas pratique. Et pourtant en informatique, on ne range pas toujours dans l'ordre les lignes de codes programmées avec beaucoup d'efforts. Les codes qui représentent des années hommes, restent encore en vrac dans des gros programmes L3G linéaires où il faut aller rechercher séquentiellement à chaque modification.

    Si on classait les codes en en modules, en objets et classes, on peut rechercher les modifications et les erreurs en accès direct, de façon beaucoup plus rapide, plus performant, plus sûr et efficace. Un système ordonné est toujours plus convivial et compréhensible qu'un tas en vrac.

souplesse

  C'est la faculté de changer sans détruire.

  Un roseau est souple, on peut le courber sans le casser.

  Dans RTGE 96 si trois lignes (res.obl.) passent d'un sous total (tot.aut.pr/ch) à un autre (div.val.ajout/capi), ce changement n'affecte pas les identifiants de stockage, il touche seulement les paramètres de calcul.

  Si une ligne change de place dans l'état de sortie (déd.res.obl), ses codes d'affichage changent mais si son type de taux reste le même, son code type de taux ne change pas.

  Si une ligne change d'origine (frais personnel), son code d'origine change mais son identifiant de stockage ne change pas et les autres codes non plus.

  Si un sous total disparaît (tot.aut.pr/ch), il est supprimé de la table des totaux mais si une ligne détail disparait (soldes irrec.), cela n'affecte pas la table des totaux.

  Etant donné qu'il existe des codes d'origine, identifiants de stockage, paramètres de calcul, types de taux, codes d'affichages, cela fait au moins trois ensembles de paramètres qui peuvent être modifiés séparément selon le type de modification demandé. Et on peut modifier des paramètres spécifiques sans toucher les autres paramètres non concernés. Ce système de séparation des paramètres selon les étapes de la procédure et selon les folios permet d'avoir un minimum d'endroits à modifier, les endroits les plus précis possibles sans gêner les autres endroits non concernés.

La séparation des paramètres par tâche (une tâche principale ==> un ensemble de paramètres de pilotage de cette tâche) est démontrée ci dessus: si la mise en forme change, cela ne touche pas le stockage qui reste identique du point de vue paramètres comme du point de vue procédures et queries.

La distinction par ensembles de folios permet de modifier ce qui concerne le folio 1 et 2 sans modifier le folio 5 et 6 et vice versa. Car à partir de 96 on aura un ensemble de tables paramètres pour folios de synthèse et un ensemble de tables paramètres pour folios de détail. Et chaque modification n'est pas forcément sur les folios de détail et sur les folios de synthèse. Certaine modifications seront sur les folios de synthèse seulement et certaines seront sur les folios de détail seulement. Cette distinction allégera d'autant le volume de modifications nécessaires et les rendra plus précis, plus rapidement identifiables, plus efficaces.

Conclusion: un tel système de modifications précises séparées par modules et par folios permet de changer ce qui est demandé sans détruire le reste qui reste bon. Donc l'augmentation du nombre de maillons de la chaîne élève la

souplesse de l'ensemble: on peut changer les maillons séparément.

    Le résultat de la séparation du système de paramétrage en sous-ensembles de paramètres c'est comme lorsqu'un nunchaku est plus souple qu'un bâton et un fouet à neuf sections est plus souple qu'un nunchaku donc il peut atteindre derrière le bouclier levé