1. #1
    Expert éminent sénior
    Avatar de Idelways
    Homme Profil pro
    Développeur Ruby on Rails / iOS
    Inscrit en
    juin 2010
    Messages
    1 374
    Détails du profil
    Informations personnelles :
    Sexe : Homme

    Informations professionnelles :
    Activité : Développeur Ruby on Rails / iOS

    Informations forums :
    Inscription : juin 2010
    Messages : 1 374
    Points : 68 480
    Points
    68 480

    Par défaut La règle "zéro, un ou infini" serait omniprésente dans le développement logiciel

    La règle "zéro, un ou infini" serait omniprésente dans le développement logiciel
    Etes-vous d'accord ? Et comment la percevez-vous ?



    Dans la conception logicielle, une règle de base serait omniprésente. Elle s'appelle "Zéro, un ou l'infini" et stipule que toute architecture logicielle destinée à un nombre limité d'instances (supérieure à 1) doit être prohibée.

    Pour mémoire, cette règle a été énoncée pour la première fois par Willem Louis van der Poel, pionnier hollandais des sciences informatiques.

    Un système de fichiers, par exemple, est conçu suivant cette règle : le dossier racine '/' n'a aucun parent. Tous les autres dossiers n'ont qu'un seul parent et peuvent contenir une infinité de fichiers et de dossiers (sauf limitations à 65536 inhérente à l'architecture globale, mais le principe reste le même).

    Concevoir un système pour un nombre arbitraire serait donc tout simplement une erreur de conception.

    La logique derrière ce postulat est qu'il existe de nombreuses situations où un système doit être conçu pour répondre à un besoin unique et spécifique (dans ce cas il s'agit d'une exception), mais en aucun cas pour deux (sinon pourquoi pas 2+1, 3+1, N+1... ?)

    Et vous ?

    Êtes-vous d'accord avec l'énoncé de cette règle ?
    Avez-vous déjà été confrontés à des cas où il vous a fallu concevoir un système pour un nombre précis (>1) d'instances ? Lequel ?

  2. #2
    Membre averti
    Profil pro
    Inscrit en
    mai 2009
    Messages
    196
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : mai 2009
    Messages : 196
    Points : 358
    Points
    358

    Par défaut CQFD !!!

    L'informatique rend fou

  3. #3
    Rédacteur
    Avatar de pseudocode
    Homme Profil pro
    Architecte système
    Inscrit en
    décembre 2006
    Messages
    10 052
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Architecte système
    Secteur : Industrie

    Informations forums :
    Inscription : décembre 2006
    Messages : 10 052
    Points : 15 721
    Points
    15 721

    Par défaut

    Êtes-vous d'accord avec l'énoncé de cette règle ?
    non

    Avez-vous déjà été confrontés à des cas où il vous a fallu concevoir un système pour un nombre précis (>1) d'instances ?
    oui, tous les jours

    Lequel ?
    Les traitements dans une chaine automatisée (ordonnancement)
    ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.

  4. #4
    Expert éminent
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 898
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 898
    Points : 7 400
    Points
    7 400

    Par défaut

    C'est une règle qu'on retrouve pas mal en modélisation avec les notations "0, 1, n". J'avoue avoir transgressé ces règles pour des raisons de performance lorsqu'il était plus facile de traiter un dataset à "plat" de la forme

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    produit; att1 ; att2, att3
    plutôt que sous forme de graphe

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    produit
      |
      |__ att 3
      |__ att 2
      |__ att 1
    A l'aide d'une requête SQL. On savait que 3 était le maximum dans la pratique et cette représentation, bien qu'assez moche sur papier avait le mérite d'éviter tout un coûteux traitement de démêlage.

  5. #5
    Membre averti

    Inscrit en
    novembre 2007
    Messages
    197
    Détails du profil
    Informations personnelles :
    Âge : 36

    Informations forums :
    Inscription : novembre 2007
    Messages : 197
    Points : 357
    Points
    357

    Par défaut

    Et bien pour ma part j'ai souvent des situations du genre ou j'ai des nombres "arbitraire". Par exemple, une horaire possède un modèle de 7 jours. J'ai une table horaire et une table jours. Ma BD permet 1 à plusieurs mais mon code permet 1 à 7.

    Ce n'est qu'un exemple.
    ______________
    Never underestimated the browser
    Ne jamais sous-estimé le navigateur
    Vic Gundotra, Google IO 2009

  6. #6
    Membre à l'essai
    Inscrit en
    mai 2004
    Messages
    9
    Détails du profil
    Informations forums :
    Inscription : mai 2004
    Messages : 9
    Points : 22
    Points
    22

    Par défaut

    C'est clairement un problème de technique pure vs métier.

    Je suis entièrement d'accord avec la règle énoncée. D'un point de vue purement conceptuel, elle est correcte, et je préfère m'y conformer le plus souvent possible.

    Maintenant, l'informatique doit s'adapter au métier:

    - Nous avons des machines aux capacités finies: les objectifs de performances obligent à limiter le nombre maximal d'éléments traités.
    - Les règles de gestion établies par le métier limitent souvent les ensembles à des quantités finies (et ça apparaît dans les specs). Il n'est pas toujours possible d'aller outre.

  7. #7
    Expert éminent sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    5 104
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 5 104
    Points : 22 257
    Points
    22 257

    Par défaut

    COBOL ne permet pas d'aller à l'infini. Il faut toujours délimiter ses zones mémoires - en violation permanente de la règle énoncée ici.

    C'est parfois très chiant(alors, je ne sais pas combien de campagnes je peux annuler d'un coup, aller, au hasard, je mets 50, et si ça plante, on agrandira). C'est souvent nécéssaire. L'exemple des jours de la semaine ou des mois de l'année est un parmi de nombreux autres.

    Il peut aussi y avoir des raisons technico-fonctionelles, genre, il y aura toujours au maximum 6 libellés de 32 caractères(existe sur mon projet actuel) pour décrire la campagne. Ca permet de limiter la taille des fichiers transférés. Parceque c'est gentil de dire "on peut mettre autant de libellés qu'on veut de la taille qu'on veut", mais au final, sur la lettre papier, ça rentre pas... Donc ça n'est pas demandé, et ça ne le sera jamais.

    Comme toujours, si on peut sans contraintes majeurs, monter à l'infini, la maintenance sera plus facile. Mais assez souvent on croise assez vite des limites techniques, fonctionelles, ou les deux, qui amènent à être moins dogmatique sur ce genre de sujet. Même sur des langages moins rigides que COBOL.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  8. #8
    Nouveau membre du Club
    Profil pro
    Inscrit en
    novembre 2009
    Messages
    27
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : novembre 2009
    Messages : 27
    Points : 39
    Points
    39

    Par défaut

    A quoi servent donc les énumérations ?
    Les constantes imposés (24h dans un journée, 7 jours dans une semaine, un jeu de l'oie de 65 cases) ?

    La plupart du temps, il faut prévoir l'extension :
    exemple : Windows / Mac / Linux autres ?
    mais un nombre limité est nécessaire pour des raisons de spécificités.

    Pour les matheux : un polygone n'est pas un cercle, même si le nombre de cotés n'est pas fixé à l'avance.

  9. #9
    Membre chevronné Avatar de ctxnop
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juillet 2007
    Messages
    858
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Morbihan (Bretagne)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2007
    Messages : 858
    Points : 1 751
    Points
    1 751

    Par défaut

    Pour le moment tous les exemples que vous donnez sont relativement mauvais
    Avant de s'offusquer, revenons au sujet de base qui parle de conception, pas d'implémentation ou de réalité physique.

    Un jour est limité à 24h ? Oui, sur Terre, pas sur Mars, Jupiter ou je ne sais quelle autre planète, et encore, c'est sujet à variation dans le temps.
    Rien ne nous assure non plus que cette règle internationale ne va pas changer dans un temps futur. Et de toute façon, ce n'est qu'une unité de temps, 48h c'est possible, ca veut juste dire 2 jours.

    65 cases sur un jeu de l'oie ? Qu'est-ce qui m'empêche d'inventer un nouveau jeu avec un plateau à 52 cases ? ou 138 ? Si je le fait il faudra à nouveau tout re-concevoir ?

    La très grande majorité des "constantes" ne sont absolument pas des constantes, ce sont des règles établies par les hommes selon l'avancement de leurs connaissance.

    Alors oui, la réalité physique est bien la, l'infinité n'existe pas réellement, mettre 2 574 294 349 roues à une petite voiture n'est pas physiquement possible.

    Par contre, conceptuellement, que la voiture soit équipée 4 ou 2 000 000 000 de roues, ca change rien.

    La limitation physique et/ou technique est un autre soucis, qu'il ne faut pas perdre de vu.
    Mais le fait est qu'on ne peut pas deviner de quoi demain sera fait, les limites physiques/techniques évolueront peut être, il est plus logique de gérer un "infini", ainsi, si la limitation physique/technique change, on a rien à changer dans la conception.

  10. #10
    Membre habitué
    Inscrit en
    septembre 2008
    Messages
    174
    Détails du profil
    Informations forums :
    Inscription : septembre 2008
    Messages : 174
    Points : 154
    Points
    154

    Par défaut

    Wahou je pige rien à ce que vous dites là !

  11. #11
    Rédacteur
    Avatar de pseudocode
    Homme Profil pro
    Architecte système
    Inscrit en
    décembre 2006
    Messages
    10 052
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Architecte système
    Secteur : Industrie

    Informations forums :
    Inscription : décembre 2006
    Messages : 10 052
    Points : 15 721
    Points
    15 721

    Par défaut

    Citation Envoyé par ctxnop Voir le message
    Pour le moment tous les exemples que vous donnez sont relativement mauvais
    Avant de s'offusquer, revenons au sujet de base qui parle de conception, pas d'implémentation ou de réalité physique.
    Conception certes. Mais Conception Logicielle. Dans le but au final d'être implémenté dans un logiciel. Logiciel codé dans un langage informatique... limité (binaire, octet, ...)

    Je fais partie de ceux qui aiment bien conceptualiser un problème, mais il ne faut pas perdre de vue l'objectif final. Une solution universelle c'est bien. Une solution optimale, c'est pas mal non plus.
    ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.

  12. #12
    Membre éprouvé Avatar de Elepole
    Profil pro
    Développeur informatique
    Inscrit en
    avril 2010
    Messages
    504
    Détails du profil
    Informations personnelles :
    Âge : 28
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : avril 2010
    Messages : 504
    Points : 1 126
    Points
    1 126

    Par défaut

    Y'a un endroit ou cette devrait etre appliqué tout le temps: les protocoles. Example type ipv4
    Citation Envoyé par Killing Joke Voir le message
    1984 : Big Brother is watching you.
    2011 : Big Brother is hosting you.

  13. #13
    Membre averti
    Profil pro
    Inscrit en
    mai 2009
    Messages
    196
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : mai 2009
    Messages : 196
    Points : 358
    Points
    358

    Par défaut

    saperlipopette .... suis - je donc le seul à trouver cette discussion ubuesque ?


    fallait faire philo les gars !!!

  14. #14
    Membre chevronné Avatar de ctxnop
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juillet 2007
    Messages
    858
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Morbihan (Bretagne)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2007
    Messages : 858
    Points : 1 751
    Points
    1 751

    Par défaut

    Citation Envoyé par pseudocode Voir le message
    Conception certes. Mais Conception Logicielle. Dans le but au final d'être implémenté dans un logiciel. Logiciel codé dans un langage informatique... limité (binaire, octet, ...)
    Une conception "sans limite" ne veut pas dire une implémentation sans prise en compte des contraintes techniques.

    Simplement, a la conception on considère l'infini, à l'implémentation on pose une limite à cet infini, une limite souvent déclarée en tant que constante, qu'énumération, etc...

    Ainsi, on a un calendrier à 7j dont 5 travaillé, si demain ca change, on a juste à changer la valeur de la constante dans le code pour faire évoluer la limite à travers tout le logiciel et hop, ca fonctionne.

    Tout ce qui est dit ici, c'est qu'en phase de conception on fait on ne dit pas "un jeu de l'oie à 65 cases", on dit "un jeu de l'oie à NB_CASES".
    Après, à l'implémentation du écrit "NB_CASES = 65", pas de problème, si demain ca change, il n'y a qu'a faire évoluer cette constante, le reste ne change pas. Puisque tout le reste à été conçut pour un nombre inconnu de cases, alors si ca marche pour un nombre inconnus ca veut dire que ca marche quelque soit le nombre.

    Par contre si à la conception tu te dis "il y a 65 cases", tu conserveras ce nombre en tête pour tous les autres choix de conceptions et du coup tu va amener des limitations là où il n'y en avait pas, sans même te rendre compte. Par exemple, pour la conception du format de sauvegarde d'une partie, tu va te dire que tu as besoin uniquement de 65 entiers pour représenter les 65 cases. Si demain ca devient 52, ton format de fichier de sauvegarde devient inutilisable, incompatible, etc... Alors que si tu avait pris un nombre inconnu, tu aurai pensé au fait d'indiquer dans le fichier le nombre de cases et donc conserver un code compatible quelque soit le nombre de cases.
    Tu va te poser le même problème à l'implémentation, car en lisant ton cahier des charges tu va lire "65 cases" et du coup tu va écrire en dur "65" dans ton code partout où tu en as besoin. Résultat, si demain ce nombre change, il faut repasser partout dans le code et tu t'expose à un risque de changement profond.

  15. #15
    Membre à l'essai
    Inscrit en
    mai 2004
    Messages
    9
    Détails du profil
    Informations forums :
    Inscription : mai 2004
    Messages : 9
    Points : 22
    Points
    22

    Par défaut

    @pseudocode:
    Je ne vois pas en quoi avoir à l'esprit un principe de fond sur la conception, fût-elle logicielle, empêche de savoir la réalité des contraintes et d'agir en conséquence. Le principe n'en est pas moins vrai.

  16. #16
    Rédacteur
    Avatar de pseudocode
    Homme Profil pro
    Architecte système
    Inscrit en
    décembre 2006
    Messages
    10 052
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Architecte système
    Secteur : Industrie

    Informations forums :
    Inscription : décembre 2006
    Messages : 10 052
    Points : 15 721
    Points
    15 721

    Par défaut

    Citation Envoyé par ctxnop Voir le message
    Tout ce qui est dit ici, c'est qu'en phase de conception on fait on ne dit pas "un jeu de l'oie à 65 cases", on dit "un jeu de l'oie à NB_CASES".
    Après, à l'implémentation du écrit "NB_CASES = 65", pas de problème, si demain ca change, il n'y a qu'a faire évoluer cette constante, le reste ne change pas. Puisque tout le reste à été conçut pour un nombre inconnu de cases, alors si ca marche pour un nombre inconnus ca veut dire que ca marche quelque soit le nombre.
    Hum. Oui et non. Ce qui est dit dans le post original c'est qu'on doit considérer un nombre infini de cases, pas un nombre inconnu de cases.

    C'est très différent de faire une application qui gère un nombre fini "n" de cases, et une application qui en gère une infinité. Ne serait-ce que pour identifier les cases (la première ? la dernière ?) ou les parcourir.


    Citation Envoyé par Karth Voir le message
    @pseudocode:
    Je ne vois pas en quoi avoir à l'esprit un principe de fond sur la conception, fût-elle logicielle, empêche de savoir la réalité des contraintes et d'agir en conséquence. Le principe n'en est pas moins vrai.
    C'est juste que j'ai l'habitude de documenter mes architectures logicielles (IEEE Std 1016), et d'y préciser le contexte, le périmètre, les limitations, les contraintes, ... Ca permet de pouvoir justifier une décision d'architecture. Et, à l'inverse, de pouvoir revenir sur une décision si la limite/contrainte change.
    ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.

  17. #17
    Membre éprouvé
    Avatar de tails
    Homme Profil pro
    Inscrit en
    novembre 2003
    Messages
    605
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations forums :
    Inscription : novembre 2003
    Messages : 605
    Points : 969
    Points
    969
    Billets dans le blog
    8

    Par défaut

    @frinux

    Si je peux me permettre :

    je pense que l'une des idées principales de ce qu'a essayé d'expliquer ctxnop, c'est tout simplement que l'informatique permet de définir des limites qui n'ont aucun sens dans la réalité.

    Ainsi, si en programmation, on peut attribuer 10000 références Roues à un objet Voiture; alors la réalité sera mal modélisée.

    Et que par conséquent, la règle du zero, un ou infini n'est pas souhaitable ici.

  18. #18
    Futur Membre du Club
    Profil pro
    Inscrit en
    octobre 2010
    Messages
    2
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : octobre 2010
    Messages : 2
    Points : 6
    Points
    6

    Par défaut

    Ainsi, si en programmation, on peut attribuer 10000 références Roues à un objet Voiture; alors la réalité sera mal modélisée.
    Et qui dit que dans 20 ans on utilisera pas des voitures avec 1 000 (mini)roues ?
    Rien, donc permettre de la modéliser dans ton application sans avoir à modifier le code source est un plus.

  19. #19
    Rédacteur
    Avatar de pseudocode
    Homme Profil pro
    Architecte système
    Inscrit en
    décembre 2006
    Messages
    10 052
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Architecte système
    Secteur : Industrie

    Informations forums :
    Inscription : décembre 2006
    Messages : 10 052
    Points : 15 721
    Points
    15 721

    Par défaut

    Citation Envoyé par LPaul Voir le message
    Et qui dit que dans 20 ans on utilisera pas des voitures avec 1 000 (mini)roues ?
    Rien, donc permettre de la modéliser dans ton application sans avoir à modifier le code source est un plus.
    Oui, j'étais aussi de cette avis dans mes jeunes années.

    Je pensais que la meilleure solution était la plus générale, la plus extensible, la plus réutilisable, la plus paramétrable, etc. Avec le temps, je me suis rendu compte que la meilleure solution était souvent la plus simple.
    ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.

  20. #20
    Membre à l'essai
    Inscrit en
    janvier 2010
    Messages
    12
    Détails du profil
    Informations forums :
    Inscription : janvier 2010
    Messages : 12
    Points : 12
    Points
    12

    Par défaut

    Citation Envoyé par pseudocode Voir le message
    Hum. Oui et non. Ce qui est dit dans le post original c'est qu'on doit considérer un nombre infini de cases, pas un nombre inconnu de cases.

    C'est très différent de faire une application qui gère un nombre fini "n" de cases, et une application qui en gère une infinité. Ne serait-ce que pour identifier les cases (la première ? la dernière ?) ou les parcourir.




    C'est juste que j'ai l'habitude de documenter mes architectures logicielles (IEEE Std 1016), et d'y préciser le contexte, le périmètre, les limitations, les contraintes, ... Ca permet de pouvoir justifier une décision d'architecture. Et, à l'inverse, de pouvoir revenir sur une décision si la limite/contrainte change.
    Euh c'est moi ou inconnu veut aussi dire potentiellement infini ? Je pense que dans ce cas de figure les deux termes sont équivalents. L'infini n'existe pas en informatique, même si on peut le modéliser...

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