Vente de CD, DVD…

Vente de CD, DVD…
Florent BAYLE
Alexis FOERSTER
Romain GRANJEAN
Barbara POISSONNET
Wei WANG
Amira WANG
Note :
COMMENTAIRES
Général
En LaTeX ok mais il faut bien le connaître pour faire une première page agréable.
Sommaire OK.
Aucune explication de diagramme ! Quel dommage ! Un diagramme ne se suffit pas à lui seul.
Oups, je n’ai rien dit c’est après tous les diagrammes…
D. CU : Pb d’include/extend. Pas d’authentification pour le client. Le client émet sa propre facture !
D. Classes : Associations anonymes. Pb de liens entre « Livraisons » et « Client » via « Achat ».
Associations n-aires inutiles et surtout fausses ! Pb similaires pour le paiement.
D. Seq : pb de message sans suite pour une commande. Pb d’authentification sur site. Le coté
Facultatif doit être modélisé. Pb de représentation de boucle (messages 5, 11 et 25). Attention, la
notion de GoTo dans les D.Seq ne doit pas exister ! C’est la banque qui vérifie la solvabilité d’un client
et pas votre site Web. La modélisation du comportement d’un client dans le magasin correspond à
un CU et pas à une séquence. Faites attention, les contraintes dans les D.Seq ne sont pas là pour
éviter des notations (boucle, branchement conditionnel…).
Le diagramme de communication est je suppose le diagramme de collaboration (pas d’utilisation
d’UML2) ☺
Pb de modélisation de la boucle d’achat. Collaboration/communication de classes : tout doit être des
classes. Est-ce le cas ?
D. Etats-transition : OK. Manque le côté non obligatoire de la commande si l’article n’est pas
disponible en magasin.
D. Activités : Problème de commande obligatoire à nouveau. Pour le magasin et pour le site, la
technique de connexion/inscription n’est pas correcte.
D. de composants : difficile de faire le lien avec votre D.Classes.
D. Déploiement : il faut des communications sécurisées au moins pour le paiement, non ?
Il est vraiment dommage que les explications des diagrammes se trouvent après les diagrammes. Il
est préférable de les mettre avant chaque diagramme surtout pour le CU dont les définitions des
acteurs sont dans les explications !
L’utilisation de la classe « Produit » est la seule et unique bonne façon de faire !
Attention, parler de CU Chronologique dans les explications du D.Seq est hasardeux.
Description du sujet
En une seule ligne, j’aurais aimé votre interprétation du sujet.
Diagramme de cas d’utilisation
Acteurs
Rien. Pas de description de rôle. (oups si dans les explications après)
Diagrammes
Quelle différence entre « Echange » et « Garantie » ? Pas d’explication donc problème.
Un client ne s’authentifie pas !!!!! C’est sympa comme site web !
« Gérer son compte » représente quoi puisqu’il n’y a qu’un include ? Là encore l’absence
d’explication pose un problème de compréhension.
Le client n’ « émettre une facture » pas. Je pense que c’est le magasin ou le site web qui va le faire
sinon montant de la facture égal à 0 lorsque je suis le client ☺
Les notes sur les moyens de paiement devraient être des contraintes sur les « extend ».
Les « include » entre « Gérer les commandes » et « Passer une commande » et « Suivre une
commande » devraient être des « extend ». En effet, votre modélisation impose au « Responsable
clientèle » lorsqu’il gère une commande de faire le suivi de commande et de passer une commande.
Diagramme de séquences
Commande
OK pour la note.
Problème avec le message 7, s’il a lieu alors le client ne reçoit jms sa commande…
Site
Le coté facultatif des messages 2, 6… doit être modélisé !
La note de vérification est fausse, il faut que le mot de passe valide corresponde en plus au login
existant !
Messages 5, 11 et 23, il fallait faire une boucle pour l’identification…
Pour les accès bancaire, il faut une banque !! Le site ne peut pas faire ces opérations.
Magasin
Cette modélisation doit être dans un D.CU et pas dans un D.Seq. De plus, vous utilisez trop souvent
des contraintes et surtout d’une mauvaise façon sans compté les facultatifs.
Diagramme de classes
Il faut nommer les associations.
Je ne comprends pas votre modélisation pour l’association « Produit », « Achat », « Commande ».
Cela est certainement dû au fait que les cardinalités sont fausses : il y en a trop… De plus, les 0
comme cardinalité min sont à utiliser avec une infinie précaution.
La classe « facture » doit être une classe d’association c’est-à-dire portée par l’association entre
« Achat » et « Client ». De plus, si vous avez des commandes, le client paye une commande à laquelle
est rattachée une facture.
La « Livraison » ne contient pas le client, cela risque d’être gênant, non ? Même en passant par
« Achat » puis « Client » on ne peut pas garantir que toute la livraison correspond au même client.
Vous avez dit en note dans le D.CU que le magasin ne fait pas crédit mais il est possible de faire un
achat sans payer (cardinalité min à 0 donc optionnel)…
Diagramme de collaboration/communication
Vous avez à nouveau un problème de boucler d’achat avant de passer à la caisse pour régler les
achats. Un client prend plusieurs articles/produits puis passe à la caisse. Si le client fait encore des
achats, c’est une autre séquence indépendante de la première. And so on.
Attention, le D. de collaboration contient de objet de classe existante ? Est-ce le cas pour CB,
Chèque… ? (ceci est vraie en UML 1 et 2 ☺)
Diagramme d’états-transitions
Achat
OK
Site
OK
Magasin
Attention, si l’article n’est pas disponible, le client peut ne pas vouloir le commander !
Diagramme d’activités
Magasin
Même problème si l’article n’est pas en stock, le client doit pouvoir aller l’acheter ailleurs. De plus,
lorsque l’article est commandé et arrive au magasin, le client n’est pas prévenu : il repasse tous les
jours ou il attend dans le magasin avec du matériel de camping ? ☺
Site
Attention, l’inscription et la connexion ne sont pas correcte !
Diagramme de composants
A quoi correspondent les paquetages « Gestion de la vente en magasin », « Gestion de la vente sur le
site internet » et « Utilisation du site internet » ?
On ne voit pas bien les liens entre votre D.Classes et vos composants : quelles classes sont dans quels
composants ?
Diagramme de déploiement
Aucune communication sécurisée !!! Je ne serai jamais un client de votre site !
OK.
Diagramme d’objets
Pourquoi n’est-t-il pas après le D.Classes ?
OK, correspond bien à votre D.Classes et il l’illustre bien. Dommage que le D.Classes soit
partiellement incorrect.
Génération de code
Oui mais…
Vos commentaires sur le code source sont faux. Le logiciel ne peut générer que ce que vous avez
modélisé. Par exemple, il ne peut générer les méthodes que si vous les avez définies dans le
D.Classes, il n’invente rien…
Outils utilisés
Visual Paradigm. Explications et justifications ok.