Discussion :

[jabbounet]

J'ai deux petites questions.

1 - qui a la plus grosse, alors ? Mac LAK ou ZoinX ?
2 - comment vous rendez deux modules totalement indépendants, quand l'un utilise les données générées par l'autre ?

facile en définissant une API assez strict entre tes modules et en ne passant que par elle.

après qui te fournis les données sur ton api tu t'en fout, cela peu être simulé afin de pouvoir tester tes modules indépendament dans le cadre d'une campagne de tests fonctionnels.

exemple tout bête:
les moteurs d'échecs et les interface graphique associé.
Cnuchess/xboard communique via un protocole spécifique, ensuite tu trouve plein d'api et de moteur d'échecs qui supportent ce protocole.
tu as aussi http://fr.wikipedia.org/wiki/Universal_Chess_Interface
http://www.tim-mann.org/xboard/engine-intf.html

[souviron34]

Je ne prétends pas avoir raison, mais pour moi ce n'est pas comme ça qu'on définit quels seront les différents modules d'un projet. Certes dans l'idéal c'est évidemment mieux qu'ils soient au maximum indépendants des autres, mais c'est pas dans cette optique là qu'on les définit.

Eh bien comme le dit Mac LAK vous avez tort, et ça en promet de belles dans le futur...

Le problème reste de trouver des gens assez compétents et expérimentés pour reprendre et maintenir de tels joyaux du code, parce qu'au train où vont les choses tout le monde fait du java ou du C# (j'aime pas spécialement ces langages mais faut accepter les faits) voire du php, donc les futurs génies du C vont se faire très rares...

Après peut-être que certains langages haut niveau permettent de simplifier ce genre de choses,sans impact notable sur les performances, le tout avec une syntaxe plus agréable, mais pourquoi changer ses habitudes ?

Voui, de l'autre côté nous avons vu passer à notre âge un certain nombre (pour ne pas dire un nombre certain) d'horreurs et de (graves) problèmes..

Alors la fougue et l'enthousiasme de la jeunesse c'est bien beau, mais la réalité dépasse souvent la fiction...





On en reparlera quand on te demandera de reprendre ce vieux projet en C# (langage traité de dinosaures par les étudiants actuels ) ou en Java (la version n'est plus maintenue depuis 15 ans ) dans 20 ans

2 - comment vous rendez deux modules totalement indépendants, quand l'un utilise les données générées par l'autre ?

Pour te répondre et répondre au premier post, la réponse est fonctionelle :

Des modules bien faits sont en général des modules fonctionnels, correspondant à une certaine (voir une partie d'une) fonctionalité.

Bien entendu, il y a des dépendances.

Mais un beau découpage modulaire implique une conception "en service" et en couches, et uniquement une dépendance descendante ou au pire de même niveau : chaque "service" a une API, qui servira aux modules extérieurs. Il peut lui-même faire appel à d'autres modules.

La souplesse tient dans le découpage strict en termes de fonctionalités.

Exemple (déjà donné ailleurs) :

Un navigateur Web.

1. Couche d'en bas (module) : implantation du protocole TCP/IP
2. Couche d'au dessus (module) : envoi de packets et récupérations/vérification via le protocole
3. Couche d'au dessus (module) : fourniture d'un service utilisateur (ouverture socket, envoi message, réception)
4. Couche d'au dessus (module) : interprétation spécialisée du message (décodage HTML)
5. Couche d'au dessus (module) : widget graphique permettant l'affichage du message ainsi interprété
6. Couche d'au dessus (modules) : IHM du navigateur (boutons, historiques, fonction d'impression, etc)

• Chaque couche se sert de la précédente, mais n'attaque jamais la couche d'en dessus
• Chaque couche ne sait pas comment elle sera utilisée par la couche du dessus (bibliothèque)
• Chaque couche peut être modifiée sans avoir à toucher à celles du dessus (exemple : on peut passer pour le graphique de la WIN API à du X11 sans rien changer en dessous).

Par exemple, un bon découpage en modules de l'IHM (couche du dessus) serait d'avoir un module par fenêtre (fenêtre d'impression, fenêtre générale, ...)
Il devrait y avoir également des modules (séparés) de gestion d'impression ou du transfert de fichier , indépendantes de l'outil d'IHM.

etc etc...

Bref, un bon découpage fonctionnel se transcrit immédiatement en bon découpage en modules.




PS: errata de frappe : lire "d'en dessus" et non "d"en dessous" (corrigé) dans le dernière liste...

[jabbounet]

Bref, un bon découpage fonctionnel se transcrit immédiatement en bon découpage en modules.

cqfd, ....
le tout est de savoir découper.

[jabbounet]

http://java.sun.com/javacard/

le mettre sur une carte a puce pourquoi pas, mais quel sera le minimum requit sur l'hôte chargé de l'exécution?

Il y'a par exemple des pilotes automatique de métro qui tourne avec 16 Mo de Ram et des processeur 68000.
Je ne sais pas quel serait le matériel requis pour faire la même chose en java.

Avec un techno comme ça, les développeurs java vont devoir apprendre a se serrer la ceinture et a restreindre l'utilisation des ressource, et ce n'est pas dans leur culture si j'ai bien compris.

[Mac LAK]

le mettre sur une carte a puce pouruqoi pas, mais quel sera le minimum requit sur l'hote chargé de l'execution?

sans compter que les dev java vont devoir apprendre a se serrer la ceinture et a restreindre l'utilisation des ressource, et ce n'est pas dans leur culture si j'ai bien compris.

C'est même "pire" que ça... Il y a aussi du Java embarqué dans la téléphonie mobile par exemple, mais ce n'est qu'un sous-ensemble du Java "normal".

Dans tous les cas, le but cherché par du Java embarqué n'est pas la performance, mais la portabilité d'applications devant être particulièrement mobiles, sans contraintes de matériel hôte... Bref, pas grand-chose à voir avec de l'embarqué "normal", c'est plus proche des ordinateurs miniatures (type PDA) que des applications industrielles, ou des équipements embarqués.

Pour ma part, je mets ça au même niveau que les jeux Java des téléphones mobiles : c'est rigolo, mais ça ne révolutionne pas grand-chose au final.

[souviron34]

cqfd, ....
le tout est de savoir découper.

voir mon errata (tu peux coriger dans ta citation)

[alex_pi]

Dans tous les cas, le but cherché par du Java embarqué n'est pas la performance, mais la portabilité d'applications devant être particulièrement mobiles, sans contraintes de matériel hôte... Bref, pas grand-chose à voir avec de l'embarqué "normal", c'est plus proche des ordinateurs miniatures (type PDA) que des applications industrielles, ou des équipements embarqués.

Ce n'est absolument pas le but de javacard, qui a pour vocation de faire de l'embarqué sécurisé. (typiquement carte sim, de carte de crédit, etc.). On est loin du tétris sur le dernier portable tactile.

[Mac LAK]

1 - qui a la plus grosse, alors ? Mac LAK ou ZoinX ?

Expérience professionnelle ? Moi. Dix ans.
Mais bon, ayant été pareil à mes débuts que ZoinX, je sais aussi qu'il finira par comprendre (plus ou moins "durement") que l'idéalisme de la jeunesse ne dure qu'un temps... Et qu'il y a parfois un monde entre la plaquette commerciale filée au client et la réalité du code !

2 - comment vous rendez deux modules totalement indépendants, quand l'un utilise les données générées par l'autre ?

Application stricte des interfaces : à partir du "noyau" du programme principal, on définit une interface vers le "bas", une interface vers le "haut". Ces interfaces sont bien sûr sous forme de collection, il n'y a pas qu'une seule entrée ni une seule sortie.

Ensuite, chaque couche basse vient s'enficher dans la plus basse couche déjà enfichée (le noyau applicatif pour la première, donc). La seule chose qu'une couche basse peut savoir, c'est qu'elle est connectée à "quelque chose" au dessus. Ce que c'est ? Aucune idée, et elle ne doit surtout pas le savoir ! La dernière couche basse se connecte directement au matériel (ou à l'OS).

Côté haut niveau, c'est presque pareil, mais dans l'autre sens : chaque couche sait qu'elle a "quelque chose" en DESSOUS, mais ne sait pas "quoi". On l'initialise avec les données adéquates, et elle transfère les données (en les traitant) vers la couche du dessus.

C'est le noyau applicatif qui va décider du "routage" des données, avec ou sans duplication, depuis les couches basses (ex : une carte d'E/S analogique, un capteur quelconque, etc.) vers les couches hautes (ex : un stockage de données, une IHM, un superviseur général, etc.).

Si tu fais ça encore un peu plus évolué, tu peux également prévoir un retour des données, pas forcément par le même "chemin" que l'arrivée. Ceci permet par exemple d'implémenter proprement des "arcs-réflexe" au niveau du projet, où une décision d'action est prise au plus bas niveau possible (et donc au plus rapide possible aussi), avec ou sans propagation vers le haut niveau.
Dans tous les cas, c'est le noyau applicatif qui décide du "câblage" logiciel du projet, à l'initialisation, en fonction de la configuration demandée (qui peut être statique et/ou dynamique, bien entendu).

Au final, tu mets bien sûr en temps réel tout ce qui est noyau applicatif et les couches plus basses, les couches hautes étant elles en temps "normal".

Ce n'est absolument pas le but de javacard, qui a pour vocation de faire de l'embarqué sécurisé. (typiquement carte sim, de carte de crédit, etc.). On est loin du tétris sur le dernier portable tactile.

Sécurisé ?? Un truc décompilable comme pas permis, avec des VM pouvant être hookées de partout ?
Tu m'excuseras si j'ai un peu plus confiance dans les ID fondues sur silicium et protégées par RSA ou système équivalent, hein...

[alex_pi]

Sécurisé ?? Un truc décompilable comme pas permis, avec des VM pouvant être hookées de partout ?
Tu m'excuseras si j'ai un peu plus confiance dans les ID fondues sur silicium et protégées par RSA ou système équivalent, hein...

Il semble que l'usage du gras ne soit pas suffisant.

je parle de javaCARD

[ZoinX]

Des modules bien faits sont en général des modules fonctionnels, correspondant à une certaine (voir une partie d'une) fonctionalité.

Bien entendu, il y a des dépendances.

Bref, un bon découpage fonctionnel se transcrit immédiatement en bon découpage en modules.

Mais c'est exactement ce que je me tue à dire depuis le début !!!!!!!!!!! Le découpage en modules correspond au découpages des fonctionnalités de la spec, ce qui suffit généralement à limiter les dépendances, mais ce n'est pas l'objectif premier et il y a forcément quand même des dépendances. EXACTEMENT ce que je dis depuis le début...

Mais un beau découpage modulaire implique une conception "en service" et en couches, et uniquement une dépendance descendante ou au pire de même niveau : chaque "service" a une API, qui servira aux modules extérieurs. Il peut lui-même faire appel à d'autres modules.

Encore une fois exactement ce que j'ai dit. On travaille en couches, avec des interfaces et des API, ce qui rend les dépendances peu nombreuses, tout à fait gérables et propres ! Mais on n'élimine pas toute dépendance !

Application stricte des interfaces : à partir du "noyau" du programme principal, on définit une interface vers le "bas", une interface vers le "haut".

Et une interface, c'est quoi sinon une interconnexion entre deux modules, donc une dépendance ???

Ca me tue ça... en fait depuis le début on pense exactement la même chose et on essaye de dire la même chose mais on s'est pas du tout compris. Toi tu parles de modules "absolument complètement totalement indépendants sans le moindre lien entre eux" comme si ce devait être des projets différents n'ayant strictement rien à voir entre eux sans la moindre possibilité d'un quelconque lien. Et moi je parle d'avoir des interfaces et API claires entre modules et une organisation par couches (soit exactement ce que toi et souviron avez dit dans vos derniers posts) mais vous avez compris ça comme "on fait des modules tentaculaires qui dépendent tous les uns des autres de manière complètement crade"...

[Mac LAK]

Il semble que l'usage du gras ne soit pas suffisant.

je parle de javaCARD

Oui, j'ai lu. Et ton monolithe Java, tu le stockes comment, sinon dans une ROM ? Oh, le beau microcode à décompiler !!!
Sûr que comparé à l'utilisation de microscope à balayage et de cohortes d'analyseurs logiques nécessaires pour "décompiler" un circuit "fondu", c'est vachement plus sécurisé...

Et une interface, c'est quoi sinon une interconnexion entre deux modules, donc une dépendance ???

Une dépendance, c'est si dans ton module "A", tu références explicitement un entête (une classe, une constante, on s'en fiche) du module "B". C'est ça, un tentacule dans le code, pas autre chose.
Quand tes modules dérivent d'une interface commune prévue pour les faire coexister, mais que ni l'un ni l'autre n'ont besoin de l'existence du module d'à côté, alors c'est "séparé".

Comme je l'ai dit, c'est au noyau principal de coordonner et assembler le tout, c'est lui qui créé les dépendances réelles entre les modules, et ceci à l'exécution. Si c'est à la compilation, c'est "mauvais".

Toi tu parles de modules "absolument complètement totalement indépendants sans le moindre lien entre eux" comme si ce devait être des projets différents n'ayant strictement rien à voir entre eux sans la moindre possibilité d'un quelconque lien.

C'est un peu ça, en effet, ne serait-ce que pour assurer le test unitaire et la possibilité de stubber. Le lien existe, mais c'est au travers d'une interface générique déterminée à l'exécution.

mais vous avez compris ça comme "on fait des modules tentaculaires qui dépendent tous les uns des autres de manière complètement crade"...

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.

[Alakazam]

Oh, le beau microcode à décompiler !!!
Sûr que comparé à l'utilisation de microscope à balayage et de cohortes d'analyseurs logiques nécessaires pour "décompiler" un circuit "fondu", c'est vachement plus sécurisé...

Ah, security through obscurity quand tu nous tiens...

[Mac LAK]

Ah, security through obscurity quand tu nous tiens...

L'idéal étant toujours de mettre les deux : sécurité par algo, puis sécurité par obscurcissement... Aucune protection n'est inviolable, tout est dans la durée de craquage par rapport à la durée d'utilité des éléments craqués.

[Alakazam]

*Ajouter* de l'obscurité volontairement, est toujours une mauvaise idée, car cela rallonge les temps de développement sans apporter de protection concrète et garantie.

[Mac LAK]

*Ajouter* de l'obscurité volontairement, est toujours une mauvaise idée, car cela rallonge les temps de développement sans apporter de protection concrète et garantie.

Quand l'obscurité est faite de façon tacite (circuit câblé / fondu, cryptage de binaires, etc.), c'est un facteur de ralentissement totalement négligeable.

Le but n'est pas l'IOCCC, c'est juste de plomber radicalement le lambda moyen (qui ne saura même pas comment commencer), et de ralentir un hacker "pro" qui, de toutes façons, arrivera à craquer les protections s'il le veut vraiment.
Le but est simplement de le ralentir suffisamment pour qu'il ne soit plus du tout intéressant de craquer les protections en question (obsolescence des données protégées par exemple).

[Alakazam]

Plomber le lambda moyen ne sert à rien, il n'a pas les moyens de craquer l'algorithme qui est destiné au hacker pro. Ralentir le hacker pro ne sert guère, puisque, proportionnellement à l'algorithme, c'est une protection dérisoire.

Partant de là, la sécurité par l'obscurité ne sert à rien, ce n'est pas de la sécurité. "Le code est décompilable" par opposition à "le code est dans les circuits électroniques eux-mêmes" ne doit pas être un critère de choix de technologie.

[davcha]

1. Couche d'en bas (module) : implantation du protocole TCP/IP
2. Couche d'au dessus (module) : envoi de packets et récupérations/vérification via le protocole
3. Couche d'au dessus (module) : fourniture d'un service utilisateur (ouverture socket, envoi message, réception)
4. Couche d'au dessus (module) : interprétation spécialisée du message (décodage HTML)
5. Couche d'au dessus (module) : widget graphique permettant l'affichage du message ainsi interprété
6. Couche d'au dessus (modules) : IHM du navigateur (boutons, historiques, fonction d'impression, etc)

On ne parle pas tout à fait de la même chose, là ^^.

En fait, plutôt que de couches, je parlais plutôt de plug-ins, quand je parlais de modules.

Un exemple qui me vient à l'esprit, pour illustrer le problème : un ERP extensible qui de base ne gère pas grand chose, mais dont chaque fonctionnalité fait l'objet d'un plug-in (plug-in gestion du personnel, plug-in temps-passés, plug-in suivi de dossiers, plug-in rentabilité, etc...)
Il parait évident que le plug-in temps-passés dépend des données fournies par le plug-in gestion du personnel, par exemple.

J'admet que l'exemple est rapide, et qu'en définitive, peut-être le plug-in temps-passés est inclut directement dans le plug-in gestion du personnel. Mais dans ce cas, ce temps passé doit bien être lié à un projet/dossier/travail. Et ces dernièrs éléments font certainement l'objet d'un plug-in n'ayant rien à voir avec le personnel.

Bref.

Dans un cas de ce genre, comment vous faites pour garder une totale indépendance ? Impossible ?

[jabbounet]

On ne parle pas tout à fait de la même chose, là ^^.

En fait, plutôt que de couches, je parlais plutôt de plug-ins, quand je parlais de modules.

Un exemple qui me vient à l'esprit, pour illustrer le problème : un ERP extensible qui de base ne gère pas grand chose, mais dont chaque fonctionnalité fait l'objet d'un plug-in (plug-in gestion du personnel, plug-in temps-passés, plug-in suivi de dossiers, plug-in rentabilité, etc...)
Il parait évident que le plug-in temps-passés dépend des données fournies par le plug-in gestion du personnel, par exemple.

J'admet que l'exemple est rapide, et qu'en définitive, peut-être le plug-in temps-passés est inclut directement dans le plug-in gestion du personnel. Mais dans ce cas, ce temps passé doit bien être lié à un projet/dossier/travail. Et ces dernièrs éléments font certainement l'objet d'un plug-in n'ayant rien à voir avec le personnel.

Bref.

Dans un cas de ce genre, comment vous faites pour garder une totale indépendance ? Impossible ?

ok, mais si c'est bien fait et que les interfaces sont correctement définis tes plug in ne dépendent pas les un des autres dans le sens ou ton plug-in temps passé ne sais absolument rien du plug-in gestion du personnel et de la façon dont il génere ses données.

tout comme la partie mise en page de ton navigateur internet n'a absolument aucune idée de comment lui arrive les données (tcp/ip,hdlc...) et par quel protocole. ce qu'il reçoit c'est du html/du javascript/ ....

[Tommy31]

ok, mais si c'est bien fait et que les interfaces sont correctement définis tes plug in ne dépendent pas les un des autres dans le sens ou ton plug-in temps passé ne sais absolument rien du plug-in gestion du personnel et de la façon dont il génere ses données.

Disons que les plugins interdépendants (conséquence de leur responsabilité métier) sont mis en relation par un couplage faible. Ainsi bien qu'un plugin n'est pas autonome, il n'est pas non plus dépendant d'une instance spécifique (mais d'un représentant quelconque conforme aux interfaces). La plateforme OSGi est une bonne illustration de cela.

[davcha]

ok, mais si c'est bien fait et que les interfaces sont correctement définis tes plug in ne dépendent pas les un des autres dans le sens ou ton plug-in temps passé ne sais absolument rien du plug-in gestion du personnel et de la façon dont il génere ses données.

tout comme la partie mise en page de ton navigateur internet n'a absolument aucune idée de comment lui arrive les données (tcp/ip,hdlc...) et par quel protocole. ce qu'il reçoit c'est du html/du javascript/ ....

Ca, oui, on est tout à fait d'accord.
Toujours est-il que mes plug-ins partagent, partiellement, les mêmes données.