OW2 Consortium
Search OW2 Mail Archive: 

Advanced Search - Powered by Google


Mail Archive Home | docdoku-dev List | November 2011 Index

<--  Date Index  --> <--  Thread Index  -->

[[docdoku-dev]] Fwd: Réponses aux questions.




De : Florent Garin <florent.garin@xxxxxxxxxxx>
Objet : Rép : Réponses aux questions.
Date : 31 octobre 2011 14:00:53 HNEC
À : PERASSO Grégory (RIC-CH) <gregory.perasso@xxxxxxxxxxxxx>



Le 31 oct. 2011 à 13:29, PERASSO Grégory (RIC-CH) a écrit :

 
 
Oui, je sais bien tout ça et nous l'avons d'ailleurs modélisé. Mais justement, si tu places ton effectivité sur un WTPartMaster (sur une version pour être précis) rien n'indique que tu ne veux la voir appliquée que dans le cas où ce WTPartMaster est employé dans un lien de substitution donné.
Si ton WTPartMaster est standard, il peut très bien se retrouver ailleurs dans la product structure, sur d'autres liens d'usage ou d'autres liens de substitution. Comment alors distinguer ces cas si ce n'est en mettant l'effectivité directement sur les liens de substitution.
 
Non ?
 
 
Si justement. si il est « ailleurs » dans la product structure, cela veut dire que tu es sur une autre instance du lien WTpartUsageLink. Tu peux être substitut sur un lien, mais pas sur un autre , dans un autre niveau de la BOM.
Si tu ne veux pas ou plus l’appliquer. Cela veut dire que c’est le père que tu dois changer de version et y enlever la substitution et mettre l’effectivité attendue.
 

Yes, on y vient ! Cette solution fonctionne mais du coup cela ne me semble pas pratique car on doit carrément enlever le lien de substitution simplement parce qu'on ne veut pas l'appliquer. Il y a donc perte d'information car on ne veut pas exprimer que la substitution n'est pas possible mais simplement qu'on ne veut pas l'appliquer. On revient en quelque sorte à faire de la gestion de configuration "manuellement".
La solution idéale n'est-elle pas de conserver l'ensemble des liens de substitution et simplement mettre l'effectivité sur les liens. Cela éviterait de créer des versions "fictives" uniquement par effet de bord parce qu'un lien d'effectivité traine quelque part ailleurs dans la structure sur le PartMaster de substitution.

En plus détecter de tel cas peut être compliqué, on a vite fait d'oublier de créer partout où il est nécessaire ces versions.
La solution de mettre l'effectivité sur les liens me parait plus sûr car on applique l'effectivité de façon circonscrite au lieu de définir une solution générale et d'ensuite chercher à en limiter la portée.

Enfin, peut être que le mieux est de permettre les deux solutions qui ont chacune un intérêt selon l'aspect généraliste de substitution.

D'ailleurs le document "PDM enablers" dont Windchill est fortement inspiré semble retenir cette solution.

Pour ma part, dans notre modélisation, je dois avouer que j'hésite, d'un côté comme expliqué je trouve cela intéressant de pouvoir mettre l'effectivité sur les liens de substitution mais cela complexifie forcement un peu le modèle.



Ce que j’ai l’impression que tu veux et que l’on ne pourrait pas distinguer, c’est si , non pas ton Article est à plusieurs endroits dans ta BOM.
Mais plutôt un assemblage qui le contient. Et cet assemblage à plusieurs endroit dans la BOM.
Dans ce cas tu ne peux pas dire , un coup la substitution s’applique, et un autre coup elle ne s’applique pas.
 
Je suis d'accord avec toi. Mais le cas dont je parle est le cas expliqué plus haut.

Si c’est ça, à mon sens , tu n’es plus sur un problème de substitution, mais d’interchangeabilité.
Cela veut dire que dans un cas de ta BOM,  le même asm peut se monter (même si dedans tu as mis le substitut), et que dans l’autre cas il ne faut pas le monter si tu as utilisé le substitut.
Si appliquer une substitution casse l’interchangeabilité du père. On est carrément sur un cas où il aurait fallu distinguer les 2 ‘variantes’ du père.
Et si tu veux distinguer les 2 asm. C’est qu’ils auraient dû avoir 2 références différentes, et 2 compositions différentes.
 
 





<--  Date Index  --> <--  Thread Index  -->

Reply via email to:

Powered by MHonArc.

Copyright © 2006-2007, OW2 Consortium | contact | webmaster.