Jump to content
Ugo

Session Modularité

Recommended Posts

Plutôt que de rentrer sur ce débat intéressant certes mais tout de même assez théorique sur un forum dédié à la pratique, je suggère de démarrer un exemple simple et de débattre au fur et à mesure sur son développement par plusieurs groupes.

Son avancement servirait ainsi de socle aux différentes interprétations, aux différents génies. L'exemple présenté lors du forum pourrait suffire à cet exercice.

Car je crains que le débat s'éternise. Il y a plus de 30 ans, on avait fini par conclure de manière lapidaire qu'en "C", module=fonction. Ainsi chacun avait le droit de disserter sur l'ingéniosité flexible et ouverte de ses fonctions. Ils avaient l'avantage de compiler séparément leurs fichiers et faire l'édition de lien en fin de parcours. Nous ne disposons pas de cette capacité.

Pour nous, il s'agit bien de méthodes de travail, point !

Qu'en pensez-vous.

Il y a eu des jeux ici pour gagner des friandises,

pourquoi pas ce jeu sans gain matériel.

_____________________________________________________

"Des pavés tu jetteras, derrière un arbre tu t'abriteras" (Anonymus)

Share this post


Link to post
Share on other sites

Que voilà une idée qu'elle est bonne, bravo Théo !

Parceque, de mon côté, plus ça va et plus je me dis que j'ai dévoyé A&B pour en faire du modulaire, chaque GOT étant en fait un module... :huh:

Allez Lucas di Ugo, fait péter un fichier et pis c'est tout :D

Share this post


Link to post
Share on other sites

Salut Théo,

Voilà une idée qui me séduit bien entendu. Le retour de conférence est un peu chargé, il me faut rattraper le temps perdu, et achever un projet en cours. J'y réfléchi ce week-end, et Lundi, je déposerai un fichier avec quelques directives.

Je voudrais malgré tout poser un seul principe, pour cet "exercice". Faire autrement que ce qu'on fait au quotidien. C'était l'objet de la session, l'objet de ce fil et je ne verrai aucun intérêt à ce qu'on rentre dans un jeu d'opposition de styles.

Il ne s'agit pas de mettre donc le modulaire face à une autre technique, mais bien de tenter le modulaire. Ensuite, on pourra, au fil de l'exercice creuser et comparer alors ce que nous faisions de ce que nous avons fait.

A première vue donc, j'imagine ce "projet" en une série de 4 ou 5 exercices, pas plus, pas trop complexe, sinon personne ne s'y intéressera, suffisamment pratique pour y retrouver en plus des méthodes ( paramétrages, gestion de scripts et résultats, déclaration de variables modulaires, etc ) visant à atteindre progressivement les objectifs de :

1. Séparation des Aspects

2. Encapsulation

3. Réutilisabilité des processus

4. indépendance d'un module vis à vis d'un autre, assez proche.

Sommes nous d'accord ?

Share this post


Link to post
Share on other sites
Parceque, de mon côté, plus ça va et plus je me dis que j'ai dévoyé A&B pour en faire du modulaire, chaque GOT étant en fait un module... :huh:

Une GOT peut devenir un module, si il devient un espace logique, avec ses propres processus.

La règle pour être modulaire, c'est l'indépendance d'un module envers l'autre. Aucun processus au sein du module ( GOT dans ton cas ) ne doit faire appel à des éléments d'interface, à des scripts, qui sont utilisés par l'autre module. Donc par exemple, activer un enregistrement lié depuis une ancre vers une autre, conduit à une dépendance. On ne pourra pas "coller" cette GOT sans avoir préalablement développé l'autre, sinon ton script ne pourra pas être réellement indépendant.

S'il te faut activer une autre ancre pour visualiser les lignes de ventes ( en vue d'une impression ), parce que ces lignes ont été isolées sur un GOT, les dépendances de ces deux GOT sont clairement définies. il convient de tempérer, car plusieurs GOT ensemble peuvent également constituer un seul module. Mais bon...voilà une première base d'analyse pour déterminer si oui ou non ton GOT peut être assimilé à un module.

Share this post


Link to post
Share on other sites

un YES massif d'autant que j'ai dû vous quitter dimanche matin à Roissy avec beaucoup d'interrogations en tête.

Donc +1

Share this post


Link to post
Share on other sites
(...) Donc par exemple, activer un enregistrement lié depuis une ancre vers une autre, conduit à une dépendance. (...)

On est parfaitement d'accord. C'est même, de mon point de vue, le principe même des GOT et des ancres que d'être indépendants.

Sommes nous d'accord ?

Que oui, sur toute la ligne Master :)

Share this post


Link to post
Share on other sites

Super idée à laquelle j'adhere avec plaisir

Une GOT peut devenir un module, si il devient un espace logique, avec ses propres processus.

Et la est toute la différence puisque même en séparant au maximum les Got il ne sont pas pensé pour être totalement indépendant (Variable, resultat de script........)

Chouette !!

Bertrand

Share this post


Link to post
Share on other sites
(...) ils ne sont pas pensés pour être totalement indépendants (Variable, resultat de script........)

(...)

des modules indépendants n'exploitent donc jamais une variable définie par un script lancé depuis un autre module ?

j'attends l'exemple avec impatience... qu'est-ce qui fout le maître nageur ? il est pas encore dans l'eau ??? :D

Share this post


Link to post
Share on other sites

"module" ... semble le point de confusion :(

Avec d'autre co-listiers ... nous échangions nos opinions, et elles convergent toutes vers un énorme ? :(

Il se pourrait que notre ami Ugo, qui à lancé ici un sujet que beaucoup ont à coeur de suivre ET de comprendre, arrivent au point de ne pas comprendre le changement de "sémathique" ou en tous cas de terme ...

La synth`se de ce que nous n'avons pas compris ... en tous cas, je vais parler pour moi après avoir demandé de l'aide à des cerveaux compétents est :

Module = table ... mais, Ugo nous dis Non, c'est pas une table (Pour ce qui est du système d'Ancres et Bouées moins redondant et plus sophistiqué, il faudrait pour se faire renoncer aux ancrages par utilisation de la Table. Donc il ne s'agirait pas d'un A&B. La logique du découpage est la seule capable de conduire au modulaire. Les modules ne sont pas des GOT, il peut s'agir de plusieurs GOT. Mais surtout, un module enferme des fonctions qui couvre des logiques bien définies. Une Table n'offre aucune fonction propres au-delà du 'stockage', en faire une valeur centrale' conduit à transposer nécessairement le fonctionnel vers le structurel.) ni une GOT, ni un A&B ou A-B... :(

Si cela ne t'ennuies pas Ugo, il serait plus pratique de définir ce qu'est un Module pour que nous puissions avoir accès à ce que tu veux expliquer.

Au final, j'ai plus compris ce qu'exprimais Yvan (une fois n'est as coutume, vu que je pige rarement ce qu'il dit de sa salle de bain ;)) et je me perds (avec d'autres) dans les limbes de ce que je ne pige pas comme concept : Module

Sincèrement,

Maxence, Bécasson d'outre-Pyrénées

Share this post


Link to post
Share on other sites
j'attends l'exemple avec impatience... qu'est-ce qui fout le maître nageur ? il est pas encore dans l'eau ??? :D

Mééééheuuuuu ! pour une fois que je peux comprendre : Eul'gars y dit "J'y réfléchi ce week-end, et Lundi, je déposerai un fichier avec quelques directives."

Fôôô suiv' Râôûl ;)

Maxence, crétinus-alpis

Share this post


Link to post
Share on other sites

en même temps, nous on n'était pas à la plage pour les définitions... :)

Share this post


Link to post
Share on other sites
Si cela ne t'ennuies pas Ugo, il serait plus pratique de définir ce qu'est un Module pour que nous puissions avoir accès à ce que tu veux expliquer.

Un peu d'abstraction ne fait jamais de mal.

http://nioumedia.com/2008/03/26/modu-mobil...elle-strategie/

Au travers de cet exemple ( voir la toute petite vidéo liéee ) considérons que l'appareil de base constitue une Table, qui ne comporte donc aucune fonction ( l'heure intégrée visiblement, et c'est tout..) . Les fonctions réelles lui sont fournies par les modules dans lesquels cet appareil va être logé.

Une table ne vaut donc rien, ou très peu, et il faut considérer l'espace dans lequel et pourquoi elle va être exploitée comme un module.

Une table Client peut être utilisée pour l'association à une commande, un devis, une facture, dans un planning de rendez-vous, dans un agenda planning, dans des envois d'emails, plus simplement dans un carnet d'adresses. Ce n'est que dans ce cadre que cette table, au travers des fonctions et logiques définies pour l'occasion ( l'envoi d'un mail, la confirmation d'une commande, la plannification d'un rendez-vous, etc. ) prendra sa valeur.

Ce qui est vrai pour la table Client est vrai aussi pour la table Commande, la table Rendez-vous, etc.

Bon, ceci j'espère étant plus ou moins compris, pour ceux qui comme moi ont des tonnes de graphes A&B sous les yeux, on constatera que cette table de Client nécessairement est associée à une commande dans le groupe d'occurrence de tables CDE. Mais alors même que nous disposons d'un lien parfaitement établi entre le Client et sa commande dans ce groupe d'occurrence de table, nous aurons dans 95% des cas dupliqué ce lien pour permettre à l'utilisateur de visualiser dans un onglet la liste des commandes depuis le contexte CLI ( client ). Il faut même reconnaître que les onglets apparus avec la 8 ont décuplé cette redondance, c'est si simple d'en ajouter un. Mais à quoi ça sert finalement ? Pourquoi donc notre peur du contexte nous a poussé à diviser ainsi en mille-feuilles notre graphe ?

On pourra me traiter de dingue, je constate surtout qu'on ne prend jamais assez de recul. J'ai pris beaucoup de temps à exéminer mes développements avant de prendre cette voie. Pour exemple, voici l'un des arguments que j'ai eu au sortir de la conférence, à chaud donc, quand j'expliquait que l'ensemble des actions liées à la Vente étaient rassemblées dans un espace ( pour ne pas parler de module ) 'Vente'.

"Tu dis qu'il est plus simple de maintenir une application structurée en espaces logiques. Mais si tu es en intervention sur l'espace Ventes, cela signifie que je ne pourrais plus visualiser depuis l'espace 'Client' l'historique des commandes."

1. Une intervention ne consiste pas nécessairement à révolutionner les liens

2. Pourquoi donc aurais-je une zone de consultation des historiques des commandes dans l'espace Client

3. C'est quoi un espace Client ?

Il faut à mon avis prendre ces 3 points en sens inverse pour véritablement dire qu'on a pris le recul nécessaire.

Dans ce cas précis, et pour ce qui me concerne personnellement, l'espace Client est directement intégré dans l'espace Ventes. Et dand cet espace 'Ventes', il n'y a aucune ancre. Une commande ne vaut que si on a associé des articles et un client. Toutes les tables sont essentielles et fournissent la logique. Aucune ne trône au centre, à droite ou à gauche.

Share this post


Link to post
Share on other sites
(...) Toutes les tables sont essentielles et fournissent la logique. Aucune ne trône au centre, à droite ou à gauche.

Et ils sont où les modèles qui donnent le "point de vue" ? :unsure:

Share this post


Link to post
Share on other sites
Et ils sont où les modèles qui donnent le "point de vue" ? :unsure:

Pas très loin, recule encore un peu :D et rajoutes 'Occurrences de' entre 'les' et 'Tables' ;)

Share this post


Link to post
Share on other sites

J'apprécie l'allusion à ma presbytie galopante, je recule un peu et... ok vu ! :D

Share this post


Link to post
Share on other sites

:D:D:D

Hé ho gamin, tu feras l'exo lundi et on en reparle, non mais !

Share this post


Link to post
Share on other sites

Rodolphe,

Je pense que tu dois, pour aborder la notion de module, sortir les GOT de ta tête, sinon tu vas te planter. Fais plutôt le schéma en 2 temps :

1) un module, avec du A&B, comporte le plus souvent plusieurs GOT, et est un processus indépendant, avec ses propres GOT, ses propres OT, ses propres script et ses propres modèles.

2) après, si (et seulement si) tu adopte la méthode de lien d'Ugo, tu lies tout avec tout au sein d'un module, et ainsi tu fais sauter toutes les redondances de lien qui étaient générées par A&B, et tu profites du double sens des liens (ce que, volontairement, nous ne faisons pas en A&B, par définition).

Ainsi, tu n'a, au final, qu'un "paquet" d'OT liées par module (qui ressemble vachement à un GOT, mais qui, à mes yeux n'en est plus un, vu qu'il n'y a plus d'ancre). De mon point de vue, c'est jouable si et seulement si le nombre de liens au sein d'un module est limité, au risque de noyades dans les contextes de calculs et de scripts. Mais c'est possiblement le cas.

Un point me reste un peu obscur, et c'est bien, Ugo, que tu ais cité la table des contacts : une table peut-elle participer à plusieurs modules ? Je pressent que oui, mais...

Christian

Share this post


Link to post
Share on other sites

Si j'en crois le graphe modulaire présenté par le Maître nageur, oui, une table participe à plusieurs modules (au reste jene vois comment il pourrait en être autrement).

Sinon, tu confirmes un peu ce que j'ai vu en prenant du recul, des modèles sur toutes les OT, et un beau paquet à gérer, donc faut savoir nager dans les liens et les calculs et je comprends encore mieux son nouvel avatar :D

Nez en moins, me semble que l'association des deux modes de fonctionnement A&B et modulaire n'est pas du tout incompatible, ce qu'on gagne en bidirectionnalité par l'un pouvant être éclairé par ce qu'on gagne en lisibilité de l'autre.

( et c'est un peu ce qu'il m'est arrivé de faire, en reliant, oui, je l'avoue, je l'ai fait et j'espère qu'on me pardonnera, deux ancres dans un modèle AB) :wacko:

Share this post


Link to post
Share on other sites
Un peu d'abstraction ne fait jamais de mal.

Je sens poindre ... une lumière au fond, tout au fond là bas :)

"Ce ne sont donc pas les fonctionnalités qui sont mises en avant mais les données; Vos données qui, quelque soit l’enveloppe externe, restent à portée de main."

Dans le lien que tu nous a fournis, il y a cette phrase qui me semble bien résumer le "vers quoi" ce sujet semble aller. Un but, en quelque sorte. Cela éclaire, je crois, pas mal le sens de tes propos depuis le départ.

Et si j'osais, je parlerais d'un début de changement intermédiaire entre le concept de "séparation données-structure" et de "fonctions". Je crois me souvenir que pour toi, Ugo, la séparation sturcture-données n'est pas dans le registre du réaliste (ce en quoi je crois aussi, sur bien des aspects), mais par ce biais, tu nous fait rejoindre plusieurs aspects, autour d'une forme de "données bruts" qui seraient, sous certains angles la concrétisation de cette séparation "données" et "structure" en poussant un chouïa plus loin la logique en travaillant d'une manière à ce que cela soit, dans certains cas, réutilisable ailleurs.

J'ai bon là ?

Maxence, nain.

PS: peux-tu nous mettre une version BIEN plus grande de ton MCD proposée plus haut, c'est illisible aux yeux des quadras, j'ose pas imaginer à ceux des Kumquats du clown gracieux ;) ahhhh... c'est kinka :D

Share this post


Link to post
Share on other sites
(...)

mais par ce biais, tu nous fait rejoindre plusieurs aspects, autour d'une forme de "données bruts" qui seraient, sous certains aspects la concrétisation de cette séparation "données" et "structure" en poussant un chouïa plus loin la logique en travaillant d'une manière à ce que cela soit, dans certains cas, réutilisable ailleurs.

(...)

Tu prépares une maîtrise de philo en Espagne ? on dirait une thèse sur Hegel :D

Share this post


Link to post
Share on other sites

ha ben s'il fait une thèse de philo, je suis nonne... nan... pilote de chasse ... nan... cosmonaute.... et lui est l'ordinateur Hal :ninja:

Share this post


Link to post
Share on other sites
et lui est l'ordinateur Hal :ninja:

Hal ?? :o Eugène ?

Maxence, lumière :D

Share this post


Link to post
Share on other sites
Au fait, j'ai fait une version Powerpoint du Keynote si ça t'intéresse

Le keynote, sans le bonhomme qui donne les explications (ou fait le clown, dans mon cas) à coté, ca n'a que peut d'intérêt. Un keynote n'est *pas* un tutoriel.

Cette session visait l'ouverture, suggérait certains nouveaux comportements face à nos développements surtout. La programmation modulaire exige un état d'esprit, et ses principes sont applicables, dans tous les développements, qu'ils conduisent ou pas au modulaire, in-fine.

Je n'en suis pas certain. La programmation modulaire implique (en théorie) un certain niveau de découplage entre les modules, une interface bien définie ("interface" au sens "moyen de communication entre le module et le reste de l'appli" du terme, pas au sens "écrans et boutons") et une dépendance unidirectionnelle (si A dépend de B, B ne dépend pas de A). Or, je vois mal comment appliquer à FMP les patterns type "inversion de dépendance".

Je ne nie d'ailleurs pas qu'on puisse procéder à des décontextualisations sans adopter le modulaire.

Normal, les deux n'oppèrent pas au même niveau.

  • Les modules, tu travailles sur l'isolation à un niveau macro, sur l'architecture de l'application
  • La décontextualisation (et donc, excuse-moi, le test unitaire développement piloté par les tests), tu travailles à un niveau micro, sur les fonctions et les scripts.
... une démarche qui consiste surtout à ce que chaque élément puisse être développé, puis assemblé, distinctement.
Le développpement modulaire, à la fmp, si on veut, c'est obtenir un applicatif divisé en unités disposant de leur propre logique, parfaitement décontextualisés, communiquant entre eux par script et via une interface, indépendants les uns des autres, permettant de mieux maintenir un développement, et de le faire évoluer...

Je vais encore jouer le rôle du grand méchant, mais je persiste et signe :

Pourquoi faire cela en FMP ? Il me semble que tu dévois le principe d'utilisation de ce logiciel. Quel est l'argument des utilisateurs de FMP ? La *simplicité* et la *facilité*. Quand on veut faire des choses plus complexes, on se retrouve bien contraint d'utiliser une de ces "astuces" à la cache-moi qui alourdissent tout, et que beaucoup (dont toi) détestent.

Il est tout à fait possible qu'on puisse faire du découpage modulaire dans FMP, mais à quel prix ?

Y mettre un pied, utiliser la bi-directionnalité des liens, avoir une approche un peu plus modulaire, je suis d'accord, et plutôt deux fois qu'une. Mais pousser jusqu'à avoir des blocs isolés, vu de ma fenêtre, c'est une erreur de choix d'outil.

Globalement, en fin de compte, tu mets de l'eau à mon moulin

Ce n'est pas la première fois qu'on tire dans la même direction, et à mon avis ce n'est pas terminé.

La question est plutôt "jusqu'où" ?

Bon, il y a toujours cette petite note de scepticisme quant à l'adaptabilité de la plateforme à cette démarche.

Petite ? tu rigoles, j'espère ! ;)

Parfois, j'arrive à des choses avec même plus de souplesse que ce qu'on pourrait faire avec Servoy (...). C'est juste pas la même "programmation"

Non, ce n'est pas la même programmation. Ce n'est pas non plus la même approche ni la même philosophie. Je n'ai pas dit que FMP était moins bien que Servoy ou Delphi ou Java ou autre, je dis que *dans ce contexte*, FMP me parait franchement inadapté. Mais je ne demande qu'à être détrompé.

Par contre, méfie-toi d'une chose : tu connais Servoy nettement moins bien que FMP, et donc tu n'as peut-être pas encore une vision globale de la bête. On en reparle dans qques années.

Autant je pense sincèrement que le développement piloté par le test (avec une approche micro) est tout à fait adoptable dans le cadre de FMP, autant j'émets de très grosses réserve sur le coté modulaire (et l'approche macro)

Yvan

Share this post


Link to post
Share on other sites

Bon,

Autrement dit, Yvan, entendons nous sur le degré de modularité avant de parler de modularité pure.

Si, dès lors on s'entendait sur ce degré possible, et sur ses bienfaits quand il est atteint ?

Quand je parle d'un état d'esprit, et des principes, je n'entendais pas en effet balayer le spectre intégral du théorème de la séparation des Aspects, depuis les données jusqu'à l'inversion de contrôle. On change de périmètre, assurément. Là, on plonge dans la Programmation Orientée Aspect, et le soleil de Roissy ne m'a pas aveuglé à ce point ;)

Pas de délégation ni d'inversion pure donc, mais en comprenant la logique de toutes ces lignes de conduites, les problématiques associées à ces patterns, des séparation de comportements, des extensions, il y a nécessairement une logique générale, un état d'esprit donc, qu'on peut malgré tout adopter, au moins pour transformer la façon dont on programme, lorsqu'on pose nos deux fesses sur ce fauteuil.

C'était encore une fois le propos de cette session que de s'interroger, surtout. Une fois l'interrogation posée, il faut comme tu me l'avais d'ailleurs suggéré ces brassières de secours pour ceux qui ont lâché dès la seconde syllabe du mot 'Programmation Orientée Aspect'. Pourquoi pas dès lors le faire ici, profiter de cette fraîcheur, de ta vision globale, de la mienne pleine d'interprétations, de la volonté des uns et des autres d'approcher d'autres méthodes.

Tu nous diras justement quand les limites ont été dépassées, cela pourrait d'ailleurs être extrêmement intéressant de les situer dans les faits, et dans nos actes. Alors oublions les 10 commandements, empruntons sans voler, travaillons 6 jours, etc... ;)

Share this post


Link to post
Share on other sites
J'ai bon là ?

En gros, oui. Sauf que j'ai pas tout compris ;)

Toutes les métaphores sont bonnes à prendre, mais il faut regarder plus loin toujours. Ici, cet appareil est placé dans différents modules qui ne communiquent pas entre eux. C'est donc en effet dans ce cas des processus isolés où les données sont mises en avant.

Dans des systèmes d'informations où tout circule, et où les dépendances se créent, ce sont plus les utilisations de ces données qui passent au premier plan.

mais bon, déjà un module n'est plus ce petit bidule qui a crâmé sur l'allumage de la BX, on avance ;)

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...