Bonjour,  
 
Je viens de faire la première version de mon diagramme de classe et je pense qu'il est facilement améliorable mais je vois pas trop comment.
 
*sujet : c'est un péage d'autoroute, chaque voie de péage  à un pc et je dois récupérer des informations sur ces pc en fonctions de leur type.
 
*explication des tables :  
 
- liste_machine => liste de toutes les machines dont j'utiliserais le nom pour aller chercher des informations dessus (type = serveur de different type, pc bureautique, voie de péage)
 
- crash => stock les informations sur le bon allumage de la machine (demarrage normal, arret normal, planté, relancé electriquement..)
 
- config_machine => récupère des données sur toutes les machines
 
- psp_ope => parmi la liste des machines se trouve des serveurs nommés ope ou psp et seulement pour ces serveurs je vais chercher des versions de logiciels
 
- voie_entree => c'est une voie ou on ne paye pas, c'est lorsqu'on prend un ticket et on paye plus tard dès qu'on sort de l'autoroute. Je récupère des infos spécifiques au voie.
 
- voie _sortie => c'est une voie normale ou l'on paye dès qu'on y passe, je récupère à peut près les mêmes infos que voie_entree + d'autres infos.
 
Merci de me donner votre point de vue et les défauts que vous avez remarqué car je suis une brelle au niveau de tout ce qui est diagramme
 
 

ouch
 
Pas moyen de diminuer la taille de voie_sortie ?  
 
Pas en virant des attributs, mais en créant d'autres classes, dont les instances seraient des attributs de voie_sortie.

je vais faire ça ouai déjà, tres bonne idée merci!!

bah déjà tout les AC_xxx, DRT_xx etc , ça sent bien les trucs encapsulables à part.

et la c'est comment?  
 

V3
 

une machine est composée d'une psp, d'une voie_entrée, d'une voie_sortie ?
 
aurais tu moyen de mettre les noms des relations entre tes classes ?

Quitte à faire de l'UML, autant le faire correctement. Les symboles de relations sont incorrects, symbole de composition douteux, les relations ne sont pas nommées, il n'y a pas de multiplicités. (Toutes les relations doivent être nommées et doivent avoir une multiplicité des deux cotés de la relation.)
 
Ca sent un peu le diagramme fourre-tout.
Ecris une spec fonctionnelle, même brève, histoire de te mettre les idées en place.
Ainsi, en fonction de la spec fonctionnelle, on peut vouloir avoir l'adresse IP et le numéro de série dans la machine et non la config. Tout dépend de ce que fonctionnellement, on appelle configuration. Si c'est une "configuration standard", ta table config va contenir une liste de "config standards", à savoir tel modèle de machine vient avec tel OS, tel DD et tel software grâce à telle version Ghost. Dans ce cas, l'IP et le numéro de série n'ont rien à faire là.
De même, dans machine, tu peux ajouter un champs type_serveur qui prendra 2 valeurs: psp, ope, ou bien restera vide (null) si la machine n'est pas un serveur.
En tous les cas, le lien entre ces tables et machine n'est pas le même que celui entre voies et machine.
 
Les voies entree et voies sortie sont des voies, donc une table "voie" dont dérivent les deux autres ne serait pas de trop. (Après, l'implémentation de la dérivation dépend de la base et de l'ORM, avec Oracle et Postgres, c'est possible si le mapping le permet, avec d'autres, rien n'est moins sûr. La plupart du temps, on se contente d'une table supplémentaire.)
La relation entre voie-sortie et carte_acceptee est un materiel de paiement. A voir si une table materiel_paiement, contenant type de machine, numéro de série, etc, ne serait pas utile. Encore une fois, tout dépend du contour fonctionnel.
 
edit: si ma table materiel_paiement, c'est ta table equipt_physique, le type de carte acceptée n'est pas lié à cette table ?
 
Enfin dans carte_acceptee, tu mets des valeurs d'énumérations, j'ai l'impression (genre AmEx, Elf, Esso, Shell). De même dans equip_physique (LMP_xxx) ?  
Les énumérés doivent être définis dans des types créés pour l'occasion (si la base le permet. Oracle et Postgres par ex.), ou mis dans des tables à part. Les champs amex, shell, esso, etc, doivent être remplacés type_carte (type_carte) et enseigne_station. Souviens-toi que ces énumérés ont de bonnes chances d'apparaitre à un moment ou à un autre dans une liste déroulante ou sous forme de boutons radio dans une IHM. Donc ça vaut le coup de les mettre dans une entité à part.
 
Il y a encore du travail, mais tu es sur la bonne voie.
De la lecture ici: http://forum.hardware.fr/hfr/Progr [...] 3970_1.htm

Merci pour ton analyse, c'est simpa de m'aider  
 
Tout d'abord je travaille sur une base MySQL
 
- Pour la relation entre machine et psp, ope, voie_entree, voie_sortie je voulais faire une relation d'héritage.
 
- j'ai suivi ton conseil pour l'adresseIP et le numSerie car je trouve ça bien.
 
- description des machines : * les psp sont des serveurs mais ils peuvent aussi avoir en plus le même logiciel qu'un ope,
                                       * les ope sont des machines dédiées à un logiciel(pas un serveur),
                                       * les voie_entree et voie_sortie sont des machines spécifique aux voies de péage (type CVR),
                                       * les pc_bureau sont les pc utilisés dans les bureaux.
 
- je pense que je ne peux donc pas regrouper psp et ope malgré la ressemblance entre les attributs.
 
- j'aurais aimé créer une table voie qui se sépare après en 2 mais je vois pas trop ce que je peux mettre dans cette table voie vu que tout les attributs présent dans voie_entree sont dans voie_sortie.
 
- "carte accepté" c'est la liste des cartes qui sont acceptées par la borne de péage afin de payer, car par exemple sur une voie une carte peut être acceptée alors que sur la voie d'à côté non, donc à chaque fois je créer une ligne de boolean spécifique à une seule voie. J'aurais aimé faire plus court mais je ne sais comment.
 
- equiptPhysique c'est des informations (versions,etc) concernant seulement les voies de sortie
 
- etat_demarrage est une table qui enregistre les crash et les bons redemarrage seulement des voies de péage (voie_entree et voie_sortie), je l'ai temporairement enlever de mon nouveau diagramme.
 
Les verbes sont un peu bidon c'est juste pour donner un sens (jamais 2 verbes identiques).
 

 
 
 
 
 
 

qu'est ce que tu entends par "VS_TC_ASSOC",  
 
parce que si je met seulement comme attributs "fournisseurs"(esso,elf,etc) et statut (accepté ou pas) ben je peux pas l'utiliser pour plusieurs voies,  
enfin je crois    
 
merci  

Ok j'ai compris ce que tu voulais dire, c'est vrai que c'est pas mal ça allège un peu ma table merci.
 
V6 =>

Sinon au niveau de mon héritage :
 
                                              machine
                                                   |
                                      pcBur  ope  psp  ve  vs
 
tu penses que c'est cohérent?

je suis pas tout a fait sur de moi, et une confirmation serait necessaire, mais si tu as déjà un attribut id dans machine, est il vraiment utile d'avoir un autre attribut id dans chacun des classes dérivées ?
 
En ne le mettant pas, cela permettrait d'alléger les classes dérivées (de meme avec tous les attributs qui sont présents partout)

je ne peux pas parce que par exemple dans mes tables je peux sauvegarder plusieurs enregistrements de configuration pour une même machine, seules les tables machine, utilisateur et gare ne changent pas automatiquement.

si tu pouvais reposter la derniere version image de ton diagramme
y'a eu trop de connections ^^