Jump to content
Ugo

Session Modularité

Recommended Posts

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

Ce graphe est issu d'une première approche modulaire, il y a bientôt un an. Il ne vaut que pour montrer le non ancrage à droite, oops, à gauche. En regardant à nouveau ce logiciel aujourd'hui, j'aurais pu éclater davantage le graphe, en plus petites unités.

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.

Comme je l'ai signalé, l'exploitation d'une ancre dans certains cas, s'avèrre parfaitement réalisable, quand les fonctions tournent principalement autour des données d'une table. L'exemple d'un module RèglagesUtilisateur me vient à l'esprit, où tout est centré sur la table des utilisateurs par exemple. Ce module pouvant être le point d'entrée de l'applicatif.

Maintenant, que reste-t-il d'Ancres et Bouées dans le schéma que tu décris, puique fondamentalement il repose sur cette structure d'Ancres distinctes.

Share this post


Link to post
Share on other sites

Eu égard à mon age et à mes activités plus que réduites, je suivrai ce fil très intéressant sans y prendre part. Il nécessite un un esprit vif et aussi un besoin d'expression qui ne convient pas à l'arthrose de mes phalanges. :(:D

Mais, je ne serai jamais très loin pour demander une explication.

Bonsoir à tous.

Share this post


Link to post
Share on other sites

Found this ...cool!?

modulaire.png

modulaire.png

post-2266-1238743804.png

post-2266-1238743804.png

post-2266-1238743804.png

post-2266-1238743804.png

post-2266-1238743804.png

post-2266-1238743804.png

post-2266-1238743804.png

post-2266-1238743804.png

Share this post


Link to post
Share on other sites

Oui Théo,

D'ailleurs, l'une des approche fondamentale de la Séparation des Aspects qui régit donc à mes yeux le modulaire énonce qu'il faut :

"Limiter les attributs limités à une tâche aux seuls attributs essentiels"

Ceci est vrai tant pour les processus que pour la définition des frontières logiques qui permettront d'établir le module.

J'en profite pour confirmer, à l'attention de Christian, qu'une table et ses éléments, sous la forme d'une occurrence, peut prendre place dans plusieurs modules.

Share this post


Link to post
Share on other sites

J'ai donc réfléchi un peu...

Pour appréhender au mieux le concept de la modularité, et pour profiter au mieux de ces exercices, je suggère les étapes suivantes, en reprenant finalement l'articulation de la session que j'ai animé. Je tenterai le plus possible de na pas influencer trop notre parcours, et de jouer un rôle de modérateur. Je vais de ce pas demander à Yvan de m'assister ;)

1. Décontextualisations :

Atteindre le modulaire nécessite de se plier à des règles. La première de toute est que le module fonctionnera avec ses propres logiques, sans faire appel à des fonctions, scripts, processus, d'autre modules. Il faut donc commencer par apprendre à décontextualiser un processus.

Cet effort dans la rédaction de nos codes, est tout à fait recommandé, que l'objectif soit la modularité ou non.

2. Constitution de Bibliothèques :

Quelques scripts que quelques uns appellent "routines" peuvent être incorporés dans nos développements. L'appel à une fenêtre, La sélection d'un élément dans une liste, la vérification des privilèges. Autant de scripts qui ne nécessitent donc que les paramètres que nous aurons abordé dans la première partie de ce voyage vers l'inconnu.

Ces scripts, comme des fonctions personnalisées pourront être appelés. Le but ici ne sera pas de piocher dans les bibliothèques des uns et des autres mais peut-être davantage de discuter du bien fondé des fonctions exécutées par ces bibliothèques, et de définir quand il peut s'agir d'un processus suffisamment générique pour y avoir recours.

3. Réutilisation des processus :

Une fois les premières décontextualisation acquises, et vos bibliothèques constituées, et prêtes à être réutilisées, un certains nombre d'autres processus, quand bien même ils sont difficilement décontextualisables, vous sembleront redondants dans vos applicatifs. Au travers de cet exercice n°3, et de nos échanges, on pourra juger d'une part des conditions dans lesquelles ces processus peuvent être réutilisés, et, en appliquant les règles de la Séparation des Aspects, comment un processus peut être décomposé en plus petites unités plus facilement manipulables.

A ce stade, il ne s'agira donc que de quelques avancées vers une programmation plus "propre" et réutilisable partiellement. Nous n'en serons pas encore arrivés à parler de modularité.

Je voudrais bien qu'avant de passer au point 4, nous réfléchissions et pratiquions un peu de Programmation Pilotée par les Tests. Ainsi, chacun pourra décider de poursuivre vers le modulaire "à la filemaker" ou de continuer à lire uniquement, s'il considère que l'approche d'Yvan est suffisante. Si tel est le cas, et si vraiment tout le monde y compris moi a bénéficié des discussions, exercices, techniques présentées dans les points 1 à 3, permettez moi de dire que je jugerai l'objectif atteint.

Pour ceux qui auront pris foi ou resteront excités par l'approche par module, le programme se poursuivra ainsi

4. Décomposition logique d'un logiciel

Sans doute cette section nécessitera plusieurs exercices, sur la base de plusieurs scénarios, je proposerai à chacun de réfléchir aux différents espaces logiques qu'on pourrait établir. Il s'agira non pas d'un exercice cette fois mais d'une discussion, qui certes nous ramènera à de la théorie, mais sur la base d'un scénario bien défini. Chacun pourra alors imaginer l'exploitation de l'application décrit, des besoins en terme d'ergonomie, partant du principe que nous analyserons cette décomposition du point de vue de l'utilisateur, en prenant délibérément comme postulat qu'il y en aura plusieurs centaines, chacun disposant de ces propres rôles, et donc exploitant des fonctions spécifiques du logiciel.

5. Périmètres logiques, frontières

Une fois qu'on aura fait notre choix sur l'organisation de ce tout petit applicatif, il s'agira d'étudier la façon donc chaque élément, présumé indépendant, fonctionnera aux côtés de l'autre. C'est à ce stade, à mon avis qu'Yvan de sa patte nous fouettera, et que nous lui apporterons, je n'en doute pas certaines réponses malgré tout.

Comment exploiter une interface utilisateur pour piloter les actions du module et comment faire en sorte que les actions accomplies par le module ne puisse être liées à quelques autres processus ou logiques présentes dans d'autres.

6. Gestion des erreurs :

Il me semble plus qu'utile d'aborder ce point, même si nous l'aurons sans doute abordé lors de la partie programmation pilotée par les tests. Comment gérer les erreurs en phase de développement, pratiquer le bon débogage, loguer les scripts défaillants. Cela rejoindra les avancées de Fabrice et ses gros efforts sur ce point, je pense que nous avons tous à prendre quelques exemples de ce que les uns et les autres fabriquent dans leur coin. Et vous, comment faites vous

7. Bilan

Là, si tout le monde est dans le coup encore, il sera temps de tirer un bilan de ce qui est faisable ou pas, du jusqu'où et avec quelles contraintes le modulaire peut être obtenu. Yvan nous aidera peut-être à regarder ailleurs ou alors à fixer les points au-delà desquels FileMaker et nos usages quotidiens deviendront contradictoires. Chacun pourra aussi bien entendu s'exprimer sur le degré d'avantages face aux inconvénients.

Partant de ce principe, le premier exercice consistera donc à masquer totalement toute référence quelconque aux rubriques, aux noms de modèles, à tout élément qui s'il est placé dans le processus, nécessiterait d'être formellement défini au préalable. En gros, à occulter totalement la dépendance du code vis à vis du design. L'objet est donc de pouvoir copier un script sans qu'une seule erreur ne se produise lors du copier coller. Il n'y a pas de mystère, ceci passe fondamentalement par des techniques de déclaration de variables, de structuration de paramètres de scripts, d'objets de modèles, ou de la fonction nouvelle Définir par Nom.

Cet exercice sera donc un bon moyen de faire une revue des effectifs :

1- Des moyens existants de stockage de paramètres ( dans des boutons, dans des enregistrements, dans des variables, etc. ) ,

2- Des méthodes existantes à ce jour pour leur passage au travers de scripts

structuration xml pour les uns ( Fabrice et moi-même, Rob Russel, etc ), structuration par propriétés pour les autres.

vos méthodes à vous ou celles que vous connaissez et qu'on ne connait pas

3- Des moyens parallèles de les récupérer.

4- Des techniques existantes de déclaration de variables à la volée

L'idée est donc de se constituer dès le départ d'une première bibliothèque de fonctions, que vous pourrez à votre guise réutiliser bien sûr. J'attendrais de ce premier fil qu'on discute des méthodes des uns et des autres, qu'on en analyse l'efficacité et la pertinence

A Lundi donc pour un premier exercice, révisez vos techniques pendant le week-end pour mieux nous les dévoiler. Et merci de jouer....

Share this post


Link to post
Share on other sites

Hé hé !!! beau programme, tu vois, depuis que tu es redevenu super U ;)

Share this post


Link to post
Share on other sites
1. Décontextualisations :

Atteindre le modulaire nécessite de se plier à des règles. La première de toute est que le module fonctionnera avec ses propres logiques, sans faire appel à des fonctions, scripts, processus, d'autre modules. Il faut donc commencer par apprendre à décontextualiser un processus.

Tu vas me trouver lourd (et encore, tu me connais mal, sinon ce serait pire), mais pourquoi partir directement sur la décontextualisation d'un *module* ? Je ne suis pas certain que tout le monde maitrise cette notion de décontextualisation.

Pourquoi ne pas avoir une étape 0, qui consisterait déjà à décontextualiser un script ou une FP ?

Cela permettrait d'avoir une première idée de l'objectif, et de mettre un exemple clair et simple sur une notion elle aussi assez simple, mais qui peut faire peur.

Décontextualisation, généricité, isolation, modèle ravioli... en clair, ca veut dire quoi ?

Je crains que la réaction de LPN-Michel (le coté "ca a l'air super, mais où est l'aspirine") soit un peu symptomatique, et il me semble dangereux de proposer des marches trop hautes.

Bien sûr, que la généricité d'un script soit directement liée au développement piloté par les tests n'est pas tout à fait un hasard ;)

Conceptuellement,

Yvan

Share this post


Link to post
Share on other sites

Bon,

La decontextualisation, dans l'exercice 1, c'est que du script si tu relis. T'es pas lourd, juste un peu bouché, mais on va quand même t'écouter jusqu'au bout :D

Share this post


Link to post
Share on other sites

Pour moi :

Isoler un script : on travaille sur un seul script (ou une seule fonction perso)

Isoler un module ou un processus : on travaille sur un *ensemble* de scripts et de FP. On est donc déjà à un niveau macro. Donc l'exercice me semble trop complexe.

J'aimerai d'ailleurs que tu définisses un peu la granularité du module :

Un client passe une commande (c'est à priori un processus) : est-ce que je vais utiliser plusieurs modules (module client pour le trouver, module article pour récupérer lesdits articles, etc...) ou bien est-ce que pour toi un module = un processus ?

Note que la question se pose aussi pour le processus : est-ce que tu considères que rechercher un client est un processus, ou bien est-ce trop "fin" ?

Il va vraiment falloir qu'on se mette d'accord sur le vocabulaire et le niveau de détail sur lequel on travaille.

Yvan

Share this post


Link to post
Share on other sites
(...)T'es pas lourd, juste un peu bouché, mais on va quand même t'écouter jusqu'au bout :D

Heu, peut-être, ça dépend dans quelle langue il parle... Ou alors on commence par le décontextualisation du langage, avec des mots nouveaux, indépendants du dictionnaire :D

(...)

Bien sûr, que la généricité d'un script (...)

Share this post


Link to post
Share on other sites
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 ?

La modularité est toujours un bienfait dans le monde informatique, à partir du moment où elle est correctement étudiée, réalisée... et réalisable.

A mon avis, il y a deux objectifs distincts :

- savoir si c'est techniquement possible

- si oui à partir de quel niveau de complexité est-ce rentable (et question accessoire : quel est le seuil où on devrait théoriquement changer de plate-forme ?) (j'ai dit "théoriquement").

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 ;)

Bon, là c'est moi qui m'excuse... je suis dans autre chose en ce moment, et j'ai tendance à oublier le contexte FMP... tu as raison de me rappeler à l'ordre.

Yvan

Share this post


Link to post
Share on other sites
Heu, peut-être, ça dépend dans quelle langue il parle... Ou alors on commence par le décontextualisation du langage, avec des mots nouveaux, indépendants du dictionnaire :D

Fchentranme, je en vsio asp où tes le bomèprel.

Ynav

Share this post


Link to post
Share on other sites

Salut Yvan,

Allez, un dernier post pleins de mots avant que le concret passe aux devants de la scène ;)

Bon, disons que concrètement, l'exercice que j'ai en tête et que je formaliserai consistera à la réalisation de 3 scripts, et que dans ce premier il sera question de passer des paramètres, de stocker des préférences quelque part, et d'utiliser des variables. 3 petits scripts du genre, ouverture d'une fenêtre avec une position donnée, définition d'une rubrique au sein d'une boucle qui parcourt un lot d'enregistrement sur un autre modèle que celui d'origine, et pour finir un script de vérification de privilèges.

On profitera de chaque exercice pour parfaire nos techniques, en regardant celles des autres, c'est à mon sens une démarche bien plus efficace que de fournir un exemple bâti par mes soins et de commenter dessus.

Ce sera notre premier palier de décompression, mais comme tout le monde pratique ce sport à sa façon, on verra où on en sera.

Comme je l'ai dit, je souhaiterai qu'il ne soit aucunement question de module dans les premiers exercices, mais plutôt de méthodes appliquant les concepts de base de la séparation des aspects, de l'encapsulation et du masquage d'informations. Une fois ces termes bien assimilés comme principe plus que comme vocable, on évoquera les modules, mais pas avant.

Pour ce qui est de la granularité du module, je ne suis pas dans du "fine-grain", c'est évident, compte-tenu de la plateforme. Nos raviolis seront beaucoup plus grand, bien moins bons que les vrais, et les interfaces de transferts d'information inexistantes. On oublie encore une fois la Programmation Objet et ses logiques qu'on n'atteindra jamais.

Donc à mon niveau, en attendant que peut être notre petit groupe élargisse ou affine la taille du module, je préfère raisonner en espace de travail. Je prends pour base le rôle de l'utilisateur, son 'métier' dans l'entreprise ou l'organisation, et j'examine les fonctionnalités dont il a besoin pour accomplir ses taches quotidiennes. Ceci constitue mon espace de travail. Attention, à ce stade, je pratique une très très grosse abstraction, en oubliant volontairement qu'un employé peut cumuler plusieurs casquettes. J'oublie que je suis face à une EURL et je raisonne au plus large, en considérant que toute petite entreprise qu'il soit, sa logique métier reste la même que son concurrent qui pourrait être plus ( mieux ? ) structuré. Si cette abstraction n'est pas accomplie, c'est tout le schéma qui prend l'eau puisqu'on aura réintroduit toutes les dépendances.

Donc un module est un espace rassemblant plusieurs fonctions et processus, pour atteindre l'un des objectifs de l'entreprise. L'espace Vente est donc distinct de l'espace Achat, ou de l'espace Finances, ou même de l'espace Production. Si j'embauche un commercial, je lui confierai la saisie des commandes sans lui donner accès ni aux marges dégagées au travers les achats, ni à la composition du produit. Il aura accès au listing des clients, aux tarifications et à la stratégie générale des prix, et à l'ensemble des processus pour effectuer ses commandes. Il aura accès aux niveaux des stocks.

Un utilisateur, c'est fort probable, aura accès à plusieurs espaces, mais je décompose le métier ainsi. Si mon vendeur, parce que c'est ainsi que mon métier est défini, doit passer la commande au fournisseur également, il aura accès aux deux espaces, mais il ne procédera pas aux achats depuis l'espace vente. L'espace Achat devrait lui permettre de disposer d'une liste de commandes Clients à traiter, bien entendu, et dans l'espace Vente, le commercial disposera d'une information sur l'état de la commande Client, si un processus d'achat devait être engagé. Ceci explique pourquoi je disais à Christian qu'un table peut se retrouver dans plusieurs modules. Mais les processus sont distincts.

Si je considère que mon espace Commande (saisie des commandes ) dépend d'un processus engagé dans l'espace Client ( Sélection ), je ne pourrai pas demain assembler un module sans l'autre. J'élimine ainsi la dépendance des modules en rassemblant les fonctions sur la base de la logique métier.

Mais sur ce point, je ne suis pas fermé du tout, bien au contraire. Si j'arrive à intégrer cette sélection du client comme un sous-module, alors j'aurais un espace de travail tout aussi bien défini, mais il faudra juste un peu de documentation.

J'arrive donc à du "fine-grain" dans la gestion des processus malgré tout, mais le module sera assez large.

Pour résumer donc :

- Un client passe une commande = processus

- Une recherche du client = processus

- Mon cadre de travail pour faire mes commandes = le module.

Bien entendu, un processus consiste à l'utilisation de scripts et autres processus. Donc processus est le regroupement de plusieurs méthodes/scripts, chacun n'effectuant qu'une action, éventuellement. On commence bien par les scripts ici

Share this post


Link to post
Share on other sites

Le système de métier que tu décris, Ugo, (et qui s'appelle "rôle" en UML) n'est ni plus ni moins que celui que devrait avoir tout logiciel raisonnablement structuré.

C'est donc un préalable nécessaire pour une analyse digne de ce nom.

Si on pousse un peu plus loin, on va déboucher sur les scénarios (ou scénarii pour les transalpins).

Je suggère d'ailleurs que les "exercices" s'appuient sur des scénarios décrivant le but à atteindre, mais je ne sais pas encore ce que tu as en tête.

Yvan

Share this post


Link to post
Share on other sites

Oui, Yvan en effet. La Session n'a pas excédé 3 heures parce que je n'ai pas traité les parties Merise, UML, ni l'étude complète du cadre de Zachman. :lol:

Cela dit, c'est dans les diapos ignorées du keynote pour ceux qui l'ont :blush: même si ce n'est pas un tutoriel, encore moins dans ce cas.

La première étape est donc postée ici

A+

Share this post


Link to post
Share on other sites

Réflexion sur la modularité

Après avoir suivi la conférence d’Ugo et lu et relu les posts du fil, j’ai refermé mon portable en me disant que ça volait trop haut pour moi. Et puis petite musique lancinante, la modularité, les briques logicielles qui s’assemblent comme des Lego. Le phantasme de pouvoir réutiliser telles quelles des parties d’applications développées par ailleurs.

C’est d’ailleurs le fil conducteur, voir même la grosse préoccupation d’Ugo.

Message 21

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.

Message 23

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.

Message 25

la réutilisabilité, d'un module dans son ensemble, d'un de ses composants, ou de l'un de ses processus.

Merise, UML, ni l'étude complète du cadre de Zachman sont des inconnus pour moi. Mais modularité, interopérabilité sont des préoccupations de tous les jours en tant qu’usager y compris hors de FileMaker.

Dans le domaine, je suis un béotien, je connais modérément FileMaker, mais cette logique m’interpelle et j’essaye de réfléchir à la problématique.

Qui dit modularité doit se poser les questions quoi, pourquoi et comment ?

Qu’est-ce qu’un module ? D’abord le terme module est assez vaste et peut englober beaucoup de choses différentes, je retiens une définition relevée sur Internet et me semble proche de nos préoccupation bien qu’extrêmement restrictive :

Un module en programmation désigne un espace de noms. Pour reprendre l'image de la programmation objet, un module est une instance unique qui n'utilise pas d'héritage et ne contient aucun module fils.

Pour être plus clair, un module est un ensemble fonctionnel indépendant qui a pour caractéristique la possibilité d’être rattaché à un autre ensemble pour le compléter. Concrètement, dans cette définition, un plug-in est un module. Plus imagé, une caravane est un module qui se rattache à une voiture. La voiture n’a pas besoin de la caravane pour fonctionner, mais la voiture plus la caravane créée une nouvelle fonctionnalité. Une roue de Clio ou de 4x4 ne peut être un module, ce n’est qu’un élément de la voiture car la voiture sans la roue ne peut fonctionner.

Pourquoi utiliser un module ? Pour en revenir à la comparaison avec la voiture, une voiture avec une caravane peut avoir le même usage qu’un camping-car mais un camping-car n’aura jamais l’usage d’une voiture seule. Le camping-car, ce sont nos solutions FileMaker où l’on retrouve tout ce que tous nos clients peuvent avoir besoin en une seule application. C’est lourd, et plus c’est lourd et complexe, plus c’est difficile à gérer et ce d’autant plus que chaque client n’a besoin que d’une partie de l’application. On garde des tables et des scripts au frigo pour au cas où ça serait utile... On se rapproche plus du camion d’assistance que de la voiture-caravane... Pas facile d’aller au supermarché du coin faire ses courses !

Comment utiliser un module ?

Qui dit module dit interface et standardisation. Interface au sens liaison entre deux modules et non pas interface utilisateur où nous l’entendons habituellement. Pour en revenir à l’image voiture caravane, il s’agit de l’attelage, la boule et le connecteur électrique. La boule, à cette boule une voiture peut rattacher de nombreux modèles de caravane et une caravane peut se rattacher à toutes les voitures pourvues d’une boule. pareil pour le connecteur électrique avec en plus obligation de correspondance des fonctionnalités : éclairage avec éclairage, feux de freins avec feux de freins et feux de stop avec feux de stop. La forme de la boule et du connecteur électrique ainsi que l’emplacement des fiches sont les mêmes pour tous les véhicules, c’est une interface standardisée.

Avant de se lancer dans la programmation, il convient donc de se pencher sur ce qui va être l’interface entre les différents modules et comment vont-ils communiquer entre eux.

Premier point, comment une application FileMaker saura-t-elle qu’un module lui est rattaché. Au jour d’aujourd’hui, lorsqu’un fichier manque, au lancement d’un script FileMaker lance une alerte, et le processus risque de s’enrayer. La solution devra être si tel module est en place, je fais telle action sinon j’en fais une autre sans que l’utilisateur quotidien n’ait à agir.

Deuxième point, la standardisation. C’est-à-dire que les informations doivent circuler entre deux modules selon des protocoles définis à l’avance et figés.

Exemples : dans le domaine de la gestion commerciale, on pourrait imaginer un ensemble de briques logicielles avec un module de base Client, Articles, Devis, Facturation. Le classique du classique. Et puis en fonction du développement de l’entreprise, rajouter un module Gestion des stocks et puis un module SAV et puis encore un module Logistique et j’en passe... Mais le tout sans jamais avoir à changer le module de base ou bien n’avoir à changer que le module de base seul. Et surtout, que tout continue à fonctionner !

Diviser une grosse application en plusieurs petits modules semble frappé du bon sens, on devrait y gagner une optimisation plus rapide de chaque module et une souplesse dans la variété des assemblages. Par contre, il ne faut pas que les interfaces de liaison entre les modules et les contraintes de standardisation des échanges des informations ne se payent d’un poids trop lourd. A la place d’un camion d’assistance multifonction, on risque de se retrouver avec des branchements plus gros et plus complexes que les applications elles-mêmes !

Dans l’état actuel de FileMaker et malgré l’intensité des cogitations d’Ugo, je crains que je continuerai encore longtemps à développer des usines à gaz...

Bonne continuation aux joyeux contributeurs

A+

Share this post


Link to post
Share on other sites

La réutilisabilité est l'étape ultime de la modularité. L'exemple typique est effectivement le plug-in (enfin, quand il est bien fait).

Dans un premier temps, sans aller jusqu'à la réutilisabilité, on peut s'acheminer vers un minimum d'indépendance entre les modules.

Ton module client, par exemple, ne pourra fonctionner que dans ton appli, mais il pourra être détaché du reste sans bobo, et surtout surtout pouvoir évoluer sans tout casser à coté.

Tant qu'on est sur la gestion de DVD, cela n'a pas trop d'importance, mais dès qu'on aborde des projets un peu plus costaux, ce point devient crucial.

Ton image de la caravane est excellente, je sens que je vais la reprendre dans mes formations.

Yvan

Share this post


Link to post
Share on other sites

Bonsoir Philippe et merci pour ta contribution,

Comme l'explicite Yvan à demi-mots, je suis plus préoccupé par la maintenance et les possibilités d'évolution d'un système bien "compartimenté" , modularisé, ou disons alors bien divisé, que par la réutilisabilité elle-même. Ce que tu cites est sorti du contexte, mais c'est normal avec ce flot de mots, et encore plus normal de ne pas occulter l'ultime dessein du modulaire, même s'il reste utopique.

Très intéressante analyse cependant.

Share this post


Link to post
Share on other sites

Bonjour,

j'essaie de suivre ce fil intéressant depuis le début.

Vous faites, les uns et les autres, allusion à des "bibliothèques de fonctions" mais je vois pas bien dans la pratique comment cous les utilisez. Est-ce qu'une bib est simplement un fichier fmp sans données dans lequel vous créez vos fonctions et scripts génériques et ensuite vous faites des copier-coller des fonctions et des imports des scrips à partir du fichier X courant. Cela peut etre pratique mais impose pas mal de manips et oblige lors d'une éventuelle évolution du script ou des fonctions à faire les modifs toujours dans la bibliothèque et re-importer/coller dans le fichier courant. Ou bien il y a t il un moyen de faire un vrai "include" de cette bibliothèque dans le fichier X. J'ai essayé de rajouter un fichier bibliothèque dans le graphe de liens d'un fichier X. A ce moment-là effectivement on peut executer le script externe à partir de X (ce script externe pouvant d'ailleurs faire appels aux fonctions perso de la bib) mais jamais on peut exécuter une fonction perso directement depuis le fichier X ce qui est un peu génant quand même

Comment vous gérez la chose ou bien est-ce que j'ai rien compris et c'est pas du tout de ca dont vous causez ?

Share this post


Link to post
Share on other sites

désolé j'arive pas a supprimer les fichiers...

YouGoModular_stepH.zip

YouGoModular_stepH.zip

YouGoModular_stepH.zip

YouGoModular_stepH.zip

YouGoModular_stepH.zip

YouGoModular_stepH.zip

YouGoModular_stepH.zip

YouGoModular_stepH.zip

YouGoModular_stepH.zip

YouGoModular_stepH.zip

YouGoModular_stepH.zip

YouGoModular_stepH.zip

YouGoModular_stepH.zip

YouGoModular_stepH.zip

YouGoModular_stepH.zip

YouGoModular_stepH.zip

YouGoModular_stepH.zip

YouGoModular_stepH.zip

YouGoModular_stepH.zip

YouGoModular_stepH.zip

Share this post


Link to post
Share on other sites

Salut,

Je ne sais pas si Olivier peut déplacer une réponse d'un post vers l'autre, mais manifestement, Henri, tu t'es trompé de fil ;)

Désolé, ici c'est la théorie, là bas la pratique apparemment :blush:

Share this post


Link to post
Share on other sites

Bonjour Nicolas,

C'est effectivement une question très importante.

Par bibliothèque, j'entends pour ce qui me concerne des scripts couvrant plusieurs fonctions. Quand bien-même on peut effectivement constituer une 'bibliothèque' de fonctions personnalisées, il ne s'agit pas véritablement de la même chose. Une fonctions personnalisée à mes yeux ne fait que rajouter une fonction à l'ensemble des fonctions natives.

Ce que tu tentes de faire, c'est d'isoler la 'logique'. Cela est matériellement possible mais extrêmement compliqué. on peut le faire au sein du même fichier ou dans un fichier séparé, il suffit d'isoler les évaluations dans des groupes d'occurrences de Tables. Pour un développement dans lequel j'ai opté pour cette option, l'interface était effectivement très fluide. Mais c'est une gymnastique très complexe, et cela conduit finalement à reproduire plusieurs structures relationnelles, l'une pour l'affichage des données, l'autre pour l'évaluation.

Quoiqu'il en soit, mettre à jour sa bibliothèque est une opération pénible. Chaque script comporte un identifiant et l'appel à un script d'un bouton est strictement lié à cet identifiant. Importer les scripts ou les copier, puis supprimer leurs homonymes est impossible. il faudra donc copier le contenu de chaque script.

Ou alors, comme je l'ai vu faire, utiliser un script unique qui se chargera de rediriger vers le script fourni en paramètre. Auquel cas, on a effectivement laissé la porte ouverte à la constitution de bibliothèques faciles à réutiliser. Il faut malgré tout un plug-in pour cela, et une très fine gestion des paramètres. C'est d'ailleurs ce qui l'a conduit comme moi à l'externalisation des paramètres dans une table séparée.

Share this post


Link to post
Share on other sites

Bonsoir,

Juste un petit complément à ma réponse à Philippe. En prenant la caravane comme exemple de module, on ne prend que l'aspect extension des fonctionnalités. C'est probablement la plus facile des modularisations, et comme tu le dis, les plug-ins sont par essence l'exemple même.

La division en espaces logiques, pour ne plus utiliser le mot module avant que nous ayions trouvé un véritable sens dans FileMaker, et pour ne plus porter à confusion, est un peu plus complexe il est vrai, et ne nécessite pas les mêmes méthodologies. On parle plus d'assemblage ici alors.

Share this post


Link to post
Share on other sites

ma petite contribution.

Est-ce que je me trompe ou le fait de rediriger vers un modèle est un comportement particulier du module, et donc ne doit pas être envisagé de manière "générique" ?

Pour cela, j'ai inclus l'exécution d'un script générique ("bibliothèque") ("New Window") dans un script propre au module, qui lui n'a pas pour vocation d'être réutilisé ailleurs.

YouGoModular_step1_Fabrice.fp7.zip

YouGoModular_step1_Fabrice.fp7.zip

YouGoModular_step1_Fabrice.fp7.zip

YouGoModular_step1_Fabrice.fp7.zip

YouGoModular_step1_Fabrice.fp7.zip

YouGoModular_step1_Fabrice.fp7.zip

YouGoModular_step1_Fabrice.fp7.zip

YouGoModular_step1_Fabrice.fp7.zip

YouGoModular_step1_Fabrice.fp7.zip

YouGoModular_step1_Fabrice.fp7.zip

Share this post


Link to post
Share on other sites

Salut,

Bon, toi aussi tu t'es trompé d'endroit...

Tu as parfaitement raison. Ouvrir la fenêtre et la fermer ne comporte aucun intérêt d'une part, mais surtout si on s'en tient aux principes de la Séparation des Aspects, un script ne doit accomplir qu'une seule action. L'unique partie du processus réutilisable ici est donc l'ouverture d'une fenêtre et l'inclure comme tu le fais dans un sous-script, c'est tout à fait ainsi que je l'envisageais.

C'était donc un peu le piège de ce premier exercice. La gestion du résultat au travers du script d'une seule ligne, c'est aussi ce que je pratique au quotidien et ce que je voulais mettre en pratique ici.

Convient-il d'appliquer la Séparation des Aspects à outrance pour autant ? Si au sein du même 'espace', à différents endroits, je dois faire appel à un script du même genre, avec une ou deux conditions clairement définies, permettant d'en faire varier le comportement, la définition du paramètre au sein du script tel que tu le fais plutôt que dans le bouton, nous obligera à créer n scripts plutôt que de placer les quelques conditions nécessaires dans le script. Puisque dans ce cas, il est clairement établi que ce script ne sera pas générique, la Séparation des Aspects doit-elle être notre première préoccupation ?

Bref, c'est donc parfait, tout ce que vous produisez donne de l'eau à notre moulin. L'ensemble des techniques exposées jusqu'alors permettent de mettre en lumière tant la diversité des techniques que les conditions même de réutilisation des scripts.

Demain, dans le train, je m'y pencherai à mon tour, je vous promets.

Puis, je vous proposerai une synthèse, un dernier petit dialogue, débat, discussion, avant de modifier le fichier d'origine avec les éléments que NOUS aurons retenus comme les plus pertinents. Histoire de le réutiliser pour les prochaines aventures et les autres scénarios.

Merci encore.

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