Discussion :

[Sereine]

Bonjour à tous.

Aujourd'hui je suis confronté à un problème à mon boulot. Je suis sur un projet où je dois gerer l'administration d'un catalogue de panne en php. Tout en permettant la gestion individuelle de chaque partie du catalogue.

Ce catalogue est sencé regroupé ces informations de manière hierarchisée:

Un catalogue de panne possède un type (commun ou spécifique), une famille, une technologie associé à cette famille (une famille possède donc une à plusieurs techno), une anomalie associé à une famille et une techno (donc une famille/techno peuvent avoir plusieurs anomalies. Et enfin, une précision associé à une anomalie. (une anomalie pourra posséder une a plusieurs précisions.

Etant pas très doué en uml, j'ai commencé directement en m'attaquant à la base de donnée que je déploie comme ceci:



Sauf que mon patron voudrais que je fasse le diagramme d'abord et que je détermine la bdd après. Chose pas du tout naturel pour moi.

Alors j'ai essayer de me dépatouillé, mais je n'y arrive pas ... malgré les tuto que je comprend, mais qui sont bien souvent, pas/peu adapté à ce que je souhaite faire.

[Sereine]

Personne pour vérifier si je me gourre completement de voix? Ou quelqu'un qui pourrait traduire le diagramme de classe que j'ai fait, voir si ça correspond à ce que je cherchais a faire?

[Sereine]

"Forum d'entraide sur les Diagrammes de Classes', j'ai du me tromper de section, ou bien? ..

[tonton16]

Bonjour,

Ce diagramme de classes n'est pas très objet.

Les attributs de la classe "Catalogue" avec un type Integer ne sont pas très logiques.

S'il y a un lien entre le catalogue et les autres classes, on fait une association. Cette association se traduit par un attribut (qu'il ne faut pas mentionner).

Personnellement, j'évite les classes d'association.

J'ai mis en pièce jointe un diagramme qui pourrait correspondre aux règles de gestion indiquées, même si je ne suis pas sur que ce soit la solution idéale (vite fait).

Le diagramme de classes ne doit pas refléter le modèle de la base de données. Si on fait un diagramme de classes, on pense objets et on pense à la persistance après.

Cordialement.

[Sereine]

merci pour cette réponse. Mais dans ce cas alors j'ai rien compris. Et ça reste tout autant incompréhensible jpense qu'il me faudra une bonne formation pour y voir plus clair, parce que là ... c'est du charabia qui ne veut rien dire pour moi.

[tonton16]

Je ne voulais pas te décourager, au contraire, il faut persister.

Ce qu'il faut voir dans les associations entre classes, c'est que dans la classe Catalogue, tu auras des attributs "famille : Famille", "technologie : Technologie"...

Pour faire le lien avec un modèle de base de données, c'est un peu comme si la table "CATALOGUE" récupérait des clé des tables "FAMILLE", "TECHNOLOGIE" comme clé étrangères.

Les associations représentent ces attributs "importés".

Rien n'empêche de garder ta structure de table, il faudra juste faire attention lors de la persistance.