Jump to content
Ugo

Session Modularité

Recommended Posts

C'est déjà fini ? Mais non, ça se poursuit, et les couloirs de notre forum sont tout aussi bruyants que tous ces avions qui nous ont survolés ce week-end.

Dans le respect des éditions précédentes, les pre-sessions qui vous ont été proposées avaient des visages opposés. Celle présentée par Fabrice était à vocation pratique, l'autre que j'ai eu l'honneur d'animer, était plus suggestive.

Parce-que céder la face 'Pratique' à mon ami Fabrice ne me satisfais guère, je vous propose de poursuivre le débat ici, comme Olivier l'a suggéré en clôture de cette Conférence. Synthétiser en 2 heures ( +30 minutes, pardon pour ce dérapage... ) et 300 diapositives - gloups :blush: - ce qui fait l'objet d'une formation de 3 jours n'était pas une mince affaire. Il ne pouvait s'agir que d'une introduction, suggérant des interrogations qui n'ont pas manquées, et je vous en remercie. Je sais que j'en ai rassuré certains, et que d'autres étaient apeurés de me croiser ce week-end. Mais non, il faut pas ;)

Peut-être donc, à l'occasion, souhaiteriez vous ici apporter vos commentaires, questions, critiques, suggestions, sur ce que je vous ai exposé. Pour ceux qui n'auraient pas pu se joindre à nous en ce week-end studieux, afin que nous puissions débattre, permettez moi d'effectuer ce bref résumé, que j'espère fidèle au fil conducteur de la session, détaché de sa dose technique.

Peut-être permettra-t-il également à ceux qui se croyaient sur une autre planète, ou que j'ai perdu dans les derniers virages, de raccrocher le wagon et de mieux comprendre ma passion pour Luis d'Antin van Rooten ;)

Programmer par assemblage successifs de modules, de façon itérative, est devenu un standard, quelque soit le language de programmation, pour tous les Systèmes d'Informations. Cela repose sur l'adoption d'un certain nombre de principes, dont le principal est la Séparation des Aspects, seule garante d'un découpage logique du Système d'Informations.

La programmation modulaire ne s'adresse pas uniquement à ceux qui aujourd'hui développent pour revendre des logiciels, qu'ils pourraient alors distribuer sous divers assemblages ; il s'agit d'une méthode de développement dont la finalité, par un raccourci vulgaire, est la ré-utilisabilité, d'un module dans son ensemble, d'un de ses composants, ou de l'un de ses processus. La Séparation par Aspects est donc tout autant un process qu'un principe, qui permettra d'éliminer toute trace d'une quelconque dépendance d'un module envers un autre, au niveau fonctionnel.

On peut atteindre cette perte de dépendance par l'utilisation de techniques dites d'encapsulation, qui permettent de transferer les dépendances du code, du design vers l'interface. Il est malgré tout utopique d'atteindre cette indépendance sans un design adequat, qui variera bien évidemment selon les exactes interactions possibles entre les modules. La programmation modulaire ne tolère par ailleurs aucune systématique, l'existence de bibliothèques ou de modules déjà développés, s'ils peuvent considérablement réduire les besoins de l'analyse, ne s'y substituent aucunement.

Toute division qui n'est pas conduite sur la base de la logique mène au chaos. Le schéma 'Ancres et Bouées', comme il a été démontré, est l'anti-thèse de cette programmation. Il répond certes en partie aux angoisses des développeurs, mais au grand jamais à la demande de souplesse du Système d'Informations exigée par l'entreprise. L'adoption de ce schéma est donc néfaste, tout d'abord parce qu'il brime l'ingéniosité du développeur FileMaker, et qu'il néglige les principales avancées conduites par FileMaker depuis la version 7. Mais aussi, et surtout parce que la multiplication des occurrences de tables à laquelle il conduit au travers la division systématique structurelle ( lisez par Table ), n'apporte que redondance et dépendance. Celle-là même qui nuit à tout processus itératif et à l'aspect véritablement modulaire d'un applicatif.

L'assemblage d'un module ne peut être entrepris qu'après que toute dépendance ait été anihilée. En pratique, un module ne communique avec un autre qu'au travers de son interface. L'indépendance exige que chaque module puisse être développé, puis assemblé, distinctement, ce qui implique qu'un module ne pourra en aucun cas exploiter les processus d'autres modules, ni même faire appel directement appel à des élements d'interface d'un autre module. Les interfaces bien entendu ne comporteront pas non plus de dépendances vers d'autres modules, la navigation unifiée dans le logiciel constituant alors souvent, un module à part entière.

Une fois les bibliothèques constituées, les process unifiés et décontextualisés, voire externalisés, les éléments d'interface structurés, l'assemblage d'un module pourra être envisagée. Pas avant.

Comme lors de la Session, parce qu'un débat ne vaut que s'il s'oppose à quelque chose, radicalement, vous aurez noté que je pose comme principe que le schéma modulaire est un schéma valide. Et que je l'oppose avec grande délicatesse à ce schéma AB :) Il n'est pas universel non plus, sinon la systématique que je dénonce me serait rétorqué à raison. Des éléments constituants d'Ancres et Bouées peuvent très largement y être utilisés.

Même si je considère que c'est vouloir faire la traversée de l'Atlantique en aviron. <_<

J'attends vos suggestions, commentaires, idées sur ce sujet. Voyez comme je peux être sérieux parfois ! :closedeyes:

Share this post


Link to post
Share on other sites

Hello,

eh ben moi, j'ai essayé de m'accrocher jusque dans les derniers virages, et même si j'ai fermé les yeux et aggripé ma ceinture (pour ne pas dire "serré les f...") dans certaines courbes, j'ai apprécié la "balade" (sic)

Je ne vais pas vraiment ouvrir le bal au niveau du débat, mais juste exprimer une petite frustration que je partageais avec certains à la sortie, du côté pratique justement (frustration qui n'est pas un reproche, vu comment se positionnait la session) :

On a à peu près suivi les grandes lignes et les principes, mais on aurait aimé qques exemples de mise en oeuvre de ces encapsulations (couché ! ;) ), assemblages et autres décontextualisations.

Par "exemples" j'entends principes, techniques, voies à suivre, citées en gros, pas un didacticiel, of course.

Bref, ça peut être dans un 2e temps, après le débat..., mais ça en intéresserait plus d'un je crois.

Même si je considère que c'est vouloir faire la traversée de l'Atlantique en aviron.

Ou traverser la piscine à califourchon sur une bouée, en pagayant avec une ancre... :D

Share this post


Link to post
Share on other sites

Bonsoir Laurent,

La démarche impose nécessairement une prise de recul. Au coeur d'une session, il est difficile donc d'y parvenir, directement. Tu vois, je ne me blâme même pas ;)

Quand il y a une frustration, c'est que quelque part on commençait à y prendre goût, c'est donc plutôt positif :rolleyes:

J'ai parcouru sur la fin de la session plusieurs démarches de décontextualisation de scripts, et la mise en place de bibliothèques. J'avais pris pour coeur de la démonstration, un seul et unique module. Au terme de la session, il est vrai bien rapidement, j'ai mis en perspective l'assemblage au travers d'un exemple très succint, et d'une démarche en 10 points qui aurait mérité une pause, et une petite heure supplémentaire ;)

A cette heure tardive, je ne m'étendrais pas, mais j'y reviendrais volontiers, au travers de quelques exemples illustrés, s'il le faut. Je voudrais malgré tout bien tenir le cap de cette ouverture, plus qu'un ensemble de pratiques.

PS : J'aime bien ton image de l'Ancre. On sent très bien que les bouées ne tarderont plus à être emportées par une ancre si lourde, quand la profondeur augmente. :P

Share this post


Link to post
Share on other sites

Bonjour Ugo,

Merci de faire partager tes "élucubrations" avec de malheureux qui n'ont pu, comme moi, et pour diverses raisons, aller t'écouter (et les autres), "en temps réel", à la Conférence.

En te lisant, je me suis mis à rêver et en me réveillant, je me suis demandé si tu parlais de Filemaker.

S'il est vrais que depuis la .fp7, les choses ont beaucoup changés, je pense de plus en plus que FM est resté un superbe logiciel pour développer rapidement une petite application mais à partir du moment où on commence à "bidouiller", on atteint (dépasse) les limites du logiciel, même si comme beaucoup, j'y trouve un côté ludique.

Je ne prétends pas être arrivé à la connaissance du logiciel FM mais cette modularité n'est-elle pas l'apanage d'applications plus évoluées (et plus complexes aussi) où la séparation des données notamment est toujours présente ?

Ne faut-il pas utiliser FM en tant que tel, (relativement) simple à mettre en oeuvre, rapide à digérer et qui permet de réaliser rapidement des applications de complexité moyennes. Ce qui lui donne beaucoup de qualité!

Le schéma 'Ancres et Bouées' que tu dénigres est, même si ce n'est pas le schéma idéal, est malgré tout le plus lisible et celui permet, pour le béotien que je suis, de retrouver ses jeunes après avoir les avoir abandonnés quelque temps.

C'est aussi très important pour un programmeur occasionnel qui a choisi FM pour cette raison.

Depuis la v7 nous avons eu droit à des avancées mais qui ne sont malheureusement jamais finalisées complètement.

Alors, comme tout le monde, j'essaye de modulariser mais .. pas facile.

Merci pour tes considérations. Je serai le premier à essayer d'appliquer tes recommandations.

Robert

Share this post


Link to post
Share on other sites

Salut à toi Ugo et merci de faire partager aux absents tes idées.

S'il est vrai que le développement par module est un objectif (pour un developpeur) ambitieux mais au combien difficile à atteindre s'il veut rester dans un schéma clair et retrouver ses petits.

Jusqu'à présent, au lumignon de mon expérience je n'ai jamais réussi à obtenir un mélange des deux tendances qui me satisfasse.

Ou j'ai découpé l'appli en module prévue ou à venir, et le schéma relationnel etait tout sauf... "relationnel"avec plutot une tendance Picasso qui serait passé dire bonjour à Raoul avant.

Donc Débat : oui, mais s'il etait possible d'avoir (Olivier ?) un bref résumé de tes élucubrations Roissyesque ce serai plus parlant

Merci en tout cas pour ce début

Bertrand

Share this post


Link to post
Share on other sites

Bon, on comprend mieux le silence qui s'est installé pendant 3 voire 4 jours. Attaqués de cette manière, plus d'un ont du restés scotchés.

Quelques remarques pour répondre à ta demande de débat ;)

(...)

(...)

Une fois les bibliothèques constituées, les process unifiés et décontextualisés, voire externalisés, les éléments d'interface structurés, l'assemblage d'un module pourra être envisagée. Pas avant.

(...)

Ceci ne me semble pas du tout incompatible avec un système d'ancres et de bouées, sans doute plus sophistiqué et moins redondant (quoique) que celui que nous pratiquons actuellement. Finalement qu'est-ce qu'un module ?

La décontextualisation des process est devenue beaucoup plus simple avec la V10, du moins de certains process (cf le petit auditlog v10). Mais au-delà de ça et dans le contexte précis de FMP, j'avoue ne pas comprendre globalement cette notion.

Donc, et pour résumer, à l'instar de mes petits camarades, il me semble qu'un petit exemple concret, ne serait-ce qu'un fichier de base appliquant ces principes serait en effet le bienvenu ;)

PS et CustomList dans tout ça, n'est-ce pas l'exemple parfait de l'encapsulage-décapsulage puisqu'on peut tout faire de n'importe où ? :ph34r:

Share this post


Link to post
Share on other sites

Hello Robert,

Je dénigre pas, je provoque ;)

Le résumé n'était pas assez fidèle. Ancres et Bouées est un schéma général valable pour de petites applications. je fais ici une distinction entre une Base de Données isolée et un Système d'informations, plus complexe, plus complet, plus gourmand aussi. La programmation modulaire implique une bonne dose de...programmation, donc de processus scriptés. Elle n'est donc pas destinée à être employée pour l'établissement d'une gestion de dvdthèque, et comporte des lourdeurs de mises en place qui ne sont bien entendu pas adaptées aux béotiens, qui n'étaient pas visés par cette pre-session.

Avec toutes ses imperfections, FileMaker progresse malgré tout versions après versions vers des niveaux toujours plus élevés de compétences et de fonctionnalités. C'est parce-qu'aujourd'hui on peut établir de vraies comparaisons avec des concurrents que nous regardions d'en bas précédemment, qu'on devient plus exigeants. Seul le groupe d'utilisateurs stratégiquement visé reste immuable.

Mettre en balance la plateforme, c'est donc avant tout un choix qui est toujours l'affaire d'un contexte donné. A l'image des langues vivantes, il est toujours intéressant de disposer de plusieurs langues, justement pour pouvoir utiliser celle qui convient le mieux pour nos déplacements. Certains des participants fumeurs se souviendront sans doute de ce petit aparté ;)

C'est tout aussi vrai pour l'application d'un schéma modulaire.

Nous ne disposons pas d'une séparation entre interface et données, c'est un fait. Ceux qui s'y sont aventurés dans Filemaker auront sans doute heurté le mur de la logique, car sans un isolement de la logique ( Business Logic ), cette séparation est toujours incomplète et inopérante à mes yeux.

La programmation modulaire implique une forte dose de séparation, il est vrai, mais pas nécessairement celle-ci, justement parce qu'à cette séparation par couche horizontale ( Présentation, Business Logic et Data ), on peut opposer une séparation verticale par module, dans laquelle chacun dispose de sa propre logique. S'il n'est pas rare d'aboutir à une double séparation, ou chaque module dispose alors de ses propres couches d'Interface, de Logique et de Données, c'est probablement plus le cas dans des cibles qui ne concernent pas Filemaker ; si véritablement l'intérêt de ces séparations est de ne maintenir à jour qu'une couche de Présentation, j'ai quelques doutes à ne concevoir aucune révision de la couche Data ou Logique au fil du temps en plus. Si c'est d'une mise à jour qu'il s'agit, qu'on nous donne un outil de mise à jour dans Filemaker, et pis c'est tout comme dirait l'autre.

Et puis comme dirait alors Yvan, sans bougonner, où arrêtes-t-on véritablement cette séparation horizontale par couche ? http://en.wikipedia.org/wiki/OSI_model

La lisibilité du schéma Ancres et Bouées, quand on monte en gamme et que l'application se transforme en système d'informations, ne me semble pas du tout évident. Concentrer autour d'une ancre des bouées de plus en plus nombreuses, au fil du temps, ça rend les choses bien moins évidentes que la théorie le laisse entendre.

Séparer l'applicatif en déterminant des frontières logiques, ne nuit aucunement à la lisibilité. On identifie mieux chaque aspect dans le graphe, le parcours d'un processus est très nettement balisé au sein du seul module, les scripts sont parfaitement identifiables et ne peuvent faire appel qu'à leurs frères et soeurs ou à des bibliothèques commnunes.

Sauf à traduire rapidement que ce qui n'est pas Ancres et Bouées est nécessairement Spaghetti, je ne vois aucun problème de lisibilité de mon côté.

Voici un seul GOT d'une application développée en A&B et qui en comporte 45, dont 12 de la sorte

Image_7.png

, et voici un éclatement en 5 modules d'un applicatif comportant 12 tables.

Image_5.png

Il ne s'agit que du résultat d'une première approche modulaire, d'autres petits aménagements conduiront à encore plus de lisibilité ( occurrences disposant de modèles en Majuscules, etc. )

à partir du moment où on commence à "bidouiller", on atteint (dépasse) les limites du logiciel, même si comme beaucoup, j'y trouve un côté ludique.

Au fil des lectures qu'il m'a fallu parcourir pour structurer au mieux cette présentation, je suis tombé sur cette citation, que je n'ai finalement pas intégré, mais qui me démangeait ;)

"les programmeurs...se réfugient souvent dans une compréhensible, mais désastreuse inclinaison vers la complexité et l'ingénuité dans leur travail. Puisqu'ils ne sont pas autorisés à développer quelque chose de plus grand qu'un programme, ils font tout pour rendre ce programme suffisamment compliqué pour mettre au défi leurs compétences professionnelles."

"Programmers… often take refuge in an understandable, but disastrous, inclination towards complexity and ingenuity in their work. Forbidden to design anything larger than a program, they respond by making that program intricate enough to challenge their professional skill."

Image_7.png

Image_5.png

post-106-1238486665.png

post-106-1238486729.png

post-106-1238486665.png

post-106-1238486729.png

post-106-1238486665.png

post-106-1238486729.png

post-106-1238486665.png

post-106-1238486729.png

post-106-1238486665.png

post-106-1238486729.png

post-106-1238486665.png

post-106-1238486729.png

post-106-1238486665.png

post-106-1238486729.png

post-106-1238486665.png

post-106-1238486729.png

Share this post


Link to post
Share on other sites

Salut Ugo,

si tu autorise les non-conférenciers à participer, je veux bien en être ;)

Une question : Est-ce que cette faculté à proposer des modules (qui s'appuient sur des choses réalisées par le passé) n'incite pas, par défaut, le développeur à proposer "sa" solution, au lieu de repartir sur une feuille blanche ?

Un exemple concret : Deux projets, un qui date d'il y a une bonne dizaine d'années et un autre très récent. Deux industries, d'apparence très proche. Plus de 85% des travaux sont communs entre les deux entreprises. Les petits 15% de différence, oblige à repenser tout l'ensemble, soit.

Au final, j'ai moins de 20% de "lieux communs" entre les deux projets, certes, les aspects CRM sont très proches, mais le processus, et la manière d'aborder les données sont gérées de manière très différentes.

Le fait d'avoir une base de modules déjà réalisé ne va-t-il pas inciter le développeur à faire aller son client sur ce terrain, au lieu d'aller vers celui du processus du client ?

Par delà ces aspects "prêt à proposer", est-ce que cela fonctionne dans un monde comme celui proposé par Yvan Picot, la méthode Agil ?

Et si tu peux nous donner des clés sur cette évaluation en amant, avant même de déterminer le type de développement ?

Merci

Maxence

Share this post


Link to post
Share on other sites
complexity and ingenuity

Attention, faux-ami :

(GB) ingenuity = (FR) ingéniosité

(GB) naïvety = (FR) ingénuité

;)

-- edit --

Et si tu peux nous donner des clés sur cette évaluation en amant

Attention, (dangereuse) faute de frappe :

(Good for You) donner en amont

(Very Bad for You) donner en amant...

:D;)

Share this post


Link to post
Share on other sites
PS et CustomList dans tout ça, n'est-ce pas l'exemple parfait de l'encapsulage-décapsulage puisqu'on peut tout faire de n'importe où ? :ph34r:

Cette fonction, à l'état pur, viole toutes les règles de la séparation des aspects. Une fonction pour une tâche. Je recommandais l'adaptation de cette fonction vers des fonctions, dont le nom refletterait la tâche accomplie. Sans jamais toucher le code de la fonction, simplement en l'utilisant au sein d'une autre fonction.

Mais c'est un autre débat qui s'est engagé ;) et je sais qu'il sera difficile :D

Il tient plus à la lisibilité du 'code' qu'à autre chose, mais il permet d'illustrer aussi le principe de Séparation des Aspects.

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.

Edit: Oui, on peut appliquer la modularité avec un schéma A&B, je le vois accompli par certains déjà dans mon entourage. Mais il relève de l'exploit, et pour y parvenir pelinement, il forcerait à renoncer au TOG Surfing, soit à se déplacer d'une ancre à une autre au sein d'un même processus. C'est donc une limitation énorme qui à mon avis remet considérablement en cause l'un des autres principes fondateurs de A&B.

Share this post


Link to post
Share on other sites
Attention, faux-ami :

(GB) ingenuity = (FR) ingéniosité

(GB) naïvety = (FR) ingénuité

;)

Très joli ;)

nous sommes donc tous des génies naïfs :D

Merci, encore un truc appris grâce à cette conf B)

Share this post


Link to post
Share on other sites

je réponds dans le désordre ;)

Ou j'ai découpé l'appli en module prévue ou à venir, et le schéma relationnel etait tout sauf... "relationnel"avec plutot une tendance Picasso qui serait passé dire bonjour à Raoul avant.

Difficile de formaliser un graphe relationnel modulaire. Mais il pourrait être composé d'éléments ( groupes ) enfermant leur propre structure relationnelle. Dans certains cas d'ailleurs, quand la fonction colle à la Table ( ex. Emailing ), une 'structure' du type Ancres et Bouées pourrait y être introduit.

La clef n'est malgré tout pas dans le graphe, si je puis me permettre. Celui-ci n'est que le reflet remanié et réorganisé d'une 'zone' extraite d'un Diagramme Entités Relations au service du module. Il n'a pas vocation à s'y substituer. En modulaire, l'étude du graphe se concentre sur un module à la fois, en ignorant les autres, qui sont complètement distincts. Cela revient à véritablement s'intéresser à l'essentiel à chaque lecture. C'est moins distrayant ;) mais presque plus important que le choix des couleurs :rolleyes:

Share this post


Link to post
Share on other sites
Une question : Est-ce que cette faculté à proposer des modules (qui s'appuient sur des choses réalisées par le passé) n'incite pas, par défaut, le développeur à proposer "sa" solution, au lieu de repartir sur une feuille blanche ?

Par delà ces aspects "prêt à proposer", est-ce que cela fonctionne dans un monde comme celui proposé par Yvan Picot, la méthode Agil ?

Ceci m'amène à faire quelques redite de la conférence. On ne construit pas un 4x4 à partir des roues d'une Clio. Tout n'est pas réutilisable donc, et il faut procéder par ordre.

Comme je le précisais, c'est avant tout un état d'esprit qui vise à la réutilisation, pas nécessairement une volonté de ne réutiliser que des briques existantes.

Le schéma idéal serait qu'au fil du temps, nous disposions justement d'une multiplicité de modules pouvant satisfaire chaque cas.

Mais la réutilisabilité passe aussi par des bibliothèques de fonctions, qui pour le coup elle sont totalement réutilisables, en ayant découpé l'action en plusieurs éléments essentiels. Et la volonté surtout est de pouvoir faire évloluer l'applicatif, si besoin, par l'extension d'un module, par modification de celui-ci sans impact sur le reste de l'application. C'est surtout cette Séparation là qui donne son sens au modulaire.

La méthode Agile, dans bien des cas, comme toutes les autres, exploite les modules comme base de développement. Son approche par tests et cycles itératifs n'en est que plus simple, souvent.

Share this post


Link to post
Share on other sites
Donc Débat : oui, mais s'il etait possible d'avoir (Olivier ?) un bref résumé de tes élucubrations Roissyesque ce serai plus parlant

Merci en tout cas pour ce début

Mais il me semble que c'est ce qui a été fourni en tête de ce fil. :blush:

L'objet n'est pas de retranscrire une session à laquelle certains ont participé et d'autres non. On ne refait pas le film, en quelque sorte, et ce n'est pas mon objet ici que de faire un résumé comme ceux que j'utilisais niaisement pendant mes épreuves du Bac ;)

Le film comporte une thématique, on peut la recouvrir au travers de plusieurs discussions, de plusieurs visions ou méthodes.

Moi j'aime l'échange et le débat ;)

Share this post


Link to post
Share on other sites

Bonjour,

Cette session m'inspire aujourd'hui quelques remarques, peut être incomplètement fondées.

  • Je suis assez d'accord avec Rodolphe concernant l'utilisation de "ancre boué". À mon sens cela dépend de la "taille" de l'application.
  • Pour les développeurs en entreprise (dont je suis) la mise en œuvre demandera du temps ; on ne refait pas le SI tous les jours. :blink:
  • Incontestablement cette session nous donne du grain à moudre pour quelques heures et participe à l'évolution de nos pratiques.

Je vais donc suivre avec attention le fils de cette discussion.

Il fait beau à La Rochelle :P

Share this post


Link to post
Share on other sites

Sacré Ugo ! A force de taper sur le clou, tu finiras bien un jour par nous convaincre :P

Je dois admettre que AB deviens fort épais dans certaines applis ambitieuses, et que l'avantage de la "lecture" des noms d'OT se perd dans d'interminables listes. Une première approche est la multiplication des GOT, plusieurs ancres étant représentatives de la même table. Selon le "contexte de travail", comme tu te plais à les nommer (avec raison) : ainsi le nombre de bouées diminue par ancre.

Tu me rétorqueras que, gardant le schéma AB, même allégé, on ne profite pas d'une propriété évidente de FMP : le double sens d'un lien. En profiter, comme tu le fais, diminue évidemment drastiquement le nombre d'OT, et allège conséquemment le développement. C'est exact.

Néanmoins, AB a des avantages que j'estime non négligeables, et je tenterai par tous les moyens dont je dispose d'empêcher mes "débutants" de lire tes écrits iconoclastes :lol::D En effet, un des avantages d'AB est que, lorsque le franc l'euro est tombé, le développeur moyen ne se plante plus, ni dans ses nommages ni dans ses liens. Autre avantage : l'ancre : elle sert de contexte de modèle, toujours (donc erreur nulle) et de contexte de calcul (donc erreur nulle), son trigramme est utilisé dans les noms des modèles, avec tous les avantages que l'on peut en tirer, dans des noms de scripts particuliers, dans des noms de listes contextuelles, etc, etc. Pour moi, avec ma casquette de formateur, l'avantage est évident et mes cauchemards diminuent drastiquement... Mais comme tu le dis toi-même, ta méthode ne s'adresse pas à la blonde débutante qui se rue sur le Business Productivity Kit ! (me vais me ramasser sur le râble les blondes débutantes et FMP, moi... :ninja: ). Car, c'est personnel bien sûr, j'estime que la plus grande faiblesse de ta méthode est le plantage de contexte potentiel : faut être prudent...

Je me demande, à la relecture de tes écrits, si tu ne mélange pas deux choses, finalement :

1) le double sens d'un lien, qui diminue le nombre d'OT

2) la séparation en modules

Non ? Dis-le.

Quant à cette séparation en modules (qui est un peu la conquête du Graal :glare: ), à te lire, je me demande si, finalement, une bonne méthode ne serait pas de re-séparer en divers fichiers, vu que FMP le permet. Un script étant intimement lié à un fichier, on coupe les liens inter-fichiers, on embarque ce dont on a besoin en dessous du bras pour aller dans le fichier d'à côté, et le tout est joué. Non ? Cfr facturation, que tu connais.

Intéressant débat. Je suis en tout cas convaincu que pour développer une appli un tantinet épaisse, une autre méthode doit être abordée, et le développement par modules prometteur.

Ciao, et n'assomme pas trop tes petits camarades :rolleyes:

Christian

Share this post


Link to post
Share on other sites

Je crois que, sur la forme au moins (et il est difficile de juger du fond avec des images), les modules que tu nous présentes dans ta 2eme copie d'écran s'apparentent totalement à ce que je considère comme une évolution possible de la notion d'A&B.

Je ne sais pas où sont posés les modèles (et c'est sans doute une différence majeure), mais néanmoins je remarque que chaque module tourne autour d'une OT centrale, unique et différente, ce qui est un point commun majeur également.

Mais peut-être considéré-je déjà, en toute ingenuity (pour ne pas me faire enfler les chevilles, je vous laisse le choix non pas dans la date mais dans la traduction), A&B comme un système modulaire ;)

Share this post


Link to post
Share on other sites

Allez, ensuite je file bosser ! ;)

Salut Eric,

[*]Pour les développeurs en entreprise (dont je suis) la mise en œuvre demandera du temps ; on ne refait pas le SI tous les jours. :blink:

C'est un point essentiel, et tu as raison. On ne peut proposer une vision modulaire que si tout, dès son origine, est pensé modulaire. Autrement dit, il s'agit d'une méthode de programmation, une reprogrammation modulaire est impossible. Même si parfois, on pourra greffer des modules ( ex. un plug-in SPTPit ou MailIt ), mais souvent ils servent de fonctions à eux seuls.

Yo Christian, merci de te joindre au débat,

Tu me rétorqueras que, gardant le schéma AB, même allégé, on ne profite pas d'une propriété évidente de FMP : le double sens d'un lien. En profiter, comme tu le fais, diminue évidemment drastiquement le nombre d'OT, et allège conséquemment le développement.

La diminution du nombre d'occurrences, en soit, n'est pas véritablement un objectif essentiel. Dans certains cas, selon le degré de séparation exigée, il pourrait advenir que le nombre d'occurrences soit presque équivalent. Mais leur répartition pourrait être plus logique.

Autre avantage : l'ancre : elle sert de contexte de modèle, toujours (donc erreur nulle) et de contexte de calcul (donc erreur nulle), son trigramme est utilisé dans les noms des modèles, avec tous les avantages que l'on peut en tirer, dans des noms de scripts particuliers, dans des noms de listes contextuelles, etc, etc. ...

Car, c'est personnel bien sûr, j'estime que la plus grande faiblesse de ta méthode est le plantage de contexte potentiel : faut être prudent...

Un module n'existe que s'il détermine un espace de nom. On pourra comme en A&B utiliser un trigramme pour nommer le module, et je recommande même de procéder ainsi. Les modèles utilisés eux aussi sont préfixés de ce trigramme, les scripts également, les listes de valeurs, si elles sont bordées exclusivement sur ce module, aussi. Les occurrences de tables sur lesquelles un modèle a été constitué peuvent être écrites en pleines majuscules pour les identifier dans une liste...il y a plein de moyens de faciliter la lecture et l'appréhension des modules et de leurs éléments constituants.

Je me demande, à la relecture de tes écrits, si tu ne mélange pas deux choses, finalement :

1) le double sens d'un lien, qui diminue le nombre d'OT

2) la séparation en modules

Non ? Dis-le.

Non ;)

Le double sens du lien permet de profiter de perspectives différentes, je ne m'en passerai pas il est vrai. Surtout si pour rétablir ces perspectives, je dois reconstituer l'environnement comme on le fait avec A&B. Mais il est un complément à la vue modulaire. Ce n'est pas fondamental.

Quant à cette séparation en modules (qui est un peu la conquête du Graal :glare: ), à te lire, je me demande si, finalement, une bonne méthode ne serait pas de re-séparer en divers fichiers

Tout comme Ancres et Bouées, non ? Chaque contexte n'est il pas purement et simplement celui déterminé par un fichier à la mode FileMaker 6 ? Ici, en effet, on pourrait aussi considérer la séparation de modules en fichiers, pourquoi pas. Les maintenir séparés dans leur propres fichiers jusqu'à utilisation est aussi une de mes ambitions. Mais cela nécessite ( juste pour cette phase de développement ) de disposer de tous les éléments au sein de ce seul fichier, ou alors d'appliquer la séparation Données/Interface, donc. Pour aller piocher des données dans des réservoirs.

Share this post


Link to post
Share on other sites
Je ne sais pas où sont posés les modèles (et c'est sans doute une différence majeure), mais néanmoins je remarque que chaque module tourne autour d'une OT centrale, unique et différente, ce qui est un point commun majeur également.

Dans le cas d'un module de Commande ( ce qui n'est pas le cas ici ), la table Commande et son occurrence sera manifestement un croisement plus utilisé. Mais elle ne constitue aucunement le coeur du module, ni n'est l'unique carrefour. Ceci dépend essentiellement des fonctions associées au module. je vois au moins que le graphe n'est pas illisible ;)

Share this post


Link to post
Share on other sites
Les maintenir séparés dans leur propres fichiers jusqu'à utilisation est aussi une de mes ambitions. Mais cela nécessite ( juste pour cette phase de développement ) de disposer de tous les éléments au sein de ce seul fichier, ou alors d'appliquer la séparation Données/Interface, donc. Pour aller piocher des données dans des réservoirs.

N'est-ce pas le but que tu prônes ? Chaque module a ses propres éléments, contextes, fonctions, scripts, trucs et machins ? Ainsi, on est certain que rien n'est mêlé, ce qui est le but recherché. J'y vois un autre avantage pour le développeur : il peut à loisir travailler sur un module tandis que les utilisateurs jouent déjà avec d'autres modules mis en place. Le cas classique est le rajout du module de facturation après la mise en place du développement de base. Je viens de le faire pour un client qui m'a demandé de rajouter un module de gestion documentaire à son appli : je l'ai faite dans un autre fichier, mis à côté du premier, sans aucun lien commun : vachement pratique, en vérité !

On pourra comme en A&B utiliser un trigramme pour nommer le module, et je recommande même de procéder ainsi. Les modèles utilisés eux aussi sont préfixés de ce trigramme, les scripts également, les listes de valeurs, si elles sont bordées exclusivement sur ce module, aussi. Les occurrences de tables sur lesquelles un modèle a été constitué peuvent être écrites en pleines majuscules pour les identifier dans une liste...il y a plein de moyens de faciliter la lecture et l'appréhension des modules et de leurs éléments constituants.

OK. Faudra préciser un peu tout ça, mais OK, j'achète ;)

Christian

Share this post


Link to post
Share on other sites
N'est-ce pas le but que tu prônes ?

Disons que ce que j'exprimais plus haut, c'était cette faculté tout de même intéressante de disposer de modules prêts à l'emploi, ou celle de développer un module dans un fichier séparé, puis de le greffer à la solution, en ne procédant qu'à un basculement des références aux tables liées. C'est dans ce contexte alors qu'une séparation Données/Interface est envisageable, sans pour autant que cette structure, utilisée dans le cadre du développement du module, ne soit un pré-requis au moment de l'assemblage.

Oui, en tout cas, c'est comme tu le soulignes cette possibilité d'intervenir sur un module sans interférence sur l'autre qui reste la base la plus intéressante de la construction modulaire.

Tout est relatif. pour vulgariser, il y a plusieurs niveaux.

- Oter les roues d'un véhicule l'empêche de rouler, mais ici alors, c'est comme si on enlevait les datas...

- Rajouter un module emailing, c'est ajouter un auto-radio, en quelque sorte

- Dé-programmer l'ouverture du coffre, ou condamner le siège passager, n'empêche pas de rouler, et ne nuira qu'à l'une des fonctions du véhicule.

OK. Faudra préciser un peu tout ça, mais OK, j'achète ;)

Je fais pas de rabais aux premiers arrivants :D

Le nommage n'est franchement pas problématique, l'identifiaction des processus me semble une fois encore plus perceptible avec ce schéma. Selon le niveau de modularisation à laquelle l'analyse nous aura conduit toutefois, l'espace des noms pourrait ou devrait évoluer. L'ensemble des processus de vente d'une entreprise peut être rassemblé au sein d'un seul module, mais comporter des sous-modules Devis, Commandes, Livraisons, Facturation, etc.. Mais il peut aussi être décomposé selon le format de la vente ( comptoir, vente en ligne ). C'est l'analyse qui déterminera la solution appropriée.

A ce jour, je conserve le nom du module du plus haut niveau, dans le graphe, mais sans doute qu'un certain niveau de propriété peut être attaché quelque part, pour identifier et distinguer chaque sous-module, si besoin, si surtout ils peuvent à eux seuls justifier leur séparation du reste. C'est aussi là qu'une séparation des Aspects excessive pourrait conduire. A voir.

Share this post


Link to post
Share on other sites
je l'ai faite dans un autre fichier, mis à côté du premier, sans aucun lien commun : vachement pratique, en vérité !

Au ... je sais que j'ai passé un peu de temps dans les Alpes, mais chui natif de la Sarthe ... pourtant, je crois souffrir de crétinisme :(

Là, j'ai rien compris, ou vous parler de deux fichiers qui ne se causent pas, et donc, qui n'ont aucun liens ... Oú qu'elle est la révolution là ? :(

Autre chose ... avoir pleins de "petits fichiers" et non "table" cela ne va pas sévèrement alourdir eul'bouzin à terme ?

Soit, je suis largué total, soit y'a un épisode qui manque dans la série...

Maxence, desperate neurono(s)

Share this post


Link to post
Share on other sites

Bonsoir à toi,

La séparation en plusieurs fichiers, c'est une autre histoire. Il n'y a pas de systématique sur ce point non plus. Certains modules enfermant des données plus confidientielles pourraient être décrochés. Ou est-ce plutôt une table donnée dans un autre fichier. Peu importe à vrai dire, c'est l'analyse qui déterminera cela.

La communication d'un module vers l'autre ne nécessite en effet aucun lien. Il s'agit justement de les rendre totalement indépendants l'un de l'autre. S'il existe une dépendance, on ne pourrait pas assembler l'un sans l'autre. Un module ne constitue pas l'angle d'une table ici, c'est là toute la différence. Deux modules distincts peuvent attaquer exactement les mêmes tables, ils ne pourront pas exister si ces tables ne sont pas présentes bien entendu, mais communiqueront leurs données au travers leurs processus.

Share this post


Link to post
Share on other sites

Puisque je suis cité dans ce fil, je vais donner mon opinion de non-expert mondial dont la non-compétence est reconnue jusque dans sa salle de bain.

- modèle A/B : je pense qu'il s'agit d'un point de passage obligé pour tout développeur FMP. En gros, il correspond pour moi à la "marche debout". Le débutant crapahute à 4 pattes, et le modèle que tu (Ugo) proposes correspond à la course à pied. Je serai modérément enthousiasmé (euphémisme) si Christian décidait de supprimer ce modèle de son tuto cqfd.

Bien sûr, sur les gros dev FMP, ce modèle devient pénalisant. Mais encore faut-il arriver au niveau de compétence qui te permet de réaliser un gros dev. A noter que FMP ne propose pas -et tu le soulignes toi-même - un vrai modèle Entité Relation, ce qui pourra s'avérer pénalisant à un moment où à un autre dans un dev important, qu'on soit en modulaire ou, pire, en A/B.

- concernant la modularité "intégrale" : je ne partage pas ton point de vue (ou alors je l'ai mal compris, ce qui est envisageable vu mon manque de sommeil).

il n'existe actuellement dans aucun langage à ma connaissance un module "client" prêt à l'emploi. les seuls vrais "modules" en circulation apparaissent sous forme de composant ou de bibliothèque de composant, et proposent un service *limité et défini* (limité au sens "qui a une limite", mais aussi "qui fait peu de choses" et je rajouterai "mais qui le fait bien"). Et ca existe actuellement en FMP : ce sont les plug-ins.

Par contre, je ne te suis pas du tout dans le coté "tout faire en module".

Si j'ai bien compris, tu proposes d'avoir un composant "Client" qui serait réutilisable. Le pb est qu'il est difficile (quasi-impossible) à atteindre. La notion de "Client" est trop variable d'un dev à l'autre. Tu perdrais plus de temps à faire l'adaptation qu'à le recréer en partant d'une base propre, et de découplage entre modules ne serait pas garanti.

En fait, plutot que des modules "purs", je te suggérerai de regarder du coté des design patterns. Ce sont des patrons de conception (patron au sens de "modèle", comme en couture) qui te donnent des modèles à suivre pour tel ou tel cas bien défini (si tu as tel problématique, utilises tel modèle de solution...). A toi ensuite de les adapter à ton langage / ton environnement / ton contexte.

Parmi les patrons les plus connus : le patron Modèle/Vue/Contrôleur (MVC) qui fait le bonheur de nombreux développeurs WEB.

En fait, avec le développement piloté par les tests, je propose un passage en douceur, car à partir du moment où on se demande "comment vais-je tester ça", on arrive tout naturellement (et sans se poser de questions existentielles) à la création de petits scripts et fonctions "décontextualisés". Certains seront réutilisables, d'autres non. La réutilisabilité n'est pas importante à ce moment-là. Pour pouvoir parler de réutilisabilité, il faut avoir un certain recul pour être capable de cerner les différents aspects qu'on désire pour son module.

Le fond, pour moi, est plutot n'inadéquation entre FMP et certains projets. Ton approche hautement modulaire est tout à fait à sa place en Java ou en PHP (PHP "propre"), mais pas forcément dans FMP.

J'ai vraiment l'impression que tu cherches parfois à déménager un piano sur ta mobylette. La mobylette est un outil fantastique pour se déplacer de façon souple et économique d'un endroit à un autre, mais *pas* pour déménager un piano.

Pour ton déménagement, je te suggère plutôt de passer ton permis voiture (ou plus) et d’utiliser une fourgonnette. C’est d’ailleurs ce que tu fais quand tu te mets à Servoy.

Vu de ma fenêtre, la structure intrinsèque de FMP, avec notamment une interface très proche des données, est à la fois sa force et sa faiblesse. Je pense qu’il faut l’utiliser là où il est fort, et employer d’autres outils quand on atteint ses limites (les limites du produit ou les limites du développeur).

Conceptuellement,

Yvan

Share this post


Link to post
Share on other sites

Quel dommage,

A la première lecture, je me suis dis "Youpi, quelqu'un qui conteste, avec des arguments et tout et tout" ;)

Visiblement, il faut que je tempère mon propos ou que je précise davantage, vu les conclusions que tu tires à la lecture de ce fil. Au fait, j'ai fait une version Powerpoint du Keynote si ça t'intéresse ;)

La ré-utilisabilité est l'un des objets de la programmation modulaire, il est vrai, mais la ré-utilisabilité des modules n'est pas la voie que je poursuis. Il n'en a été question aucune fois lors de la session, qui n'adressait pas la problématique des seuls revendeurs de solutions qui seraient tentés de prolonger la vie de leur développement. C'était aussi la même réponse que j'ai faite à Maxence, plus haut, par cette référence à la roue de la Clio pour construire un 4x4. Et en introduction de la session, pendant ta digestion :P , je me suis permis d'ironiser sur l'utopisme de l'expression "Ne pas réinventer la roue"

En introduction à ce fil, tu pouvais lire il est vrai :

par un raccourci vulgaire, est la ré-utilisabilité, d'un module dans son ensemble, d'un de ses composants, ou de l'un de ses processus.

Le côté "vulgaire" n'était pas assez accentué, donc. J'aurais peut-être dû préciser immédiatement que seuls ces composants et processus ont réelle vocation à être ré-utilisés, en tout cas au niveau d'un développement FileMaker ; je serai même tenté de dire qu'on peut l'étendre aux bases de données dans son ensemble.

Maintenant, j'ai évoqué le fait qu'on pouvait compartimenter les logiiels, voire livrer un logiciel avec différents packages, c'est effectivement une démarche que j'ai initié avec des déclinaisons de gamme, sur la base d'un tronc commun. Peut-être cela était confus.

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.

Le coeur de la session malgré tout était axé sur la décontextualisation des scripts, et c'est sous l'angle de la réutilisation des composants que j'ai abordé, si tu t'en souviens, la partie "pratique" de la conférence, en décomposant les éléments de l'interface, puis les processus, en constituant des bibliothèques, et en réutilisant les processus ( au sein d'un même applicatif, au sein du même module même... ). Juste pour rassurer certains lecteurs quand même, j'ai pas fais 2h30 de théorie tout de même, ni même ne me suis transformé en visionaire ;)

Je ne nie d'ailleurs pas qu'on puisse procéder à des décontextualisations sans adopter le modulaire. Même d'ailleurs en utilisant un schéma "Ancres & Bouées", c'est même devenu le jeu favori de Fabrice, ces derniers temps, qui y parvient avec brio. J'en connais une qui joue malicieusement avec FileMaker pour fabriquer des présentations reprenant les effets Keynote, chacun son truc après tout ;) - si, si, malicieusement ! j'insiste ! Moi ces animaux qui criculent en liberté sur ses écrans, ils m'amusaient bien plus, et étaient bien plus techniques que le bubble Chart de FileMaker Inc B) ! -

Plus sérieusement, je pense qu'une fois les lignes de conduite du modulaire acquises, expérimentées, étraînées, adoptées, on n'est plus très loin d'une démarche, qui consiste surtout à ce que chaque élément puisse être développé, puis assemblé, distinctement. Dans ce fil de discussion, nous avons déjà abordé l'intérêt de l'indépendance d'un module pour sa maintenance, également. C'est un point essentiel à mes yeux.

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 en respectant, à la ligne, la logique de l'entreprise, et de ses répartitions métiers. C'est tout comme le modulaire donc ;)

Je l'ai opposé délibérément à Ancres et Bouées, parce que ce schéma est radicalement tout l'inverse. Mais j'insiste et je te soutiens, il a sa place dans un tutoriel tant qu'on en fait pas un schéma général, systématique, unique...

Peut-être certains design-patterns seraient adaptés, pourquoi pas. Ce n'était pas trop mon propos, mais tout comme les process réutilisés, ils aident à minimiser, quand ils sont adaptés, l'analyse globale en amont, surtout. Je suis un partisan de l'analyse, avec mes posts à rallonges on s'en serait douté... - comment ça pas en matière synthétique ? ;) - donc loin de moi l'idée d'imposer un composant Client universel et réutilisable partout.

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

Bon, il y a toujours cette petite note de scepticisme quant à l'adaptabilité de la plateforme à cette démarche. Et cette séparation 'naturelle' entre données, logique et interface encore. Je ne conteste pas le fait que ce soit plus simple avec des outils parfaitement adaptés, mais ceux dont nous disposons à ce jour, le pemettent également. Avec une méthodologie qui sera adaptée, bien entendu aux spécificités de notre plateforme favorite. Après quelques années à me battre avec, je la connais un tantinet...même si je continue quotidiennement à perdre patience et à m'arracher les cheveux ( heureusement elles repoussent très bien mes boucles ).

Parfois, j'arrive à des choses avec même plus de souplesse que ce qu'on pourrait faire avec Servoy, c'est évident, puisqu'on en parle. C'est juste pas la même "programmation"...

C'est toujours et toujours et toujours une histoire de projet avant tout, de contexte ensuite. L'outil vient après. et tant qu'on me démontre pas que ce n'est pas faisable avec FileMaker - faisable vs 'possible avec 20,000 astuces bidons qui tiennent pas la route' - , je ne souhaite pas vraiment rentrer dans ce débat, ici stérile, et qui justement par moment, me semble condamner les développeurs à une voie unique. Parce qu'on peut pô faire comme les aut'

Buona note

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...