coo poo 1 3 5 organisation

Dans une application orientée objets moderne, certaines parties communes sont horizontales appelables par tous.

Ce sont traditionnellement les lectures, écritures, transcodages, calculs généraux. Par exemple les calculs de dates, calculs de primes, sont dans les modules généralisés. Dans RTGE 96: on met les lectures, les calculs et les mises en forme dans des modules horizontaux qui permettent à toutes les lignes de profiter du résultat de leur travail.

Dans une grande entreprise: la production, la division géographique, la division par branche sont verticales mais le marketing, la comptabilité, la recherche et développement sont horizontales. Dans RTGE folio 1 les lectures et calculs sont horizontaux et les totalisations sont verticales en cascade.

Ce qui devient horizontal (profitable par tous) est orienté objets. (objet calcul, objet lecture). Ce qui reste vertical est découpé par tâches (et pas par type de donnée). A défaut de découpage par types de données (BF1/BF5) en différentes classes successives (BD1/BD2), le découpage par tâches en ordre chronologique (TF1,TG1,TA1) est mieux que pas de découpage du tout.

Un objet exécute une fonction. L'objet BF1 exécute la lecture pour charger la base des folios de synthèse la base BF1.

Intégration, développement en parallèle, division des tâches, ventilation des tâches, affectation des tâches aux ressources, décomposition du travail vers différentes équipes de développement, suivi de l'avancement des travaux, tests d'intégration, mise en oeuvre.

Puisque l'application est déjà divisée en modules bien définis grâce à la conception orientée objets, on peut, plus facilement affecter des modules aux personnes, des tâches aux ressources, des travaux aux équipes. On peut plus rapidement développer les modules indépendants en parallèle au lieu de les faire en séquence. Il devient plus facile de suivre le degré d'avancement des travaux dans chaque module séparément.

Puisque les modules sont bien identifiés il devient plus facile de les intégrer on ne risque pas d'en oublier. Ils sont déjà testés et validés individuellement on n'attend pas la fin pour découvrir les erreurs dans un module. Puisque les modules sont bien structurés, on peut facilement les disposer dans une échelle de temps pour faire une planification. S'il y a des contraintes de priorité, on peut mieux faire des études de PERT et des dessins de GANTT ou des Work Breakdown Structures.

En somme on peut faire beaucoup de choses à partir d'un système bien structuré modulaire, bien orienté objets (chaque objet ayant ses données et ses procédures) car sinon, si l'application était en vrac (la base B19 en vrac, les paramètres de la B13 en vrac non séparés, les traitements de la C200 linéaires en vrac) comme avant en 95 alors il serait difficile de ventiler logiquement du vrac sur des personnes, des ressources, sur un PERT et un planning, on serait obligé d'effectuer un découpage un peu arbitraire. Alors que si l'application est déjà découpée en objets il suffit de suivre les lignes de découpage des objets pour affecter des tâches aux personnes, aux périodes de temps, aux étapes de développement.

	Découpage de la base
avant découpage		après découpage
une bdr		une bdr + 6 BDO

pour découper le système de comptabilité de gestion et tableaux de bords qui présentent les résultats des groupes d'exploitations on sépare synthèse et détails d'une part puis période d'analyse et comparaisons d'autre part

ce qui nous donne six bases objets hiérarchiques en dessous de la base relationnelle existante
ainsi on peut les confier à plusieurs personnes et/ou développer en plusieurs étapes

Lorsqu'il y a une quinzaine de modules il est facile de les compter, de les livrer de les mettre en exploitation, de ne pas en oublier.

Lorsqu'il y a une procédure algorithmique linéaire, c'est plus problématique pour ne pas oublier quelque chose, une query qui traine, un data, un load, un synonym, un view.

Evidemment quand les composants bien rangés, classifié, groupés par classes, par sous classes, par objets comme des boîtes imbriquées, il est plus facile de les manipuler, livrer, intégrer, d'en faire le suivi et la gestion.

Quand il y a un grand nombre d'éléments à gérer il ne faut pas se tromper, il ne faut pas oublier, il faut une classification, un rangement, une structuration, une hiérarchie, une organisation en somme un système orienté objets. Comme pour la nomenclature de pièces d'avions, de trains, de voitures, il faut beaucoup d'ordre et d'organisation hiérarchique pour les composants logiciels.

La technologie orientée objets améliore les performances de la programmation mais aussi des autres travaux: la gestion de projets, la planification, la mise en oeuvre, les tests, l'intégration, la communication, la coordination, le suivi, la gestion des composants, la livraison, le contrôle, en somme la COO POO c'est la façon industrielle de produire du logiciel.

Si on ne normalise pas l'intérieur d'une procédure cela veut dire qu'au début de la procédure on explique au réalisateur ce qu'il trouve en entrée (les tables données et paramètres en entrée ) puis on explique au réalisateur ce qu'il doit donner en sortie (la maquette d'état en sortie ). Dans ce cas, il a libre cours de décider des tables intermédiaires (nature, nombre, description, colonnes, noms de colonnes , emplacements, organigramme, c'est à dire toute l'analyse organique)

Un fois qu'il a fait et que c'est juste, si on veut faire évoluer ou corriger, modifier, débugger on est obligé de refaire tout le cheminement intellectuel de son analyse organique pour être capable d'intervenir au bon endroit sans détruire tout le reste. Cela (chercher à comprendre le cheminement de la pensée d'un autre) est long, fastidieux, aléatoire et source de perte de temps et de fiabilité.

Solution: au lieu de donner au développeur l'entrée et la sortie d'une grosse procédure comme la constitution d'un folio qui contient 90 queries, on ferait mieux de diviser la grosse tâche en 4 petites tâches puis de donner au développeur la description avec entrée-traitement-sortie de chacune des 4 petites tâches nommées lecture,calculs,totaux,misenforme.

Ainsi on a déjà dès le départ décidé des tables intermédiaires, de leur nature de leur nombre, des colonnes, de leurs noms, de leur emplacements. De cette manière, une fois que le travail est fait il n'y a aucun problème pour vérifier la conformité. On est sûr que ça marche. Les différents travaux donnés à différentes personnes se ressemblent.

Maintenant quand on donne à cinq personnes le développement cela donne en sortie un seul style compréhensible par tous et exprimé dès le départ par la documentation qui décrit les solutions techniques retenues. A chaque moment où il y a une décision à prendre entre plusieurs solutions, une solution est choisie ensemble dès le départ et sur tous les folios c'est standardisé d'après le même moule.

Lorsqu'on a compris un folio on a compris tous les folios. C'est facile à maintenir. Les noms de queries et de colonnes sont normalisés, c'est beaucoup plus facile à lire à mémoriser et à écrire. Il faut normaliser la méthode, la technique, les noms de queries, data, colonnes, forms, tables.

Harmonisation horizontale entre toutes les lecture, tous les calculs, tous les totaux, toutes les mises en formes du RTGE et RMGE. Cela ressemble un peu à de la programmation massivement parallèle: on fait tout en même temps: toutes les lectures, tous les folios et tout RTGE et RMGE.

Au lieu que l'organigramme des folios 1 2 5 6 soit fait par plusieurs personnes chacun dans son coin, l'analyse organique est fait par tous sur un document unique. Ainsi tout le monde sait lire le dessin commun et parle le même language. Il n'y a qu'un seul organigramme pour tout le RTGE-RMGE.

Conclusion pour la normalisation: l'analyse orientée objets (décomposer une grosse procédure en quatres procédures plus petites lecture, calcul, totaux, misenforme avec entrée-traitement-sortie pour chacune des petites procédures) permet d'introduire la normalisation et standardisation des noms et des méthodes à l'intérieur de tous les folios (1,2,5,6) du RTGE 1996 et permet de profiter des avantages de la normalisation et standardisation: fiabilité, ergonomie, facilité d'intervention, de debugging, évolutivité, facilité d'explication, de compréhension.

Lorsqu'on explique le système orienté objets déjà divisé en 4 étapes c'est facile d'expliquer les étapes une à une qui font des traitements simples avec des entrées et sorties bien définies.

Le but du jeu est d'obtenir une procédure qui marche mais qui soit aussi facile et rapide à débugger à maintenir, à faire évoluer. Donc il ne faut pas laisser de black box.

Si on donne à dix programmeurs une analyse floue, ils vont faire dix black box et on se retrouve à la fin avec un énorme black box composé de dix styles différents dont on ne connait pas le mécanisme interne. C'est opaque.

Donc pour que la programmation déléguée soit claire, il faut mettre des lumières aux étapes comme des lampadaires sur la route périodiquement, ici ce sont des tables permanentes bien définies qui empêchent une programmation sauvage grâce à leur rôle normalisateur de check-points.

Si une programmation est non conforme à la norme (même si c'est juste) cela embrouille le reste des personnes amenées à intervenir sur le système.

S'il n'y a pas de norme, chacun écrit selon son inspiration, et quand il y a un bug personne ne sait résoudre parceque chacun connaît son petit bout de code et personne ne connaît l'ensemble de l'application, on ne sait pas d'où vient le bug et même la personne qui a fait le bug ne sait pas que c'est elle qui l'a fait et les autres personnes ne peuvent pas intervenir rapidement à l'intérieur du code.

Lorsqu'il y a un bug, il peut venir de n'importe où, il peut resurgir bien loin de l'endroit où il a été commis et il est très difficile de retracer son cheminement à travers toute l'application si on n'en connaît pas tous les moindres recoins.

Pour être capable de débugger une grande application complexe il faut la connaître à fond et si on ne l'a pas écrite soi même il faut que ceux qu'il en ont écrit différentes parties aient respecté une certaine norme une certaine standardisation, un certain mécanisme commun pour qu'un personne qui débugge ou modifie puisse travailler dans un environnement bien connu.

Si tout est normalisé alors chaque intervenant qui comprend la norme peut comprendre un folio qui respecte la norme.

Si rien n'est normalisé alors chaque personne qui comprend un folio doit passer du temps pour accéder à un autre folio.

Si deux personnes différentes développent deux parties d'un même folio de façon non standardisée, les deux parties peuvent être incohérentes et faire des bugs. Il faut imposer des normes communes pour garantir la cohérence entre les différentes parties d'un même système.

Dans RTGE orienté objets la norme passe par les tables permanentes à l'entrée et à la sortie de chaque étape.

Ces tables permanentes préfabriquées servent à garantir la qualité du logiciel.

Dans la conception orientée objets la normalisation facilite la vérification à la sortie d'une étape:

Sans normalisation, standardisation et décomposition en objets on ne peut que vérifier le début et la fin (l'édition de l'état) sans voir clairement le milieu de la grosse procédure.

Avec la normalisation, standardisation et la décomposition en étapes, on peut vérifier de façon plus sûre plus ergonomique les résultats des calculs et queries.

Normalisation de la méthode de programmation: on généralise la même méthode de programmation sur tous les folios: