Discussion :

[Totomanator]

Bonjour.

Je débute sur les méthodes d'analyse sur Merise et je souhaiterais vous demander votre aide sur un cas particulier :

Je travaille actuellement sur un modèle concernant une gestion de parc ULM.
Sachant qu'un ulm pendulaire est caractérisé par :
1- Son chariot (le cockpit pour simplifier)
2- Son moteur
3- Son aile
et que les 3 "pièces" sont remplacable relativement souvent (un peu à la manière d'un parc info) et que je dois pouvoir garder l'historique des configurations ( du type, tel jour : Moteur 1, aile 4 et chariot 2 )

Comment dois-je modéliser cette situation ?
Un Héritage ayant comme père une entité machine ayant comme fils exclus chariot, moteur et aile ?
Ou plutôt un essemble d'entité - association du genre "Est composé de" ?

Petite complication, je dois en plus pouvoir gérer l'historique des opérations de maintenance sur chaque matériel.


Je vous donne un apercu de mon MCD pour illustrer la situation : http://sonoboss.free.fr/Download/mcdULM.JPG
étant bien entendu que la partie qui nous intéresse est surtout la partie gauche...

Personellement, je cale et je vous serais très reconaissant si vous pouviez m'aiguiller...

D'avance merci!

[azertyman]

[Nanci]

La solution proposée est globalement correcte.
Le seul petit bémol est le suivant
Une pièce qui a été montée puis remplacée sur un appareil (donc une occurence de se composer) , puis ultérieurement remontée sur ce même appareil.
C'est la même occurrence de composer !

La solution serait de modéliser chaque "configuration" de l'appareil; mais c'est plus lourd à gérer.

[Totomanator]

Merci de vos réponses rapides.

@azertyman: Cette solution me semble correcte mis à part la notion de doublon sur les remplacements de pièces.


@Nanci:

La solution serait de modéliser chaque "configuration" de l'appareil; mais c'est plus lourd à gérer.

Cela s'approcherait donc de ma modélisation non ?
Un héritage ne simplifirait-il pas la notion de composition ?

[azertyman]

Une pièce qui a été montée puis remplacée sur un appareil

J'ai fait ULM -0,n-(se composer[debut, fin])-0,n-PIECE

ce qui devient en MLD :SE COMPOSER (#NumULM, #NumPiece, Debut, fin)

Donc on associe la piece et le numero d'ulm AVEC les dates.

Allez un exemple en table

NumULM | NumPiece | Debut | Fin
-----------------------------------------
45 | 445 | 12jan | 13 fev
46 | 445 | 14 fev | 17 Mar
45 | 445 | 18 Mar | 15 Avr

On sait à quel moment une piece est sur un appareil (ou aucun)

[Totomanator]

Oui je vois où tu veux en venir mais, en fait, il n'y a pas vraiment de moyen d'identifier un ULM par un ID... Sachant qu'un ULM est un assemblage d'un chariot, d'un moteur et d'une aile à l'exclusion de toute autre chose, comment définir un ULM si on utilise seulement la notion de Pièce sachant que il n'y aurai pas à proprement parler de facon d'identifier un ULM ?
Car si on change une Aile par exemple, l'ULM n'est plus le même car un de ses 3 identifiants à changé...

J'ai du écarter cette solution que j'avais aussi mis en place car elle ne remplissait pas toutes les règles de gestion...

[azertyman]

mince j'ai considéré l'ulm comme par exemple une voiture, ou y'a la carcasse de fixe et des éléments comme les portes qui changent.

Sinon on ne pourrait-on pas considérer l'id_ulm comme la place dans le garage ?

[Totomanator]

Ah si c'était si simple!

Malheuresement... Non. Pas de place spécifiée pour la simple raison c'est que c'est un peu comme un parc à vélo! (oui je sais ca fait cher les vélos! ) où le dernier arrivé est le dernier sortit ( 2 portes dans le hangar, après un vol => examen Post vol + complet que prè vol (non compris dans le modèle (Ouf!) donc impossible de redécoller dans la foulée)

[azertyman]

a la limite c'est plus simple

[Totomanator]

J'ai peur de la perte du sens de la notion d'ULM... Je m'explique : en utilisant cette méthode, on va se retrouver avec qqc comme 20 ou 30 ulms différents alors que physiquement, il n'y en aura que 8... Du point de vue purement Access, je pensais à une table du genre
ULM(#IdAile, #IdChariot,#IdMoteur,...)

Mais je me demande si finalement, je ne vais pas devoir fausser les règles de gestion et créer un IdUlm... Tant pis.

Donc à ce moment là, je me retrouverais avec qqc approchant de ton 1er MCD mis à part le fait que je ne vois pas l'intérêt de relier réparation et ULM étant donné que l'on peut y accéder par rapport aux pièces.
Et autre question, sur PowerAMC, on ne peut pas passer les propriétés des associations en tant qu'identifiant, donc comment faire passer cette notion ?




Pourrais tu me dire quel logiciel tu utilises pour modéliser tes MCD ?
Personellement, j'utilise Power AMC Données 6 et il est incapable de générer des Db sous Access 2003...

[azertyman]

Actuellement on a :
ULM (NumULM, DebutULM, FinULM)
PIECE (NumPiece)

Dans le MCD et dans le MLD ça reste pareil, autrment dit tu auras (si tu fais ce que je te dis ), une table avec les numéros des ULM, et un autre avec les numéros des pièces. Au passages qu'il y ai 20 ou 400 ulm référencés dans ta table ULM, ça ne change rien au fait que tu n'en ai que 8 en meme temps : vu que l'on précise les dates de vie de l'ULM, on sait quand telles pieces étaient ensemble pour former tel ulm, on peut donc déduire (grace aux dates) les ULM ayant été "monté" en meme temps.

Au passage (se composer) devient une table.
(un pti coup de MLD ) SE_COMPOSER (#NumULM, #NumPiece)

[Totomanator]

Désolé pour le retard...

Oki je vois où tu veux en venir... Je vais plancher dessus.


Thx et à plus!