[UML]Diagramme de classe d'un projet

**Fratcha** · 12/06/2007, 10h42

Bonjour à tous, je travaille sur un projet où il est question de mettre en oeuvre un module de gestion de courrier dans une application déjà existante. Je suis actuellement sur la conception du diagramme de classe, le problème c'est que là où je travaille, il est question de programmation composant, donc en gros je dois faire un diagramme de classe très général qui puisse être transformé en composant.

J'aurai aimé savoir ce que vous pensez de ce diagramme de classe.

Ps : référence hérite d'une classe client et d'une classe établissement qui sont dans d'autres composants.

J'ai changé le diagramme.
Merci d'avance

**Alec6** · 12/06/2007, 11h41

Je comprends pas grand chose à ton diagramme, c'est pas claire les responsabilités de chaque classe;

C'est un composant graphique, si oui il semble qu'il y a un mélange entre les responsabilité graphique et celle du model de donnée du composant.

Ecrit à coté de chaque classe en commentaire la responsabilité pour chaque classe.

Commence par écrire les interfaces; Ensuite les classes abstraites puis concrètes.

**Fratcha** · 12/06/2007, 14h00

Je n'ai pas très bien compris ce que tu voulais que je fasses au niveau des responsabilité. J'ai rajouté des commentaires pour que tu puisses mieux comprendre le modèle d'analyse. Je suis désolé, mais je suis en stage et je débute dans la POO et l'analyse objet.

Merci.

**Alec6** · 12/06/2007, 14h21

Bon alors la première chose à faire c'est d'écrire en texte toute ta reflexion sur le sujet, et par analyse de ce texte du verra que le diagramme apparait de soi.

Commence par écrire le lexiques avec les définitions: par exemple,

Lorsque ton texte (ton explication) semble bien cohérent et que tu as utilisé les bons mots (tel que défini dans le petit robert), et que tu as attribués les bonnes définitions, tu te retrouves avec l'ensemble des classes dont tu as besoin pour ta modélisation.

Dans ton model j'ai l'impression que tu veux conserver des historiques de communication, et les différents moyen utilisés. Explique nous clairement, on pourra mieux t'aider.

Dans ton diagramme tu à la classe Envoi, je suppose que c'est pour une émission de courrier, sms, ou fax ??? Et ce que ca vaut un Recoi. Est ce qu'il n'y a pas un mot dans le dico plus approprié. Est ce que tu modélises un dialog . Explique... et choisi bien tes mots c'est super importants, car la modélisation UML et une transcription formel du langage naturel.

**Fratcha** · 12/06/2007, 14h30

J'ai fait un diagramme de cas d'utilisation graphique et détaillé si tu veux.
En fait je dois gérer des envois et des réceptions de courrier, qu'ils soient postaux et électronique. On doit pouvoir référencer n'importe quel courrier dans l'application, qu'ils soient créés par l'application ou bien créé à côté mais en rapport avec le sujet de l'application (envoi et réception). Les courriers sont composés de documents fusionnés (word). Certains courriers nécessitent une réponse d'autres non. Il est possible soit d'envoyer les courriers à plusieurs clients.

Diagramme de cas d'utilisation :

**Alec6** · 12/06/2007, 15h49

J'arrive pas a accéder au diagramme des uses cases; je ne sais pas pourquoi.

Sinon moi je commencerai par parler de communication:
une communication est l'aggregation d'un message et d'un protocol (de communication) qui peut etre un courrier un courriel, sms, fax etc...
(heritage donc)

**Fratcha** · 12/06/2007, 15h54

Désolé j'avais oublié de mettre en lien, c'est bon tu dois pouvoir avoir accès au use case. Sinon si tu veux encore plus d'explication j'ai détaillé chaque cas dans un document.

**Alec6** · 12/06/2007, 16h04

j'ai acces au lien mais l'image et petite ??

**Alec6** · 12/06/2007, 16h07

Tu disais que tes courries était produit par fusion de document word (je suppose des templates pour des réponses toute faites), il faut dans ce cas absolument lire le pattern Decorateur qui est fait pour.

Cette partie de creation du message est à mettre ailleur. C'est un processus métier de ton composant et non une partie du modèle.