IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Débats sur le développement - Le Best Of Discussion :

programmation modulaire


Sujet :

Débats sur le développement - Le Best Of

  1. #41
    Membre expert Avatar de jabbounet
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Juin 2009
    Messages
    1 909
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48

    Informations professionnelles :
    Activité : Consultant informatique

    Informations forums :
    Inscription : Juin 2009
    Messages : 1 909
    Points : 3 284
    Points
    3 284
    Par défaut
    Citation Envoyé par davcha Voir le message
    Ca, oui, on est tout à fait d'accord.
    Toujours est-il que mes plug-ins partagent, partiellement, les mêmes données.
    parceque ton application a été concu comme ça.

    maintenant prenons un exemple simple d'environnement modulaire dans couplage entre les données ....


    on va prendre quelque chose qui parle a tout le monde.

    un environnement dev.

    dedans tu as un editeur, un compilo, un debbugger, ...


    peux tu utiliser chacun des elements indépendament oui.
    tu peux debugger un exe sans avoir de compilateur ou d'éditeur
    tu peux compiler sans editer et debugger
    tu peux editer des fichiers sans compilateur ni debugger.

    maintenant si tu combine les trois dans un editeur moderne tu as un interface pour compiler et debugger. tout ces elements ont été conçus et developpé indépendament les uns des autres et ont une synergie forte, la seul chose a faire et des les parametrer correctement.

    On peux donc avoir des couplage tres faibles (chacun des elements pouvant fonctionner séparement et n'avoir aucune consciences des autres, sauf paramétrage) et des resultats fonctionellement tres fort.

    Ensuite l'inverse existe aussi, tu as un paquet d'appli aussi ou le couplage est fort (parfois trop) entre les modules et l'un ne va pas sans l'autre. mais la on ne peux plus vraiment dire que c'est modulaire (car si tu es obligé de prendre un truc pour en utiliser un autre il sont effectivement interdépendant).

    exemple ton executable java a forcement besoin d'une jvm, mais bon c'est la techno qui a été concu comme ça.


    voila je crois que j'ai pris
    bazar: http://www.improetcompagnie.com/publ...ctacles-6.html

    BÉPO la disposition de clavier francophone, ergonomique et libre: http://bepo.fr/wiki/Accueil

    Emacs Wiki: http://www.emacswiki.org/

    En attente de ce que produira: http://www.pushmid.com

  2. #42
    Membre à l'essai
    Inscrit en
    Juillet 2009
    Messages
    21
    Détails du profil
    Informations forums :
    Inscription : Juillet 2009
    Messages : 21
    Points : 22
    Points
    22
    Par défaut
    Citation Envoyé par Mac LAK Voir le message
    Parce que tel que tu le dis, c'est lu comme "c'est fait en dur dans le code source"... Ce qui est tentaculaire et crade.
    Si c'est dynamique et à l'exécution, comme des briques de Lego empilées les unes sur les autres, c'est "propre". Parce que tu n'as pas besoin d'avoir de dépendances au niveau du code source (#include, using, etc...) pour pouvoir faire ceci, la seule "contrainte" étant de référencer l'interface commune, qui devient la seule et unique dépendance statique des modules.
    Donc si j'ai bien compris, pour toi la différence entre un projet modulaire propre et un projet tentaculaire crade, c'est de mettre les include/using en préprocesseur ou dans ton environnement d'exécution au lieu de les mettre dans le code. On est d'accord, il s'agit bien de remplacer 3 lignes de code par 3 autres lignes de code ? Du coup, j'ai beau chercher, je ne vois que 2 différences concrètes non négligeables :

    - Avec ta méthode, tu peux compiler un module tout seul sans avoir besoin des autres. Quel intérêt ? Aucun, puisque de toute façon les modules de couche inférieure dont tu dépends auront été créés dès le tout début du projet, du moins les interfaces et squelettes, et dès leur toute première compilation tu pourras alors les référencer dans ton module sans avoir à t'en soucier. Entre une boite noire inconnue et découverte seulement à l'exécution, ou une boite vide, je ne vois pas la différence.

    - Par contre là où il y a une différence concrète entre ta boite noire et ma boite vide, c'est que quand la boite vide se remplit peu à peu (i.e. quand on commence à implémenter le code du module dont tu dépends) je peux alors profiter de tous les outils de vérification de mon éditeur et de mon compilateur qui vont regarder ce module utilisé et vérifier qu'il est utilisé correctement. Ta boite noire par contre elle reste noire jusqu'à l'exécution...

  3. #43
    Membre expert Avatar de jabbounet
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Juin 2009
    Messages
    1 909
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48

    Informations professionnelles :
    Activité : Consultant informatique

    Informations forums :
    Inscription : Juin 2009
    Messages : 1 909
    Points : 3 284
    Points
    3 284
    Par défaut
    - Avec ta méthode, tu peux compiler un module tout seul sans avoir besoin des autres. Quel intérêt ? Aucun, puisque de toute façon les modules de couche inférieure dont tu dépends auront été créés dès le tout début du projet, du moins les interfaces et squelettes, et dès leur toute première compilation tu pourras alors les référencer dans ton module sans avoir à t'en soucier. Entre une boite noire inconnue et découverte seulement à l'exécution, ou une boite vide, je ne vois pas la différence.
    L'intérêt et que tu peux le tester et le valider seul sans avoir besoin des autres (qui ne sont pas toujours prêt au moment ou tu fait ton module).
    cela apporte du parallélisme a ton projet et donc du gain potentiel de temps.


    - Par contre là où il y a une différence concrète entre ta boite noire et ma boite vide, c'est que quand la boite vide se remplit peu à peu (i.e. quand on commence à implémenter le code du module dont tu dépends) je peux alors profiter de tous les outils de vérification de mon éditeur et de mon compilateur qui vont regarder ce module utilisé et vérifier qu'il est utilisé correctement. Ta boite noire par contre elle reste noire jusqu'à l'exécution...
    c'est le principe de la boite noire, et elle reste noire aussi pendant l'exécution, ton application ne sais pas réellement de quoi il s'agit, (banc de test, appli réelle, proto pour poc, ...)
    bazar: http://www.improetcompagnie.com/publ...ctacles-6.html

    BÉPO la disposition de clavier francophone, ergonomique et libre: http://bepo.fr/wiki/Accueil

    Emacs Wiki: http://www.emacswiki.org/

    En attente de ce que produira: http://www.pushmid.com

  4. #44
    Inactif  
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    Octobre 2004
    Messages
    3 893
    Détails du profil
    Informations personnelles :
    Âge : 49
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : Octobre 2004
    Messages : 3 893
    Points : 4 846
    Points
    4 846
    Par défaut
    Citation Envoyé par ZoinX Voir le message
    Donc si j'ai bien compris, pour toi la différence entre un projet modulaire propre et un projet tentaculaire crade, c'est de mettre les include/using en préprocesseur ou dans ton environnement d'exécution au lieu de les mettre dans le code. On est d'accord, il s'agit bien de remplacer 3 lignes de code par 3 autres lignes de code ? Du coup, j'ai beau chercher, je ne vois que 2 différences concrètes non négligeables :
    Non, c'est que dans un projet tentaculaire, tu définis QUI reçoit ou envoie les données.
    Dans un projet propre, tu définis LES DONNÉES VÉHICULÉES ELLES-MÊME... C'est plus que "quelques lignes de code" qui changent, c'est une philosophie complète.

    Citation Envoyé par ZoinX Voir le message
    - Avec ta méthode, tu peux compiler un module tout seul sans avoir besoin des autres. Quel intérêt ?
    Le test unitaire, le changement facile de couche basse (ou haute), le portage, la réutilisabilité... Aucun intérêt, en effet...

    Citation Envoyé par ZoinX Voir le message
    puisque de toute façon les modules de couche inférieure dont tu dépends auront été créés dès le tout début du projet, du moins les interfaces et squelettes, et dès leur toute première compilation tu pourras alors les référencer dans ton module sans avoir à t'en soucier.
    Faux, justement : on définit certes les interfaces, mais les interfaces des données. Au moment où le projet est lancé, les hardeux commencent l'étude des cartes, elles n'existent même pas encore !!! Il est donc nécessaire d'écrire un stub, afin de valider les couches les plus hautes en parallèle... Une fois le matériel prêt, les tests unitaires et de non-régression des couches hautes permettent de valider le bas niveau, qui doit réagir "comme prévu". Si le comportement est différent, l'erreur est dans le code réel qui a remplacé le stub.
    Or, déterminer à quel endroit se situe un bug est souvent l'opération la plus longue, la correction elle-même prenant rarement plus d'une heure ou deux. Cette méthode permet justement d'isoler les parties de code entre elles afin de pouvoir déterminer, de façon quasi-dichotomique, à quel endroit du code est l'erreur.

    Citation Envoyé par ZoinX Voir le message
    Entre une boite noire inconnue et découverte seulement à l'exécution, ou une boite vide, je ne vois pas la différence.
    "Voilà pourquoi tu échoues..." (Yoda).

    Citation Envoyé par ZoinX Voir le message
    Par contre là où il y a une différence concrète entre ta boite noire et ma boite vide, c'est que quand la boite vide se remplit peu à peu (i.e. quand on commence à implémenter le code du module dont tu dépends) je peux alors profiter de tous les outils de vérification de mon éditeur et de mon compilateur qui vont regarder ce module utilisé et vérifier qu'il est utilisé correctement. Ta boite noire par contre elle reste noire jusqu'à l'exécution...
    Et tu dois donc débugger au pas à pas, en "cherchant" l'erreur comme un chien de chasse ? Pas très rationnel, tout ça...
    Ma boîte noire reste noire parce qu'elle n'a pas à être "connue" par l'utilisateur d'à côté, il en attends des données, pas autre chose. Le "sens de communication" est unidirectionnel, on ne rétroagit pas sur les couches précédentes.
    Si cela doit être fait, on ajoute alors une dérivation dans le flux de données pour le réinjecter, c'est ce que j'appelle des "arc-réflexe".

    On pourrait schématiser ça en disant qu'un récepteur ne doit jamais transmettre lui-même à son émetteur, et réciproquement. Chacun son rôle, chacun sa fonction, seules les données transmises comptent. Pas "qui" les transmet, juste "comment" il les transmet, et "sous quelle forme"...


    EDIT : Grillé par Jabbounet, tiens...
    Mac LAK.
    ___________________________________________________
    Ne prenez pas la vie trop au sérieux, de toutes façons, vous n'en sortirez pas vivant.

    Sources et composants Delphi sur mon site, L'antre du Lak.
    Pas de question technique par MP : posez-la dans un nouveau sujet, sur le forum adéquat.

    Rejoignez-nous sur : Serveur de fichiers [NAS] Le Tableau de bord projets Le groupe de travail ICMO

  5. #45
    Membre chevronné Avatar de chaplin
    Profil pro
    Inscrit en
    Août 2006
    Messages
    1 215
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2006
    Messages : 1 215
    Points : 1 819
    Points
    1 819
    Par défaut
    Citation Envoyé par Mac LAK Voir le message
    On pourrait schématiser ça en disant qu'un récepteur ne doit jamais transmettre lui-même à son émetteur, et réciproquement. Chacun son rôle, chacun sa fonction, seules les données transmises comptent. Pas "qui" les transmet, juste "comment" il les transmet, et "sous quelle forme"...
    Est ce que cela signifie que les données transitent un peu comme des messages ?

  6. #46
    Inactif  
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    Octobre 2004
    Messages
    3 893
    Détails du profil
    Informations personnelles :
    Âge : 49
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : Octobre 2004
    Messages : 3 893
    Points : 4 846
    Points
    4 846
    Par défaut
    Citation Envoyé par chaplin Voir le message
    Est ce que cela signifie que les données transitent un peu comme des messages ?
    Un peu, oui, en effet, sauf que ce sont rarement de "vrais" messages au sens unitaire et atomique du terme.

    Ce sont plutôt des flux - les entrées/sorties - ou des transferts ponctuels - les commandes - provenant soit de l'utilisateur, soit d'un script, soit d'un système d'arc-réflexe plus ou moins configurable.

    Le but dans tout ça, c'est que si par exemple on demande une donnée analogique, elle doit arriver au final à l'utilisateur dans une donnée compréhensible : par exemple, un angle d'inclinaison d'un volet (en degrés, en pourcentage ?), une mesure de pression (en Pascals, en bars, en atmosphères, en millimètres de mercure ?), ou que sais-je encore... Pourtant, à l'origine, ça reste un "simple" chiffre de 16 ou 32 bits acquis depuis le matériel !! Le but d'une telle "chaîne", c'est de traiter la mesure, la convertir, la calibrer, etc. pour pouvoir la présenter dans le "bon" format à l'utilisateur... Qui décide ensuite de ce qu'elle doit devenir : la consigner ? La surveiller ? Prendre une action quand elle dépasse une certaine valeur ? Ne pas en tenir compte, c'est pour le labo d'à côté ?

    Bref, on se concentre sur ce que veut l'utilisateur final... Il se fiche d'acquérir une donnée analogique, il veut savoir "quelle est la mesure ?"... Comment on l'obtient ? Il s'en fout. Il nous dit à quelle fréquence minimale il la veut, sous quel format, et on le lui fait.
    Et si on ne conçoit pas ses modules en fonction des données, on réalise certes le cahier des charges... Mais ce ne sera jamais réutilisable pour un autre client, donc cela coûtera de l'argent de revendre le produit, car il devra être adapté, et des fonctions spécifiques sont toujours à faire quoi qu'il arrive.

    Si c'est bien modulaire, il suffira de le configurer ce qui existe déjà, et d'intégrer les nouveautés. Très différent d'une adaptation par cassage / refonte du code, donc !!!
    Mac LAK.
    ___________________________________________________
    Ne prenez pas la vie trop au sérieux, de toutes façons, vous n'en sortirez pas vivant.

    Sources et composants Delphi sur mon site, L'antre du Lak.
    Pas de question technique par MP : posez-la dans un nouveau sujet, sur le forum adéquat.

    Rejoignez-nous sur : Serveur de fichiers [NAS] Le Tableau de bord projets Le groupe de travail ICMO

  7. #47
    Membre chevronné Avatar de chaplin
    Profil pro
    Inscrit en
    Août 2006
    Messages
    1 215
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2006
    Messages : 1 215
    Points : 1 819
    Points
    1 819
    Par défaut
    En fait, il faudrait raisoner en terme de chaîne de traitement de l'information qui peut être convertie en fonction des maillons de la chaîne (ce qui justifie leur existence).

  8. #48
    Inactif  
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    Octobre 2004
    Messages
    3 893
    Détails du profil
    Informations personnelles :
    Âge : 49
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : Octobre 2004
    Messages : 3 893
    Points : 4 846
    Points
    4 846
    Par défaut
    Citation Envoyé par chaplin Voir le message
    En fait, il faudrait raisoner en terme de chaîne de traitement de l'information qui peut être convertie en fonction des maillons de la chaîne (ce qui justifie leur existence).
    Ce qui rejoint un topic parallèle, ou je rappelle que l'informatique, c'est la science du traitement de l'information...

    Mais sinon, oui, c'est très exactement ça. Une donnée, ou une information, ne sert à RIEN en soi. Ce qui est important, c'est ce que l'on en FAIT. Donc, le but est de raisonner en unités de traitement, et de construire ensuite une chaîne de traitement de l'information. L'aspect modulaire se situe dans le fait que les interfaces d'entrées et de sorties sont prévues pour "s'emboîter" les unes dans les autres, non pas au travers d'un pointeur vers un type de classe "suivant" ou "précédent", mais au travers d'une structure de transfert, qui possède alors une direction (IN ou OUT), éventuellement organisées en collections.

    L'unité de traitement ne sait pas ce qu'il advient de la donnée : il sait juste qu'elle arrive (présupposée dans un certain format), et qu'il la ressort dans un autre pour le suivant. Par exemple, un module de calibration va présupposer que la donnée n'est, justement, pas calibrée avant de la réexpédier corrigée. Si la donnée était déjà calibrée, cela devient alors une unité de changement d'échelle, et non plus de calibration !
    Mac LAK.
    ___________________________________________________
    Ne prenez pas la vie trop au sérieux, de toutes façons, vous n'en sortirez pas vivant.

    Sources et composants Delphi sur mon site, L'antre du Lak.
    Pas de question technique par MP : posez-la dans un nouveau sujet, sur le forum adéquat.

    Rejoignez-nous sur : Serveur de fichiers [NAS] Le Tableau de bord projets Le groupe de travail ICMO

  9. #49
    Membre chevronné Avatar de chaplin
    Profil pro
    Inscrit en
    Août 2006
    Messages
    1 215
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2006
    Messages : 1 215
    Points : 1 819
    Points
    1 819
    Par défaut
    Citation Envoyé par Mac LAK Voir le message
    L'aspect modulaire se situe dans le fait que les interfaces d'entrées et de sorties sont prévues pour "s'emboîter" les unes dans les autres, non pas au travers d'un pointeur vers un type de classe "suivant" ou "précédent", mais au travers d'une structure de transfert, qui possède alors une direction (IN ou OUT), éventuellement organisées en collections.

    L'unité de traitement ne sait pas ce qu'il advient de la donnée : il sait juste qu'elle arrive (présupposée dans un certain format), et qu'il la ressort dans un autre pour le suivant.
    C'est là ou la notion d'interface prend effet. Je garde une notion physique de l'interface, c'est à dire la séparation entre deux milieux, mais suppose un protocole de connexion compatible entre les deux.

    Je sens le troll venir, donc je prierais les intervenants d'être constructif sur le sujet.

    Dans ce cas, je considère deux interfaces:
    - une interface qui sépare deux milieux de même nature.
    - une interface dont les milieux sont de nature différente (adaptateur).

  10. #50
    Inactif  
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    Octobre 2004
    Messages
    3 893
    Détails du profil
    Informations personnelles :
    Âge : 49
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : Octobre 2004
    Messages : 3 893
    Points : 4 846
    Points
    4 846
    Par défaut
    Citation Envoyé par chaplin Voir le message
    C'est là ou la notion d'interface prend effet. Je garde une notion physique de l'interface, c'est à dire la séparation entre deux milieux, mais suppose un protocole de connexion compatible entre les deux.
    C'est très exactement ça.

    En mode "tentacule", on connecte directement les modules entre eux (pointeur de classe, héritage, appel direct de fonction, peu importe).
    En mode "modulaire", on utilise des protocoles de connexion : callbacks, FIFO, pipes/sockets, messagerie globale, etc.

    Citation Envoyé par chaplin Voir le message
    Dans ce cas, je considère deux interfaces:
    - une interface qui sépare deux milieux de même nature.
    - une interface dont les milieux sont de nature différente (adaptateur).
    Tout à fait.

    Le premier est une interface de traitement : une donnée transite sans changer de nature. Elles doivent avoir une efficacité maximale, la transition d'un module à l'autre doit être d'un coût négligeable. La charge au niveau applicatif résulte des traitements eux-mêmes, et non pas des transferts.

    Le second est une interface de transfert : la donnée change de nature, ou de "monde" (ex : du hard vers le soft, par exemple, ou change de machine). L'objectif est alors l'intégrité de la donnée (transfert de "mondes"), ou la fiabilité de la conversion (erreurs d'arrondi, troncatures, etc.).
    La notion de performance est ici très relative, tout dépend en fait du NIVEAU dans lequel on se situe : c'est en général critique entre le hard et le driver, alors que ça n'a souvent aucune importance pour un système de log...
    Mac LAK.
    ___________________________________________________
    Ne prenez pas la vie trop au sérieux, de toutes façons, vous n'en sortirez pas vivant.

    Sources et composants Delphi sur mon site, L'antre du Lak.
    Pas de question technique par MP : posez-la dans un nouveau sujet, sur le forum adéquat.

    Rejoignez-nous sur : Serveur de fichiers [NAS] Le Tableau de bord projets Le groupe de travail ICMO

  11. #51
    Membre habitué
    Profil pro
    Développeur Java
    Inscrit en
    Juin 2009
    Messages
    102
    Détails du profil
    Informations personnelles :
    Âge : 39
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : Juin 2009
    Messages : 102
    Points : 172
    Points
    172
    Par défaut
    Moi je voudrais poser une question... Bon, j'avoue, j'ai zapé une partie de ce sujet parce que je n'avais pas trop envie de relire un remake de "Mac lak contre le reste du monde"... Je ne dis pas que tu as tort... Bref.

    Moi, je fais de la programmation de haut niveau, c'est mon job. Mon trip à moi, c'est de réfléchir à architecturer mes projets, à les rendre génériques, en couches pour qu'ils soient réutilisables ou tout du moins adaptables.

    Donc, au moins le titre du sujet me plait : "programmation modulaire".

    Je suis plutot jeune dans le domaine, mais je voulais savoir si c'était pertinent de faire une analogie avec quelque chose à la mode dans la programmation objet : Service Oriented Architecture ou plus communément appelé SOA.

    Est ce qu'un service = un module ? Je comprends bien qu'un module peut-être concrètement une simple librairie qui va traiter une information.
    Mais n'est ce pas ça le propre d'un module ? Avoir une entrée et une sortie, faire son job et ne pas se soucier du reste du projet ?

    Juste que SOA, je trouve ça pompeux pour quelque chose qui n'est au final (pour ce que j'en ai compris) qu'une granularité dans un projet ? Ai-je raté une subtilité ?

    je suis peut-être hors sujet, mais si quelqu'un veut bien m'aiguiller

  12. #52
    Expert éminent sénior

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    10 603
    Détails du profil
    Informations personnelles :
    Âge : 66
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 603
    Points : 17 913
    Points
    17 913
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par Kanithael Voir le message
    Est ce qu'un service = un module ? Je comprends bien qu'un module peut-être concrètement une simple librairie qui va traiter une information.
    Mais n'est ce pas ça le propre d'un module ? Avoir une entrée et une sortie, faire son job et ne pas se soucier du reste du projet ?
    Oui et non..

    Disons que un service peut-être composé de plusieurs modules, mais un module ne devrait offrir que des services ciblés sur un type de choses particulier...

    (mais ça, c'est mon instinct qui me dit d'après les mots, pas ma "connaissance", puisque je n'ai pas eu de cours dessus...)

    Prenons en exemple une bibliothèque (un service) de transformation géographique.

    Vraisemblablement elle aura besoin d'un module de maths (rotation, sin, cos, tan, atan, etc etc).

    Vraisemblablement donc du point de vue de cette optique tu auras 1 service et 2 modules..

    Mais tu pourrais considérer que le module de maths est en service en lui-même...

    Ce qui sera le cas si tu fabriques d'autres bibliothèques (ou services) qui l'utilisent...


    Citation Envoyé par Kanithael Voir le message
    Juste que SOA, je trouve ça pompeux pour quelque chose qui n'est au final (pour ce que j'en ai compris) qu'une granularité dans un projet ? Ai-je raté une subtilité ?
    Je ne crois pas, non

    Comment faire du neuf avec du vieux ou comment plumer les gogos en cours et formations...
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  13. #53
    Membre chevronné

    Homme Profil pro
    Architecte logiciel
    Inscrit en
    Novembre 2006
    Messages
    1 252
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte logiciel
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Novembre 2006
    Messages : 1 252
    Points : 1 954
    Points
    1 954
    Par défaut
    Citation Envoyé par Kanithael Voir le message
    Est ce qu'un service = un module
    Ca pourrait, tout dépend de la granularité que tu attribues à un module.


    Citation Envoyé par Kanithael Voir le message
    Juste que SOA, je trouve ça pompeux pour quelque chose qui n'est au final (pour ce que j'en ai compris) qu'une granularité dans un projet ? Ai-je raté une subtilité ?
    Tu as raté le médiateur que lie le producteur au consommateur. En outre les services impliqués dans les SOA possèdent un certain nombre de propriétés comme l'interopérabilité, la localisation ou l'asynchronisme.

  14. #54
    Inactif  
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    Octobre 2004
    Messages
    3 893
    Détails du profil
    Informations personnelles :
    Âge : 49
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : Octobre 2004
    Messages : 3 893
    Points : 4 846
    Points
    4 846
    Par défaut
    Citation Envoyé par Kanithael Voir le message
    Moi je voudrais poser une question... Bon, j'avoue, j'ai zapé une partie de ce sujet parce que je n'avais pas trop envie de relire un remake de "Mac lak contre le reste du monde"... Je ne dis pas que tu as tort... Bref.
    Pour ça, faut aussi lire mes arguments...

    Citation Envoyé par Kanithael Voir le message
    Mon trip à moi, c'est de réfléchir à architecturer mes projets, à les rendre génériques, en couches pour qu'ils soient réutilisables ou tout du moins adaptables.
    C'est une erreur lourde si tu crois que ce n'est pas quelque chose de courant (pour ne pas dire "constant") en bas niveau... La problématique de la modularité n'est pas une affaire de "hauteur" de conception.

    Citation Envoyé par Kanithael Voir le message
    Est ce qu'un service = un module ? Je comprends bien qu'un module peut-être concrètement une simple librairie qui va traiter une information.
    Mais n'est ce pas ça le propre d'un module ? Avoir une entrée et une sortie, faire son job et ne pas se soucier du reste du projet ?
    En partie seulement...
    Dans le concept, oui, c'est effectivement le cas. Mais pour le reste, cela peut varier énormément...

    Par exemple, si tu te bases sur une technologie de type CORBA, tu as bien une architecture SOA. Par contre, tes modules n'en ont que le nom : les parties client/serveur sont étroitement emmêlées, et de façon générale tu vas te retrouver avec énormément de dépendances "tentacules" au sein de chaque service, notamment ceux nécessitant de transférer les données d'un objet à l'autre, car pour respecter la technologie, il te faut connaître l'objet destination !

    Du coup, tentacule, et non plus modularité stricte... Modifier un objet quelconque (le compléter, par exemple) provoque la recompilation de tout objet communiquant avec lui.

    Citation Envoyé par Kanithael Voir le message
    Juste que SOA, je trouve ça pompeux pour quelque chose qui n'est au final (pour ce que j'en ai compris) qu'une granularité dans un projet ? Ai-je raté une subtilité ?
    Une petite : c'est effectivement une base de granularité, mais ça, c'est l'aspect "logique" de la chose (les monolithes, c'est MAL ! ).
    Le but est surtout de découper ton projet en entités fonctionnelles orientées métier plus que par un découpage "logique"...

    Par exemple, dans une architecture SOA, un concept de "librairie mathématique" n'a pas lieu d'être, sauf pour un labo de scientifiques. Tu vas par exemple avoir un service "Comptabilité", qui va en faire un usage plus ou moins lourd, ainsi qu'un module "Service des achats".
    Or, ces deux services n'ont rien à voir entre eux, ce ne sont pas les mêmes personnes, les mêmes fonctions. Mais, côté logiciel, elles vont pourtant utiliser des modules communs, qui n'ont absolument rien à faire dans les interfaces publiques.

    C'est pour ça que c'est "tentaculaire", d'un point de vue CODAGE. D'un point de vue "utilisateur", c'est par contre parfaitement disjoint et modulaire.
    C'est donc l'autre bout de la lorgnette que tu regardes : le côté "module utilisateur" (=module métier), et non pas le côté "module informatique" (=librairie, code source, etc.).
    Mac LAK.
    ___________________________________________________
    Ne prenez pas la vie trop au sérieux, de toutes façons, vous n'en sortirez pas vivant.

    Sources et composants Delphi sur mon site, L'antre du Lak.
    Pas de question technique par MP : posez-la dans un nouveau sujet, sur le forum adéquat.

    Rejoignez-nous sur : Serveur de fichiers [NAS] Le Tableau de bord projets Le groupe de travail ICMO

Discussions similaires

  1. L'interet de la programmation modulaire.
    Par giggs dans le forum C
    Réponses: 3
    Dernier message: 01/11/2006, 13h35
  2. programmation modulaire en C
    Par lastrecrue dans le forum GTK+ avec C & C++
    Réponses: 11
    Dernier message: 28/06/2006, 22h03
  3. programmation modulair en C
    Par argon dans le forum C
    Réponses: 32
    Dernier message: 26/06/2006, 11h10
  4. programmation modulaire
    Par barbarello dans le forum C++
    Réponses: 2
    Dernier message: 19/02/2006, 14h04
  5. [Projet] Programmation modulaire d'un projet.
    Par loverdose dans le forum Langages de programmation
    Réponses: 1
    Dernier message: 18/11/2005, 22h59

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo