Discussion :

[carado]

Moi je dirais plustot 1, n ou limite technique.
Mais ca revient a peu pres au meme.


Et je suis d'accord que c'est (quasiment ?) toujours vrai.

[kisitomomotene]

Quelqu'un peut me donner un lien ou cette régle est définie et expliquée avec clarté et detail?
Merci

[Kantizbak]

Pour moi c'est un problème philosophique et chacun peut trouver sa réponse sans déroger à cette règle.

J'ai toujours conçu des choses dans l'esprit 0,1, infini (avec un esprit suite numérique plutôt d'ailleurs) avec un raisonnement que nous appliquons tous à savoir : qui peut le plus peut le moins.
bon bah il se trouve que "infini" est fini en fait. Mais ce n'est jamais non plus jamais le même.
Il n'est pas fini pareil sur les machines 32 et 64 bits.
Donc on conçoit pour 0, 1 ou l'infini et ensuite on rend les choses concrètes.

Le meilleur exemple à mon sens c'est la configuration d'un serveur, d'une application, etc.
On a un système de gestion de règle qui prend en compte une infinité de cas potentiels, mais dans les cas concrets, on peut avoir que 1, 2 ou 3 configurations connues (qui marchent) par exemple pour Mac, Win et Linux.

C'est la différence entre concevoir pour l'infini (on manipule une liste) mais savoir qu'au final on ne manipule que quelques cas finis (par conception et ensuite par tests/expérience, on a des configurations fixes finies).

C'est aussi simple à mon sens.

Concevoir pour 2 cas précis revient à mon sens à faire 1 d'un côté et 1 de l'autre dans un système qui peut contenir potentiellement une infinité de cas concrets.

Sachant que tous les langages permettent la prise en compte d'une infinité de cas, tout le monde respecte cette règle \o/

Bon ok pas tout le monde, j'ai vu des horreurs moi aussi. Mais au final, gérer de cas finis (liés au métier, cas concrets, etc.) ce n'est pas casser cette règle de conception.

[lemra]

Bonjour à tous,

Face à une problématique (un peu) abstraite,
très interessant de voir les types de réponse.

En résumé :

- où est le problème // qu'est ce qu'il raconte ?

- Garder les mains propres quitte à s'embêter puisssance mille.

- Avoir conscience du problème, le prendre en compte mais si le coût
est disproportionné introduire N.


Ainsi, je prends le risque insensé de considerer que dans 10 ans une semaine fera toujours 7 jours.

[Filippo]

Bonjour,
je pense que l'arborescence est particulièrement adaptée pour représenter un système de fichiers de serveurs etc ...

Il y a une racine et un unique chemin élémentaire pour aller de la racine à n'importe quel sommet de l'arborescence.

Cela permet également d'organiser les données en les hiérarchisant.

[sekaijin]

Bonjour

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

en général oui. lorsque je vois une conception qui utilise un tableau de taille fixe d'élément je me pose la question et j'analyse pour savoir on ne risque pas dans un avenir proche d'avoir un pb avec.

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 ?

Oui tout les jours
nombre d'instance 2. dans la conception des SI d'entreprise les choses vont très souvent par deux. l'application Alpha et son secours.
le mode de fonctionnement d'une application du SI Online, Offline (donc par exemple pour les paramètres de l'application dépendant du mode il existe en deux exemplaires ou on a deux groupes de paramètres) etc.

A+JYT

[Nebulix]

Tout celà nous ramène au classique :
Il y a 10 sortes d'informaticiens : ceux qui comprennent le binaire et les autres.
Si les autres veulent construire une informatique non binaire, souhaitons leur bon courage

[amaillere]

je trouve ça incomplet

j'aurai rajouté 2... c'est quand même un peu tous les jours qu'on le trouve.
déjà pour tout ce qui est binaire: homme femme, ok / ko.
mais c'est valable aussi pour des relation métier : les deux géniteurs d'un enfant, les deux équipes d'un match, le client/le serveur (et plus généralement l'émetteur et le récepteur d'un message).
Rien n'empêche de modéliser ca en mettant une relation 1-n mais bon je me moquerais sans doute un peu du gars qui coderai comme ça

[zaventem]

j'aurai rajouté 2... c'est quand même un peu tous les jours qu'on le trouve.
déjà pour tout ce qui est binaire: homme femme, ok / ko.

Globalement d'accord mais attention à bien cerner le problème au départ.
Par exemple, si dans certains cas on peut se limiter à homme/femme, j'ai déjà été confronté à des situation homme/femme/non applicable/inconnu.

[shenron666]

0,1,n -> ok
0,1,infini -> non
l'énoncé est faux, et de toute façon, comme on le dit trop souvent, il ne faut pas généraliser

exemple dans le cas d'un traitement en parallèle sur une machine équipée de plusieurs processeurs : ça n'a aucun intérêt de lancer plus de traitements simultanés qu'il n'y a de processeurs sur la machine, au mieux on ne gagne rien, au pire on perd en performances

[pghislain]

0 = non
1 = oui
2 = nul - haute impédance

Cette règle me semble dépendante des problèmes pausés et ne fait pas l'économie des moyens. En générale, elle sera donc fause puisque les moyens sont limités.

[Barsy]

0 = non
1 = oui
2 = nul - haute impédance

Cette règle me semble dépendante des problèmes pausés et ne fait pas l'économie des moyens. En générale, elle sera donc fause puisque les moyens sont limités.

l'état "haute impédance" n'est pas un état logique à proprement parler, il s'agit d'avantage d'un état d'écoute ou de non interférence sur un bus partagé entre plusieurs appareils.

Cela dit, je pense que c'est limite hors sujet...

[Virgil Scipion]

En théorie oui.
En pratique aussi, la plupart du temps.

Mais quand on sait que le nombre d'instances sera toujours limité, et que ce nombre est très réduit (le meilleur exemple : 2), pour me simplifier la vie je me base sur un nombre fini d'instance.
Car il est plus simple d'accéder à deux variables plutôt qu'à un tableau.

Mais quand on commence à avoir un nombre plus important, ne serait-ce que 5, alors là oui, c'est mode infini et utilisation de liste.

[Mpolo]

Bein je crois bien que je n'ai rien pigé moi aussi.
Si j'ouvre Internet, c'est une instance ? si dans le même temps j'ouvre Media Player, est-ce une autre instance ?
Mon ordi doté de deux + deux cores est paraît-il de traiter les deux simultanément sans problème.
Maintenant si je conçois une appli qui demande de mettre en route ces deux instances afin qu'une renseigne ou approvisionne l'autre est-ce que je déroge au principe ?
Risque-je des poursuites (je rigole) suis-je ou à côté de la plaque (et là je risque de faire rigoler, donc tant mieux) ?

[Invité]

Dans les logiciels de conception (UML, Merise, etc.) qui sont des logiciels qui ont été pensés pour schématiser n'importe qu'elle architecture de manière générale, on retrouve de manière très présente les trois cas 0,1,infini dans les mutiplicités/cardinalités. Il doit s'agir donc d'une pseudo-règle qui peut être suivie par un grand nombre d'applications.
Par contre, il subsiste évidement des cas très spéciaux, d'ou l'ajout dans ce type de logiciel de petits pour indiquer la valeur que l'on souhaite.

Typiquement, dans une application dédiée à la généalogie, on se retrouve avec un enfant qui a... 2 parents.
Ces cas spéciaux dépendent bien évidemment des contraintes imposées. Car on pourrait naturellement concevoir d'avoir n parents (parents biologiques, parents d'adoption, etc.)
Cependant, ces cas restent rares ou en tous cas, il y a toujours une bonne raison pour laquelle on a choisi cette structure (optimisation, raisons techniques, etc.)

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

[pseudocode]

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

[remond]

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

Pourrais tu m'en citer quelques unes ??

[sekaijin]

Pourrais tu m'en citer quelques unes ??

1. mon robot à deux bras et deux jambes il n'y a aucune raison de mettre 1 ou de mettre * il n'y en a que deux de chaque c'est matériellement impossible de lui en mettre plus.
2. pour le déplacement d'un objet dans l'espace j'ai exactement 6 degrés de liberté translation sur les axes des X des Y et des Z rotation sur les axes X, Y et Z.
3. le satellite qui doit partir pour explorer un astéroïde possède exactement 27 propulseur à gaz de positionnement. il n'en aura jamais plus ni moins.
4. mon home cinéma possède 6 HP, un aigu face un caisson basse deux avant et deux arrières.
5. la plaque de cuisson vitrocéramique a exactement 4 point de chauffe.
6. La chaudière de ma résidence à 2 brûleurs, 5 vannes de répartition 2 motopompes.

dans tous ces cas il convient de se poser la question dois-je modéliser avec le nombre exact ou avec *

1. pour le robot espace mémoire oblige dans le microcontrôleur moins on en consomme mieux c'est.
2. pour les degrés de liberté c'est physiquement impossible d'en avoir plus inutile de mettre *
3. pour le satellite c'est de l'embarque comme pour le robot mais ne vais-je pas en construire un autre dans l'avenir ?
4. pour le home cinéma je peux me poser la question de l'avenir n'existera-t-il pas de système plus pourvus ?
5. de même pour les plaque de cuisson j'en aurais-je pas 5 ou 6 dans l'avenir ?
6. pour la chaudière c'est évident suivant l'installation ces quantités peuvent varier.

A+JYT

[pseudocode]

Pourrais tu m'en citer quelques unes ??

La raison la plus courante que je rencontre (et que j'ai déjà cité), c'est que le problème est beaucoup plus simple à résoudre avec un nombre limité et connu d'instances. Faire une conception généraliste avec un nombre illimité ou inconnu rendrait le problème différent, complexe, voir insoluble.



Y a-t-il une bonne raison de modéliser plus de 3 piquets pour ce jeu ?

(En particulier si c'est pour avoir plus de piquets que de disques )

[remond]

non mais je ne vais certainement pas me contenter d'un jeu avec seulement 3 disques, alors qu'au niveau de la conception ça suffit largement

En tout cas, merci pour vos exemples.