coo poo 1 3 6 Puissance

1.Héritage:

    L'héritage permet aux objets de même type de bénéficier des mêmes traitements qui se ressemblent: On fait faire ce travail à un parent (classe de niveau supérieur) et les enfants en profitent (objets de niveau inférieur appartenant à cette classe). Hériter de caractéristiques ça veut dire reprendre des caractéristiques pour s'en servir sans avoir à les fabriquer soi même.

Exemple: les lignes 'divers ressources' du folio 1 héritent des caractéristiques du folio 1 sans avoir à refaire les tâches communes à toutes les lignes du folio 1 qui ont déjà été exécutées en amont.

2.Réutilisation de codes

    Elle permet aux objets de même type de bénéficier des mêmes lignes de codes situées au même endroit et pas dupliquées.

Classiquement le lieu d'implantation des codes communs est une procédure cataloguée ou un utilitaire appellable par toutes les procédures qui en ont besoin. C'est la réutilisation de code par appel de modules.

Dans RTGE le lieu de traitement commun pour une tâche utile à plusieurs folios est un niveau supérieur qui se termine par le chargement dans une base de niveau supérieur. Ainsi les niveaux inférieurs bénéficient du résultat du travail déjà réalisé par le niveau supérieur en relisant la base écrite à l'étape précédente. C'est la réutilisation de code par héritage et le couplage de modules par les données.

    Principe de la réutilisation de code par héritage vertical

3.puissance:

En peu de queries on accomplit beaucoup de choses.

Pourquoi? parce qu'avant il y avaient 10 queries

maintenant il n'y a plus qu'une query.

Et cette query unique fait le travail de 10 queries.

Comment?

Par le principe de la mise en facteur et de l'héritage:

On met en facteur la fonction commune identifiée( que ce soit lecture ou calcul ou mise en forme) puis on écrit cette fonction, on exécute cette fonction ensuite les bénéfices de cette fonction parent sont héritées par les objets enfants.

Ce qui donne la puissance: la prochaine fois qu'on aura à modifier ou faire évoluer cette fonction, on n'aura à toucher qu'un seul endroit et toutes les modifications seront héritées.

Cette puissance ne vient pas forcément d'un langage. Elle vient de l'architecture de l'application. En COBOL on peut faire des lignes puissantes héritées par beaucoup de programmes appellant ou des lignes pas puissantes qui ne font qu'une chose à un seul endroit. En SQL on peut faire des queries puissantes qui font la lecture ou le calcul une fois pour toute l'application ou bien on peut faire une série de queries pas puissantes qui font des petites choses à de nombreux endroits. Donc dans notre cas dans RTGE cette puissance vient de l'architecture orientée objets et non pas seulement de la nature du langage SQL ensembliste.

    Un language ensembliste déclaratif L4G est plus puissant qu'un language procédural L3G.

    Une méthode de 5 ème génération orientée objets est plus puissante qu'un système de 4 ème génération.

    L'optimisation dans le RTGE96 vient du 'saut de génération' qui divise par trois le besoin de tables intermédiaires et élève la puissance des queries.

Exemple 1. Mise en facteur vers l'amont:

   Au lieu de faire 12 lectures pour 12 groupes de lignes, on fait une seule lecture polymorphe pour 12 groupes de lignes. On fait une seule query du folio 5 pour les 12 groupes de lignes. La diversité est gérée par les tables paramètres en jointure.

Exemple 2. Mise en facteur vers l'aval:

   Au lieu de faire 12 mises en formes pour 12 groupes de lignes, on fait une seule query de mise en forme jointe à une table de codes d'affichages.

Exemple 3. Un seul lieu d'implantation de la tâche de transcodage:

   Pendant l'écriture des lectures des frais et moyens, on s'aperçoit qu'il y a une tâche de transcodage commune aux lectures des données frais et moyens. On prend donc la décision de reporter l'exécution de cette tâche vers l'aval pour qu'elle puisse être faite en une seule fois au lieu de 7 fois.

4.performance

    La performance vient du fait qu'avant il y avaient 90 queries dans le folio 1 et après la mise en facteur de certaines fonctions communes il ne reste que 20 queries principales dans le folio 1 du RTGE.

(Bi1, BF1, BD1, BS0, BS1, TF1, TG1, TA1)

Donc 20 queries tournent plus vite que 90 queries. et 20 tables prennent moins de place que 90 tables. Et des tables permanentes indexées tournent plus vite que des tables temporaires non indexées.

     La réduction du nombre de queries, du nombre de tables, et l'indexation des tables font que l'application tourne plus vite d'où gains en performances.

     La performance vient de l'introduction de la programmation orientée objets: pour accomplir la même quantité de travail, on fait tourner moins de queries qu'avant.

     La création de modules spécialisés standardisés normalisés

de lecture généralisés permet de transformer une centaine de tables temporaires crées par SAVE DATA en quelques tables permanentes (BIS BF1 BD1 BD2 BF5 BD5 BD6) créées par CREATE avec des INDEX. C'est ce que souhaite la DE qui est contre les tables temporaires et qui demande fortement de faire des tables permanentes indexées et triées pour des raisons de temps CPU, de rapidité d'accès, de simplicité de balayage, d'économies de logging, d'optimisation de lectures. Ainsi, à la sortie des modules de lecture standardisés on obtiendra des tables indexées plus petites, plus aptes à constituer l'entrée des étapes suivantes de calcul (à la fois le nombre et la taille des tables sont réduits).

Simplification des procédures:

     La spécialisation des fonctions (lecture, calcul, totaux...) permet que la CLIST et la procédure QMF BATCH deviennent plus courtes, plus faciles à mettre en oeuvre, plus lisibles, plus facile à comprendre, plus ergonomique pour l'intervention en CTI ou la modification au CPL.

     On analyse plus vite, on programme plus rapidement les changements de mise en forme des lignes et des colonnes, les tests de mise au point sont moins longs, il y a moins de sources d'erreur et l'exécution est plus rapide, cela permet de tester par des étapes plus petites, plus parallèles, mieux contrôlées, les bugs sont plus identifiables.

    L'idée est de diviser un grand problème à résoudre (lecture, calculs, totaux, mise en forme) en plusieurs petits problèmes plus clairs, plus maîtrisables, plus explicables à Alain.

    Si on fait une base par folio, la taille de la base sera réduite, l'exécution sera rapide, la compréhension sera facilitée, la personne qui fait les folios de détail n'aura pas à se soucier des lignes des folios de synthèse. Elle aura une petite table à comprendre et à accéder sans être encombrée par le folio 1. Les tables de paramètres du folio 5 deviendront simplifiées en même temps que les tables de données.