Salut j'ai un probleme pour modeliser la gestion d'un historique dans le diagramme des classes.
 
C'est pour la gestion d'une bibliotheque, j'ai une classe abstraite Adherent et une classe Livre:
 
Adherent(0..1)________________________(0..3)Livre  /* Le gars peut avoir que 3 bouquins */
                        |
                        |
                        |
                        |
                    Emprunt {classe d'association}
 
Je voudrais modeliser le fait qu'on puisse gerer un historique des emprunts pour un adhérent spécifique, un exemplaire de livre ou un livre. J'ai dabord pensé a faire un attribut "de classe" (static quoi) de la classe Emprunt (de type BD ??) et de faire des methodes statiques "getHistorique()" dans les classes Adherent, Livre et Exemplaire ... le but est de pourvoir simplement faire Livre.getHistorique().
 
Faut il preciser l'existence d'un attribut historique ou pas ?  
Comment dire que a chaque instance d'emprunt on enregistre dans l'historique le nom de l'adherent et le bouquin qu'il a pris ?
Ne serait il pas mieux de creer une classe du genre Historique (une espece de BD quoi) pour plus d'abstraction ???
 
Comment on fait dans ces cas la generalement ??
 
Aidez moi svp  

Salut,
Je n'ai jamais fait face à ce problème, mais je pencherais pour la solution à la sauce DB, avec une classe Historique. Je ne le mettrais pas en attribut de la classe Livre, car c'est aussi un attribut de la classe Adhérent puisque ça le concerne aussi.
Pour le gérer, Historique devrait peut-être être un singleton et fournir le service de gestion d'emprunt ?

Ok, merci de ton avis.
 
En supposant que j'ai une classe Historique, que mettre dedans comme attributs et methodes ... je vois pas trop Le but etant de rester suffisament abstrait pour laisser libre choix à l'implementation non ?
 
Ensuite est-ce qu'il serait pertinent de mettre des methodes getHistorique() directement dans les classes Livre et Adherent ?
 
Et finalement comment lier par exemple la classe Livre (ou meme Emprunt) à la classe Historique ? une aggregation toute simple suffirait elle ??

Voilà un semblant de proposition :
 

 
Transposé en cardinalité, ça donnerait ça:
 

 
Pour la gestion des erreurs, tu devrais définir tes propres types.
 
Maintenant, je vais peut-être me faire hacher menu par les guru de la modélisation objet (taper pas trop fort hein)...
 
Edit: La classe EmpruntEditable devrait sans doute être une déclaration interne à Historique pour empécher l'accès aux autres classes ?
 
Edit 2: J'ai (stupidement) oublié la possibilité de l'interface. Avec une classe Emprunt qui regrouperait Emprunt et EmpruntEditable, et l'interface iEmprunt qui ne contiendrait que les getters de Emprunt et qui serait retourné par Historique::getHistorique*()...

Ok merci
 
" +setIDLivre(idL : int) " A quoi ca sert de mettre à jour l'id du Livre emprunté ? (une fois qu'on la sauvegardé ... quoi)
 
Est-ce que une fois que l'instance d'un Livre a disparu on peut toujours recuperer des infos dessus quelque part ???
 
" -emprunt : liste d'EmpruntEditable " => Le fait de preciser la structure de donnée ça ne s'eloignerai pas de la politique de UML qui est de laisser libre choix en se qui concerne l'implementation ? Est-ce suffisament abstrait pour de l'UML ? Tu voudrais simuler la plus part des requetes d'une BD ?
 
J'ai pas mal polemiqué aujourd'hui avec mes camarades du projet et finalement on est arrivé à la conclusion (ou plutot question) suivante :  
 
Un historique est-ce simplement la savegarde de toutes les instances de la classe Emprunt ou une sauvegarde de textuelle (ou une autre forme quelquonque) des emprunts effectués ?  
 
Dans le premier cas, sachant que la classe Emprunt est une classe d'association entre Livre et Adherent si on supprime l'un des deux element du couple (Livre, Adherent) l'instance  
d'Emprunt adequate devrais dispraitre aussi je pense.
 
Je pense que par le terme "historique" on sous entend que l'on voudrais avoir des infos sur un bouquin qui n'existe plus dans le Bibliotheque (ca parrait bizzare mais c'est logique). Si quelqu'un a un contre-argument ...
 
 
Et derniere question, tu m'a conseiller de faire de Historique un "Singleton" (une instance d'un objet qui existe une et une seule fois durant le prog), est-ce que le stereotype <<Application>> est un "Singleton" ?

Y'a vraiment pas de quoi. On verra quand tu auras un modèle valide
 

J'ai mis ça un peu bétement j'ai plutôt essayé de faire attention à l'historique, c'est vrai que ça a plus sa place dans le constructeur, sauf si tu veux que ce soit un auto_increment auquel cas l'ID ne serait pas définissable par l'utilisateur... Et puis je ferais bien la différence entre id et référence (par exemple, j'ai vu dans pas mal de biblio quelques lettres du type de livre (SF, LITT, ...) suivi des 3 premieres lettres du nom de l'auteur, et ensuite l'identifiant. Enfin, a toi de voir quoi...
 

Tout dépend de ce que tu veux dire par "instance" et "disparu". Si l'objet n'existe plus dans le système alors non, on ne peut plus accéder à aucune de ses informations. Mais si par disparu tu entends n'a pas été rendu ou en gros a disparu de la bibliothèque, alors tu peux faire un attribut (ex: -dispo : bool). De cette façon tu donne un moyen de savoir quel sont les livres que la bibliothèque posséde, y compris ceux empruntés, et ceux qui ne sont plus du tout disponible, tout en pouvant accéder à leurs informations et, plus important, leur historique d'emprunts.
 

Tu as raison puisque les cardinalités sont là pour ça... Comme tu vois je suis aussi loin d'être un pro de l'UML mais ça aide bien de pouvoir échanger des idées...
 

A toi de voir les besoins du système défini dans ton cahier des charges... Mais oui c'est un peu l'idée.
 

Ca ne parait pas bizarre. Le gérant de la bibliothèque serait content de savoir les types de bouquins les plus empruntés (même s'ils ne sont plus disponibles au sens que j'ai donné plus haut) avant de réinvestir dans d'autres livres. J'ai eu l'occasion de développer une appli de gestion de prêt il y a quelques temps, et c'est là que j'ai compris qu'une information ne doit pas disparaître du système, mais plutôt être rendue inaccessible de la gestion actuelle. Pour transposer ça à la gestion d'une bibliothèque, il ne faut pas stocker les adhérents inscrits actuellement, ni les livres disponibles actuellement, mais plutôt les adhérents qui sont et ont été inscrits ainsi que les livres qui sont ou ont été disponibles. Il ne faut pas avoir le point de vue "La bibliothèque possède..." mais "La bibliothèque possède ou a possédée...".
 

Oublie le singleton, c'est sans doute la pire idée que j'ai pu te donner. Sinon <<Application>> n'a pas l'air de faire parti des stéréotypes prédéfinis par UML, donc tu peux en faire ce que tu veux, mais vu son nom, je dirais que ça irait avec la classe servant de point d'entrée au système, Bibliothèque par exemple... Et puis tu peux créer tes propres stéréotypes du moment qu'ils sont documentés, peu nombreux (pour la lisibité future).
La seule chose qui m'ait fait envisager le singleton, c'est que l'historique soit accessible à partir de toutes les classes. Mais il y a de forte chance que ça n'ait pas à s'appliquer ici et que ce soit une erreur de conception.

Merci pour ces precieux conseils !
 
Voila une formalisation mais j'ai un souci avec le fait que la bibliotequaire puisse passer des commandes (et donc consulter  des catalogues) sur Internet ... enfin c'est plus voyant sur le schema sinon pour l'Historique j'ai fait le plus bete possible pour le moment (c'est dur de se mettre d'accord avec les 2 autres energumens )
 
http://img140.echo.cx/my.php?image [...] ses8kf.png

Avec la remarque que tu as fait précédemment, je serais d'avis que Historique::emprunts disparaisse puisqu'il est représenté par ton association 1..*.
 
J'ai un peu de mal à comprendre ce que tu veux dire par la bibliotequaire puisse passer des commandes (et donc consulter  des catalogues) sur Internet .
Si je saisis bien, il te faudrait créer une classe Opérateur qui représenterait le/la bibliothéquaire, qui serait liée en 1..* à Bibliothèque. Un/une opérateur/trice serait capable de passer des commandes à partir d'un catalogue, lequel serait dispo sur intranet et/ou internet.
La relation que j'imagine serait du genre:

 
Si j'ai mal compris, explicite un peu plus...
Et, sinon qu'est ce qu'en dise tes potes ?

A mon avis la bibliotecaire, qui est donc un acteur (si on se projete dans le diag des cas d'utilisations) peut interagir avec l'application grace au methodes de cette application. Genre si elle veut ajouter un Adherent elle lance la methode ajouterAdherent() qui elle verifie par exemple qu'il n'y a pas deja un adherent avec cet identifiant et si c'est le cas alors crée un nouveau Adherent.
(dans le diag des sequence j'ai ce genre de truc ... mais le hic c'est que Poseidon n'a pas l'air de gerer des acteurs dans les diag de sequence )
 
Donc de la meme maniere, pour commander des ouvrages elle devrait pouvoir lancer simplement commanderOuvrage(..) je pense. (ou consulter un catalogue grace a une sortie vers Internet ou un truc dans le style, j'ai peur de dire Interface Internet)
 
Pour ce qui est de ta proposition sur l'operateur j'avais aussi pensé à faire un truc dans ce style mais plus dans le sens "Connexion Internet" ou "Session", justement pour exprimer le fait qu'elle accede à un Catalogue qui n'est pas dans le systeme proprement dit.
 
Voila d'ailleurs une question, doit on expliciter le fait qu'il peut y avoir des choses qu'on recupere de l'exterieur "grace à"   ... bref specifier l'emplacement des données ?
 
Sinon mes potes ont tous un avis assez different en ce qui concerne la gestion de l'historique, y en a un qui est partisan d'une simple methode "historiser(e : Emprunt)" dans la classe Emprunt et l'autre penche vers la variable "-dispo : boolean" dans Ouvrage (et donc pareil pour un Adherent -actuellementInscrit). Mais le probleme avec les variables c'est SI on a un bouquin avec "dispo" à FAUX alors c'est que le Livre n'est plus present ... et si on en rachete un avec le meme nom ?  
 
L'UML c'est bien mais j'ai l'impression de me noyer defois
 
EDIT : Ah mais pour les variables c'est pas un souci enfait avec ton systeme de ID qui s'auto incremente à la creation et puis meme avec la date c'est gerable ... donc les variables sont en fait une bonne idée je pense.

Ok... Dans la notion de commande, j'envisageais aussi la traçabilité (qui a passé la commande), d'où la classe Opérateur. La méthode commanderOuvrage(..) n'aurait-elle pas plus sa place dans la classe Catalogue ? Car c'est une action qui est réalisable uniquement à partir d'un catalogue, non ?
A part ça, qu'est-ce qu'une commande ? Une liste d'éléments, choisis dans un catalogue, demandés à une date donnée à l'éditeur du catalogue. Pour définir un élément de commande, il faut trouver un moyen d'identifier chaque produit indépendamment de son origine pour faciliter la gestion de cette partie du sysème. Si tu fais une bibliothèque (et pas une médiathèque, donc rien d'autre que des livres), tu peux utiliser le numéro ISBN qui rempli parfaitement la définition précédente. Tu peux lui associer un titre et un prix. La commande sera associée à un Cataloue et donc à son origine/éditeur/livreur...
Dernière chose pour la commande, on y retrouve aussi un historique, je suppose.
 

Spécifier l'emplacement des données appartient peut-être à l'implémentation et pas à l'UML. Cependant, tu peux peut-être faire un package "Externe" pour représenter ceci ?
 

A qui le dis-tu ?! Il m'arrive de relire plusieurs fois le même chapitre avant de rééllement le comprendre !! Mais le jeu en vaut tellement la chandelle