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 ?

:fleche: Êtes-vous d'accord avec l'énoncé de cette règle ?
:fleche: 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 ?

L'informatique rend fou

Citation:

---

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

---

non

Citation:

---

:fleche: 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

Citation:

---

Lequel ?

---

Les traitements dans une chaine automatisée (ordonnancement)

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:

---

produit; att1 ; att2, att3

---

plutôt que sous forme de graphe

Code:

---

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.

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.

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.

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.

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.

Pour le moment tous les exemples que vous donnez sont relativement mauvais :aie:
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.

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

Citation:

---

Envoyé par ctxnop

Pour le moment tous les exemples que vous donnez sont relativement mauvais :aie:
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.

Y'a un endroit ou cette devrait etre appliqué tout le temps: les protocoles. Example type ipv4 :ccool:

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


fallait faire philo les gars !!!

Citation:

---

Envoyé par pseudocode

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.

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

Citation:

---

Envoyé par ctxnop

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

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

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

Citation:

---

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.

Citation:

---

Envoyé par LPaul

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

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

Citation:

---

Envoyé par pseudocode

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