Diagramme de classe

Bonjour,

J'essaye de mettre en place un diagramme de classe pour une application de type médiathèque.

J'ai une classe abstraite Oeuvre, des classes qui héritent d'Oeuvre, à savoir Film, Album, JeuVideo, Peinture et d'autres. Et une classe BandeOriginale qui hérite de Oeuvre.

Je voudrais faire apparaitre 2 notions sur mon schéma :

- certaines oeuvres on hum comment dire, une durée. Par exemple, Film, Album ont une durée mais pas JeuVideo ni Peinture.

- certaines oeuvres peuvent avoir une BandeOriginale, par exemple Film, JeuVideo, mais pas Album ni Peinture.

Comment modéliser ces informations sachant qu'elles ne sont pas exclusives. Et ce, sans redondance de code aucune ?

Tu peux faire un diagramme de classe de cela, mais pour la redondance de code, ça va être plus compliqué. En gros, ce que tu veux faire c'est de l'héritage multiple. Mais cela n'est pas implémenté dans la plupart des langages.

Dans tous les cas, il me semble que ta classe Oeuvre est abstraite.

Avec l'héritage multiple, tu as comme classes de base Oeuvre, AvecBandeOriginale et AvecDurée.

Film hérite de Oeuvre, AvecBandeOriginale et AvecDurée.

Album hérite de Oeuvre et de AvecDurée.

etc.

Cela dit, tu peux simuler l'héritage multiple dans la plupart des langages avec la notion d'interface. Dans ce cas, tu as une classe de base Oeuvre, et deux interfaces IAvecBandeOriginale et IAvecDurée. Alors :

Film hérite de Oeuvre, et implémente IAvecBandeOriginale et IAvecDurée.

Album hérite de Oeuvre et implémente IAvecDurée.

Au niveau de l'implémentation, tu peux écrire une classe Oeuvre qui a des propriétés protégées BandeOriginale et Durée. Ensuite, dans les classes dérivées, tu fais appel aux propriétés protégées.

Vu de l'extérieur, cela sera comme si la classe Album n'avait pas de propriété BandeOriginale, puisqu'elle sera invisible. Cela utilise un tout petit peu de mémoire, mais c'est trois fois rien.

Après, si tu veux sauvegarder / charger ces données, c'est encore une autre histoire.

D'accord je vais utiliser l'héritage multiple, merci Pour l'instant je ne me soucie guère du langage je me concentre sur la conception.

J'ai un autre souci !!

J'ai donc mes classes Album et Chanson qui héritent d'Oeuvre qui est en effet abstraite (et Album est une composition de Chanson). De plus, Chanson hérite également de la classe abstraite AvecDuree qui a pour attribut -durée et pour méthode +getDuree. Mais je pense qu'Album est également une ¿uvre avec durée. Seulement,

- Soit je lui fait hériter également d'AvecDuree mais alors, je surcharge +getDuree pour que la durée soit calculée comme la somme des durées des chansons.

- Soit je lui fait hériter d'AvecDuree et je ne surcharge pas mais alors il y a redondance de données puisqu'au final la durée d'un album est bien la somme des durées de ses pistes.

- Soit je crée une méthode +getDuree dans Album tout simplement qui calculera la somme des durées des pistes. Mais alors j'ai l'impression que quelque chose est faux, j'ai une classe AvecDuree qui est sensée représenter les ¿uvres avec durée mais qui ne les représente pas toutes.

Quelle est la meilleure solution d'après vous ?

Si c'est pour un devoir d'école, l'héritage multiple risque de ne pas être accepté. Ils sont conservateurs, et puis comme on ne peut pas l'implémenter dans tous les langages. Par exemple en .Net et en Java on ne peut pas.

Mais bon, d'un point de vue théorique, y a pas de problème dans ce cas là. Dans d'autres cas cela peut être davantage problématique :

http://fr.wikipedia.org/wiki/H%C3%A9ritage_multiple

Pour l'album qui est une collection de chansons, la durée n'est pas une variable mais une propriété en lecture seule. Cela n'a pas de sens de changer la longueur d'un album sans changer les chansons, tu en conviendras. L'ambiguïté réside ici dans le faite que AvecDurée ne précise pas si c'est une durée calculée ou pas. Le plus simple à mon avis est de rajouter à l'album une fonction du genre getTempsTotal. D'ailleurs, il faudrait lui passer en paramètre le temps de silence entre les chansons.

J'ai fait comme ça, une fonction getTempsAlbum c'est ce qui me paraissait le plus logique. Et non ça n'est pas pour l'école mais pour un site web. En effet l'héritage multiple peut poser des problèmes mais avant de me porter sur la programmation j'aimerais déjà une description conceptuelle normalisée le plus possible, après on verra pour "dégrader" selon le langage. Au pire, dans mon cas, au lieu d'avoir une classe abstraite AvecBo qui partage un lien de cardinalité 1¿1 avec la classe Bo, j'aurais des liens directs de cardinalité 1¿0..1 entre chacune de mes classes qui héritent actuellement d'AvecBo et la classe Bo.

Ok

Autre question (j'en profite vu que t'as l'air de t'y connaître) : J'ai une classe Artiste et une classe Groupe, je voudrais modéliser la relation entre Artiste et Groupe comme suit :

- Un artiste peut appartenir à plusieurs groupes

- Un groupe peut évidemment comporter plusieurs artistes

- Il y a une date de début "d'adhésion" au groupe et de "fin d'adhésion" (les artistes peuvent quitter un groupe)

- Un membre de groupe a un rôle (par exemple chanteur, guitariste)

Au début j'avais créé une classe Membre héritée d'Artiste mais j'ai du mal a représenter la cardinalité *¿* entre Membre et Artiste. Alors j'ai plutot fait une association *¿* entre Artiste et Groupe avec une classe d'association Membre qui contient dateDebut, dateFin et Role. Qu'en penses-tu ?

Je ne suis pas sûr, faudrait que je révise UML. Mais ce dont tu parles est une association n-n. Après, je ne sais pas s'il faut représenter une classe d'association ou pas. Une association n-n est plus théorique que pratique.

Comme il ne s'agit pas d'une inclusion, ce n'est pas une simple clé étrangère. Si un Artiste appartenait à un seul groupe, il suffirait d'une association d'appartenance, 0..n - 0..1, équivalente à une clé étrangère. Je sais pas si tu comptes stocker cela dans une base de données, mais si c'est le cas, il te faudra une table ArtisteGroupe pour stocker l'association, ayant deux clés étrangères, une vers Groupe et une vers Artiste, et ayant comme clé primaire le couple des clés étrangères. Voilà pour le côté base de données. Au niveau programmation, par contre, tu peux stocker cette association où tu veux, à savoir :

- comme une liste de groupes dans chaque artiste

- comme une liste d'artistes dans chaque groupe

- comme une liste de ArtisteGroupe reflétant une table ArtisteGroupe

Après, il s'agit surtout d'une problématique d'indexation. Par exemple, si c'est la classe Artiste qui contient la liste des groupes, alors si on veut afficher les membres d'un groupe, il faut parcourir tous les artistes pour voir lesquels ont une référence vers le groupe en question. En gros, si on veut optimiser dans les deux sens, il faut deux index, et pour éviter d'avoir à parcourir les groupes ou les artistes, il faut plutôt une liste ArtisteGroupe.

Cela dit, si tu travailles en lecture seule à partir de la base de données, tu peux stocker la liste des artistes au niveau de la classe Groupe ET la liste des groupes au niveau de la classe Artiste. Mais si tu les modifies, tu perds l'intégrité, puisque mettons que tu enlèves un Artiste d'un groupe au niveau de la classe Groupe, au niveau de la classe Artiste, il y aura toujours la référence vers le groupe en question. Tu vois un peu le désordre possible.

Pour éviter les confusions, le plus simple est d'avoir une classe ArtisteGroupe, et alors tu as les relations suivantes :

[Artiste] 0..n - 1 [ArtisteGroupe] 1 - 0..n [Groupe]

éa fait un peu bizarre parce que l'association est à l'extérieur des entités.

Salut,

Je me suis pas vraiment penché sur ton pb, mais ce que je te conseille c'est de jetter un coup d'oeil

à ce site http://uml.free.fr ce qui te permettra de réviser un peu tout ces concepts.

Ensuite pour effectuer ta modélisation tu as le logiciel argouml qui est pas mal et open source.

bon courage

J'oubliai, sur le site d'uml tu as le liens "cours" tout en haut de la page.