Discussion :

[Daneel78]

Je continue avec l'exo 3

Le système d'information qui doit être analysé est celui d'une agence de voyage spécialisée dans la réservation
d'hôtels pour les groupes. Ce système d'information concerne donc uniquement l'activité réservation de chambres d'hôtels.
Pour effectuer ses réservations, l'agence reçoit d'un groupe (simplement défini par son nom), un ensemble de bulletins
d'inscriptions standards comportant les indications suivantes :
- un numéro unique (chaque bulletin d'inscription pré-imprimé possède un numéro unique)
- la date de début et de fin de réservation d'hôtel
- la ville demandée
- le type de la chambre demandée (individuelle ou double)
- la catégorie de la chambre (confort ou luxe)
- le nom, prénom, adresse du participant, ainsi que le nom, prénom et adresse du deuxième participant s'il
s'agit d'une chambre double.
A chaque réception d'un ensemble de bulletins d'inscriptions, un nouveau groupe est créé.
L'agence effectue ses réservations en fonction des indications portées sur les bulletins d'inscriptions. On considère
que les souhaits des participants peuvent toujours êtres satisfaits (type de chambre, catégorie de chambre, ville choisie, date de
début et de fin demandée).
Pour cela l'agence crée un bulletin de réservation par bulletin d'inscription. Ce bulletin de réservation reprend toutes
les indications déjà portées sur le bulletin d'inscription, et précise en plus, le nom et l'adresse de l'hôtel et le numéro de la
chambre réservée, ainsi que le prix, calculé en fonction des tarifs par catégorie et par type de chambre. Ces tarifs sont fournis
par les hôtels avec lesquels travaille l'agence, et sont, à priori, connus. Tous les tarifs sont à la nuit. Pour calculer le prix,
l'agence multiplie donc le tarif de la chambre par le nombre de nuits (date de fin - date début).
Ensuite, l'agence édite (procédure "par lot") tous les bulletins de réservations du groupe et les expédie à celui-ci. A la
réception du règlement global pour le groupe (un seul règlement pour l'ensemble des réservations du groupe), elle enregistre ce
règlement, avec indication du numéro de chèque, ou du numéro de carte bancaire et de la date d'expiration de la carte, suivant
le type de règlement.
Questions :
(a) Modélisation des objets du système d'information réservation de chambres d'hôtels.
(b) Modélisez les cas d'utilisation et leurs scenarii.

Voici le diagramme de CLasse.
Comment fait on d'ailleur pour creer un package? j'ai pas réussis.
Quelle type pour une date? je n'ai pas trouver le type date dans les attributs?
Sinon, y a t'il des erreurs? Je trouve que j'ai progressé non?



Par contre pour le diagramme de cas d'utilisation, c'est toujours aussi flou, je ne vois pas l’intérêt car je ne trouve qu'un seul acteur, qui sont les autres??
Comprenez vous la dernière question? je ne sais pas ce que veux dire de modéliser les scenarii???

http://img51.imageshack.us/img51/427...eservation.png

[bruno_pages]

Comment fait on d'ailleur pour creer un package? j'ai pas réussis.

voulez dire "montrer un package dans un diagramme", et bien seuls les packages déjà existant peuvent être montrés, car je ne saurais pas ou les creer ç partir d'un diagramme, donc créé vos packages et vous pourrez les ajouter dans les diagrammes

Quelle type pour une date? je n'ai pas trouver le type date dans les attributs?

pourquoi pas ..; Date ?
vous n'êtes pas obligé d'utiliser des types déjà existant/pre-défini, donc tapez simplement directement "Date" pour le type de l'attribut (la chose est éditable, ce n'est pas qu'une liste déroulante, ici comme quasiment partout), ou évidemment créez une classe Date

Sinon, y a t'il des erreurs? Je trouve que j'ai progressé non?

hehe, manque d'opération, multiplicité, noms des rôles etc, regardez les 2 autres discussions et reprenez le diagramme

la relation entre Hotel et Chambre est mal dessinée ou il y a deux relations superposées, une chambre ne pouvant pas exister sans l'Hotel il faudrait utiliser une composition et non une simple agrégation (éditer la relation pour la changer)

je ne trouve qu'un seul acteur, qui sont les autres??

je ne pense pas qu'il y en ai d'autre

je ne sais pas ce que veux dire de modéliser les scenarii???

très certainement les diagrammes de séquence

[Daneel78]

Bonjour

pourquoi pas ..; Date ?
vous n'êtes pas obligé d'utiliser des types déjà existant/pre-défini, donc tapez simplement directement "Date" pour le type de l'attribut

Ah d'accord

hehe, manque d'opération, multiplicité, noms des rôles etc, regardez les 2 autres discussions et reprenez le diagramme

Bon tant pi
je vais le recommencer alors

la relation entre Hotel et Chambre est mal dessinée

Comment ca mal dessiné? vous voulez dire que c'est pas une agrégation??

une chambre ne pouvant pas exister sans l'Hotel il faudrait utiliser une composition et non une simple agrégation (éditer la relation pour la changer)

J'ai surement pas bien compris le cours mais une agrégation, c'est une composition non ? (j'ai pas souvenir du mot composition dans mon cours) je vais le relire..........

[bruno_pages]

Bonjour

Comment ca mal dessiné? vous voulez dire que c'est pas une agrégation??

la remarque est purement graphique, le losange est coupé par un trait et le point d'attache de la relation sur Chambre est visible ... comme si la relation allait de Hotel à Hotel avec un point de coupure placé sur Chambre (déplacer l'une des deux classes et vous vous rendrez mieux compte)

J'ai surement pas bien compris le cours mais une agrégation, c'est une composition non ?

c'est l'inverse, la composition est un cas particulier d'agrégation, c'est une agrégation par valeur

[Daneel78]

Bien revoyons donc le diagramme de classe en premier...
J'ai donc changé l'agrégation en composition, et il y avait effectivement une erreur de lien.
J'ai ajouté des méthodes mais en y réfléchissant, je trouve encore des points qui sont confus.
J'ai ajouté également un lien realisation (dans mes cours, les messages entre les classes [objets] sont affichés) est-ce bien la l'utilité de ce lien?
J'ai déplacé la liaison entre Hôtel et bulletininscription, vers Hotel et bulletinreservation car je pense que c'est cette classe (ou la méthode de cette classe) qui effectue la réservation.
La méthode "réservation" va donc renseigner tout les attribut des objets instance de bulletininscription et bulletinreservation et chercher les prix dans l'objet instance de la classe hôtel...
C'est la qu'une chose m'échappe, comment peut on vérifier si la chambre n'est pas déjà réservé?? ou doit se trouver cette info? la méthode réservation doit elle vérifier dans tout les objets déjà créé si la chambre en question est déjà réservé a cette date??
Je pense que cela devrait être dans la classe Hôtel? qu'en pensez vous?

[bruno_pages]

J'ai ajouté également un lien realisation (dans mes cours, les messages entre les classes [objets] sont affichés) est-ce bien la l'utilité de ce lien?

la réalisation entre classes est un cas particulier de généralisation, une classe hérite d'une autre classes mais réalise une interface

donc sont utilisation ici n'est pas correcte

peut être confondez-vous réalisation et dépendance car toutes les deux utilisent un trait pointillé ?

...Je pense que cela devrait être dans la classe Hôtel?

c'est effectivement la classe Hotel qui connait ses chambres (c'est un peu le pendant de la classe Bibliotheque de l'autre discussion)

mais attention, cependant à ne pas faire faire trop de chose au niveau d'une classe, par exemple si Hotel connait la liste des chambres et est peu au démarrage de tout c'est par exemple la classe Chambre qui gère le fait qu'une chambre est ou non libre. Les classes s'utilisent les unes les autres, mais chacune à un rôle propre

concernant l'héritage entre les deux classes bulletin, hériter ne veut pas dire "utilise", A hérite de B veut dire que A "est un" B même si certains comportements sont modifiés et d'autres ajoutés. Pensez-vous qu'un bulletin de réservation est un bulletin d'inscription ? Il faut que vous alliez plus loin que les seuls attributs, pensez comportement/exécution et non seulement mémorisation. Une main et une jambe ont des os et des muscles (attributs/relations), mais leur but et raison d'être c'est leur comportement marcher/saisir (opération), c'est pareil pour les classes