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

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

La règle "zéro, un ou infini" serait omniprésente en génie logiciel,
êtes-vous d'accord ? Et comment la percevez-vous ?

Le , par Idelways
100 commentaires

10PARTAGES

4  2 
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 ?
Vous avez lu gratuitement 482 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.

Une erreur dans cette actualité ? Signalez-nous-la !

100 commentaires
Commenter Signaler un problème
ctxnop
Avatar de ctxnop
Membre expérimenté https://www.developpez.com
Le 19/11/2010 à 16:55
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.
15  1 
pseudocode
Avatar de pseudocode
Rédacteur https://www.developpez.com
Le 19/11/2010 à 17:14
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.
9  0 
Karth
Avatar de Karth
Membre à l'essai https://www.developpez.com
Le 19/11/2010 à 16:27
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.
8  1 
pseudocode
Avatar de pseudocode
Rédacteur https://www.developpez.com
Le 19/11/2010 à 18:12
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.
8  1 
pseudocode
Avatar de pseudocode
Rédacteur https://www.developpez.com
Le 24/11/2010 à 23:04
Citation Envoyé par Trois Sangs Onze Voir le message
Du coup, je dirais que pour moi, la loi du 0,1,n reste une loi théorique. Et comme chacun sait, la pratique est parfois différente de la théorie
Pour moi, c'est surtout une "rule of thumb" (principe général) de conception.

Dans la pratique ca signifie que lorsque je modélise une association avec une multiplicité 2, 3, ... (ou n'importe quelle valeur finie > 2), je pose mon crayon et je me demande s'il y a une bonne raison pour mettre une valeur "en dur" au lieu de mettre "*".
6  0 
ctxnop
Avatar de ctxnop
Membre expérimenté https://www.developpez.com
Le 19/11/2010 à 17:33
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.
4  0 
ctxnop
Avatar de ctxnop
Membre expérimenté https://www.developpez.com
Le 19/11/2010 à 22:30
Oui, plutôt d'accord avec toi, cependant il y a bel et bien une différence entre infini et inconnu. Celle évoquée par pseudocode.

Gérer une quantité infinie signifie que tu prend en compte qu'il n'y a pas de fin. Tu ne peux donc pas référencer la fin d'une collection puisqu'elle est infinie.
Tu ne peux pas non plus la parcourir bêtement car il n'y a pas de fin à ce parcourt.

C'est donc tout de même assez différent d'une quantité finie mais non connue au moment de la conception, car même si elle n'est pas connue elle est comptable. Il y aura donc une fin référençable à ta collection, un milieu dans ta liste, etc...

Donc oui, faire un algo gérant une infinité permettra aussi de gérer un ensemble fini. Cependant il ne sera probablement pas modélisé de la même façon qu'un algo qui gère une quantité finie mais inconnue.

A mon avis il y a une différence de vocabulaire comme il y en as entre la physique et les mathématiques. L'infini n'existe qu'en mathématique pure. En conception on parle "d'infini" quand on quantifie par "*". Mais comme il a été dit un peu plus haut, le "*" signifie plutôt "plusieurs" et non pas infini.
5  1 
pseudocode
Avatar de pseudocode
Rédacteur https://www.developpez.com
Le 19/11/2010 à 23:48
Citation Envoyé par ctxnop Voir le message
En conception on parle "d'infini" quand on quantifie par "*". Mais comme il a été dit un peu plus haut, le "*" signifie plutôt "plusieurs" et non pas infini.
C'est vrai que la règle "Zéro, Un ou Plusieurs" me plait déjà plus.

Mais pour reprendre mon post #3, les solutions à un problèmes de "Job Shop" sont plus faciles à concevoir en fixant précisément le nombre des entités. Si on garde cette valeur en inconnue, on arrive a des algorithmes généraux horriblement complexes et surtout difficilement prouvables. Alors qu'avec un nombre connu, on peut lister exhaustivement tous les cas possibles et prouver que ca marchera tout le temps.

Cela dit il est vrai que c'est un cas particulier, mais c'est celui que je rencontre en ce moment. Et puis, comme le dit wikipedia, c'est une "rule of thumb" et pas une vérité absolue.
3  0 
ctxnop
Avatar de ctxnop
Membre expérimenté https://www.developpez.com
Le 20/11/2010 à 1:41
Citation Envoyé par TNT89 Voir le message
Pour la forme : l'infini existe aussi en physique et est assez courant (optique / électromagnétique, calcul infinitésimal...).
Je n'ai pas dis le contraire. Je ne me souviens pas avoir écrit qu'en physique l'infini n'existe pas.J'ai juste évoqué les différence de vocabulaire entre les physiciens et les mathématiciens car les réalités d'un domaine ne sont pas celle d'un autre. Je me souviens des débats animés que ca provoquait entre mon prof de physique appliqué (électronique) et mon prof de maths quand j'étais au lycée (bien que j'en ai complètement oublié le sujet exacte).

Citation Envoyé par bugsan Voir le message
La réponse qu'il faut donner à ce que l'on peut désigner comme de l'over-engineering, c'est : YAGNI (you aint gonna need it)
C'est surement en grande partie à cause de cette réflexion qu'on se retrouve si souvent face à des problèmes tels que la pénurie d'IPv4, la limitation de taille de fichier à 4Go sur le FAT32, etc...
Des limitations pour lesquelles on s'est surement dit qu'on atteindrait jamais ces limites...
Et puis c'est un coup dur pour l'innovation si on part du principe qu'on inventera jamais dérivé des échec sur une grille de taille différente.
3  0 
bugsan
Avatar de bugsan
Membre confirmé https://www.developpez.com
Le 20/11/2010 à 11:52
Citation Envoyé par ctxnop Voir le message
C'est surement en grande partie à cause de cette réflexion qu'on se retrouve si souvent face à des problèmes tels que la pénurie d'IPv4, la limitation de taille de fichier à 4Go sur le FAT32, etc...
Des limitations pour lesquelles on s'est surement dit qu'on atteindrait jamais ces limites...
Nan les gens qui ont fait ses limitations savaient qu'elles seraient à revoir un jour. Ils se sont juste dit "on verra le jour venu". Ce qui pour moi n'est pas la même chose.
Ex: Les successeurs à FAT32 ne se contentent pas d'augmenter la taille des fichiers, loin de là. Idem pour ipv4. C'est une erreur de faire croire que si on met au point de nouveau standard ce n'est que pour une question de taille ou quantité limitée.

La re-conception est inévitable et permanente. Il faut l'accepter. Il faut accepter le changement ...

Citation Envoyé par suntsu Voir le message
Actuellement, la quantité de mémoire dont nous disposons rend obsolète le fait de limité à 7 (3bits de données) le nombre de jours dans une semaine... Autant prévoir directement 8,16,32 ou même 64bit d'espace ! J'exagère un peu ici mais je veux juste illustré que vouloir être trop "radin" peux entrainer à plus ou moins longue échéance de gros problèmes...
Si on se remet dans le contexte de l'époque, avec ses limitations techniques etc... on comprend qu'ils aient choisi de faire comme ça. Alors c'est un peu facile à dire maintenant que l'on n'a plus aucun problème d'espace mémoire. Quel développeur aurait mis des variables comme ça sur 64bit en 1970 ? Selon toi il aurait du aller voir le responsable des achats pour lui dire qu'il était trop "radin" ?
D'ailleurs, ces contraintes matérielles ont longuement influencées aussi la philosophie / morale des développeurs. Le développeur qui aurait mis tout sur 64bit aurait été la risée de ses collègues. Les honneurs ultimes étant décernées à celui qui aura "optimisé" au maximum l'espace mémoire. Rendant impossible toute évolution, mais ça, ce n'était pas dans l'air du temps.
4  1 
Commenter Signaler un problème