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, Expert éminent sénior
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 aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de mvvvv mvvvv - Membre averti https://www.developpez.com
le 19/11/2010 à 15:28
L'informatique rend fou
Avatar de pseudocode pseudocode - Rédacteur https://www.developpez.com
le 19/11/2010 à 15:31
Ê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)
Avatar de _skip _skip - Expert éminent https://www.developpez.com
le 19/11/2010 à 15:35
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
produit; att1 ; att2, att3
plutôt que sous forme de graphe

Code : Sélectionner tout
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.
Avatar de CIFQ_Drew CIFQ_Drew - Membre averti https://www.developpez.com
le 19/11/2010 à 15:53
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.
Avatar de Karth 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.
Avatar de el_slapper el_slapper - Expert éminent sénior https://www.developpez.com
le 19/11/2010 à 16:31
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.
Avatar de Isammoc Isammoc - Nouveau membre du Club https://www.developpez.com
le 19/11/2010 à 16:35
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.
Avatar de ctxnop 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.
Avatar de frinux frinux - Membre habitué https://www.developpez.com
le 19/11/2010 à 17:08
Wahou je pige rien à ce que vous dites là !
Avatar de pseudocode 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.
Offres d'emploi IT
Ingénieur H/F
Safran - Ile de France - Moissy-Cramayel (77550)
Architecte et intégrateur scade/simulink H/F
Safran - Ile de France - Vélizy-Villacoublay (78140)
Ingénieur conception en électronique de puissance H/F
Safran - Ile de France - Moissy-Cramayel (77550)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil