conception UML

[cedric125]

Bonjour,
j'ai un diagramme UML incomplet et je ne sais pas comment le modifier de tel sorte à avoir ce que je veux.
Un livre peut être écrit par plusieurs auteurs, certains d'entre eux sont desimples contributeurs, d'autres sont considérés comme des auteurs principaux. Il n'y a pas de différences majeures entre ces deux rôles,seulement dans l'ordre d'apparition sur la couverture du livre. Un auteurpeut être contributeur dans un livre et auteur principal dans un autre.
- Chaque livre peut avoir un ou plusieurs Genres (Thriller, Romance,Comédie,...).
-----

[umfred]

tu auras des tables intermédiaires entre tes tables actuelles:
1.une table entre book et author qui associe un livre avec ces auteurs et éventuellement leur rôle =>un champ id_book, un champ id_author, un champ role (ou id_role)
2.de la même façon, une table genre où tu listes les genres et une table entre cette table et book pour faire l'association=> un champ book_id et un champ genre_id
Il pourra y avoir dans ces tables plusieurs lignes avec le même book_id avec en face différentes valeurs pour les autres champs

[cedric125]

Bonjour, par champ vous voulez dire ATTRIBUT?

[umfred]

oui, c'est la même chose

[A voir en vidéo sur Futura]

[cedric125]

Comment je pourrai nommé ces tables alors ? parce que c'est quand même des attributs spécifique à un book et un auteur ( je comprend pas pourquoi la duplication)

[umfred]

En terme de relation c'est du n,n sinon (un livre peut avoir plusieurs auteurs, un auteur peut écrire plusieurs livres, un auteur peut avoir plusieurs roles, un role peut être associer à plusieurs auteurs).
Il n'y a pas duplication puisque les lignes seront différentes, et on utilise que les id pour faire les associations.
(je n'utilise peut-être pas le bon vocabulaire UML, mais plutôt MCD, c'est vrai)
Pour le nommage, je ne sais pas si il y a une norme, mais j'utilise quelque chose du genre Asso_Book_Author par exemple.

[cedric125]

D'accord merci j'en prendrai compte!
supposons que je veux faire deux types de clients les clients réguliers et les clients premium.Un client régulier peut être promu en client premium si le nombre de livres
empruntés dépasse 50.
- Les clients premium peuvent bénéficier de 20% de réduction lorsque le nombre de livres empruntés dépasse 3 à la fois est ce que je peux faire un héritage comme ci-joint

[umfred]

Je pense que je mettrai un attribut EstPremium en booleen (vrai/faux) et le reste serait géré au niveau applicatif.

[cedric125]

ça marche mercii !

[pm42]

Je pense que je mettrai un attribut EstPremium en booleen (vrai/faux) et le reste serait géré au niveau applicatif.

Je confirme : l'héritage dans ce cas là est une très mauvaise idée. On se retrouve avec un objet qui doit changer de type quand le client est promu premium ce qui implique de le copier complètement tout en gardant le même identifiant ce qui pose souvent des problèmes.

Et si par hasard on stocke en base (ou qu'on garde des liens directs en mémoire d'ailleurs), cela complique sérieusement les choses.

De nos jours, on conseille d'ailleurs d'éviter l'héritage de classes concrètes parce que cela complique l'évolution des programmes.

[umfred]

Je compléterais que les valeurs que tu donnes (premium au bout de 50 livres empruntés, 20% de réduc si 3 livres empruntés en même temps) ça devrait être des valeurs modifiables au niveau de l'applicatif et sauvegardés dans un fichier de paramètres.
Et en réfléchissant bien, une table (entité) Statut_Client pour le futur si il est envisageable que le client puisse avoir d'autres statuts (normal, premium, super premium, mega premium, ...) et dans ce cas là, EstPremium devient Statut_id qui prend l'id correspondant de la table Statut_Client
Edit: et on peut revenir du coup sur ce que je dit au début de ce poste en ajoutant à cette entité 2 attributs, livre_mini et reduction pour chaque statut

[cedric125]

conseille d'ailleurs d'éviter l'héritage de classes concrètes parce que cela complique l'évolution des programmes

j'ai un peu de mal avec les héritages, que voulez vous dire par "classes contrètes" ,pour pouvoir employer l'héritage il faut être certain qu'il n'y ai pas en quelque sorte une relation de composition entre les deux?

[pm42]

j'ai un peu de mal avec les héritages, que voulez vous dire par "classes contrètes"

Une classe est concrète si on peut créer un objet de ce type. Les langages implémentent d'autres concepts comme les classes abstraites (ou incomplètes, il faut en créer une version dérivée pour pouvoir l'utiliser) ou les interfaces.
Si vous commencez en objet, vous pouvez oublier ce que j'ai dit et ne pas rentrer dans de niveau de détail.
Mais juste retenir pour le futur que l'héritage est un beau concept en théorie mais qu'en pratique, il ne faut pas en abuser.

pour pouvoir employer l'héritage il faut être certain qu'il n'y ai pas en quelque sorte une relation de composition entre les deux?

Pour savoir si il y a héritage par exemple entre A et B, la question est : est ce que B est un A ?
Par exemple, une voiture peut hériter de véhicule. Et cabriolet de voiture.

Dans votre cas, on peut dire "un client premium" est "un client normal" et donc faire de l'héritage mais si demain on a par exemple des clients premium et des clients "qui payent avec notre solution de crédit à nous" et qu'on peut avoir n'importe quelle combinaison, l'héritage ne fonctionnera pas bien : on devrait créer toutes les classes correspondant aux combinaisons.