Discussion :

[Yann39]

Bonjour,

j'ai une petite question sur une relation de mon diagramme de classe.
Je ne sais pas si j'ai le droit de mettre une relation ternaire, je n'arrive pas à comprendre leur principe.

Disons que j'ai une classe ARCHITECTE et INSTALLATEUR et une autre classe PLAN qui contient des plans de maison par exemple.

J'ai donc 2 relation ARCHITECTE *---------modifier----------->* PLAN
et INSTALLATEUR *-----------modifier-----------> *PLAN

Puis-je faire une ternaire comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
ARCHITECTE *________________________________________* INSTALLATEUR
                            \ / modifier
                             |
                             *
                            PLAN

?

Merci d'avance

[bruno_pages]

Bonsoir,

déjà je trouve bizarre d'avoir une relation appelée modifier. modifier est une action peut être supportée par une opération mais pas par une relation

pour le reste, on ne rassemble pas deux relations séparées dans une relation ternaire. le fait qu'il y ai un point commun (plan) n'est pas suffisant.

Bruno

[Yann39]

En fait j'ai quelquechose comme ça :



On m'a déjà rouspéter sur ce forum car je mettais des noms de relation dans les use case... il n'en faut pas non plus dans le diagramme de classe ?

Et PowerAMC me met des flèches pour les relations, je n'arrive pas à les enlever. Je pense que c'est optionnel et que c'est juste pour indiquer le sens de lecture ?

Merci.

[hed62]

En effet, on ne place pas de nom sur les relations. Tu peux toutefois spécifier les rôles (un nom commun qui permet de savoir comment Architecte désigne ses plans, ou comment un Plan nomme son Architecte par exemple)

Les flèche ne désigne pas le sens de lecture, et ne sont pas vraiment optionnelles. Elle désigne le sens de navigation et ont un impact fort sur le code de l'implémentation.

Aucune flèche :
- diagramme métier => ne signifie rien de spécial
- diagramme complet => les deux sens sont navigables (A---B) signifie que A voit B et B voit A (donc possède de quoi y accéder)

Une flèche :
- impose qui voit l'autre, et qui ne voit pas l'autre

[bruno_pages]

On m'a déjà rouspéter sur ce forum car je mettais des noms de relation dans les use case... il n'en faut pas non plus dans le diagramme de classe ?

rouspéter

dans DC les relations peuvent être nommées, mais cela ne veut pas dire que tout les noms conviennent

[edit]ma réponse c'est télescopée avec celle de hed62, je confirme qu'on peut nommer les relations, et qu'il y a distinction entre le nom de la relation et le nom des rôles. Toutefois le nom mage d'une relation est nettement plus rare que le nom mage des rôles qui lui est obligatoire lorsqu'on veut générer du code.[/edit]

Et PowerAMC me met des flèches pour les relations, je n'arrive pas à les enlever. Je pense que c'est optionnel et que c'est juste pour indiquer le sens de lecture ?

il y a une flèche dans le cas d'une relation monodirectionnelle, pas de flèche dans le cas d'une relation bidirectionnelle.

Dans ton cas ARCHITECTE et INSTALLATEUR accède à des PLANs, mais l'inverse n'est donc pas vrai c.a.d. qu'un PLAN n'a pas d'accès à des ARCHITECTEs et INSTALLATEURs

Bruno

[Yann39]

Donc en fait on nous apprend des trucs faux à l'école ...

Mais à vrai dire j'ai ceci :



Des installateurs et des particuliers peuvent programmer des telecommandes, et les installateur peuvent mémoriser leurs programmations.

Le problème c'est que j'ai 2 tables "progrrammer" qui sont générée dont je n'ai pas forcément besoin dans la bdd, ainsi qu'une classe "concerner"...



Pour les rôles PowerAMC me met en effet des Warning "Affectation de nom de rôle" sur certaines relations donc je pense que c'est assez important. Je vais regarder ça.
Et je vais devoir remodifier mes diagrammes sous paint pour enlever les flèches alors :'(

[bruno_pages]

je n'avais pas tilté sur le fait qu'il s'agissait de BD et non d'un diagramme de classes 'standard'

Et je vais devoir remodifier mes diagrammes sous paint pour enlever les flèches alors :'(

comprends pas. Si tu ne veux pas de flèches il te suffit d'avoir des relations bidir, mais il ne faut pas le faire si cela ne correspond pas à la réalité !

[hed62]

Tu mélange MLD et DC... Et donc Merise et UML ( soit une méthode et un langage)

le poste de 11h51 est un MLD : modele logique de donnée, donc une vue BD, donc le nommage est correct, et l'implication est bien qu'il te génère 2 tables programmer. Pour la bonne et simple raison que tu a des relations n to n, et donc il faut une table de correspondance. Si une telecommande n'as qu'un seul installateur, une relation 1->n suffit, et cela va se traduire par une foreign key chez la table Telecommande, et une List<Telecommande> chez installateur.

Si tu as besoin de précisions... Je reviens demain

Ps (dslé pour al rédaction, je suis un chouilla pressé )

[Yann39]

Merci hed62 de prendre le temps de répondre même quand tu es pressé

Alors oui j'ai fait que du Merise jusqu'à maintenant, il est donc possible que je mélange un peu
Je crois en fait qu'en UML on ne met pas les identidiant parmis les attributs.

Par contre que ce soit un MCD Merise ou un diagramme de classe UML, ça génère bien les tables après ?

comprends pas. Si tu ne veux pas de flèches il te suffit d'avoir des relations bidir, mais il ne faut pas le faire si cela ne correspond pas à la réalité !

PowerAMC permet seulement de faire une relation entre 2 tables, je ne peut pas choisir uni ou bidirectionelle apparement :/


En tous cas je trouvais Merise bien plus proche de l'application, on voyais mieux à quoi elle allait ressembler.

[PINGOUIN_GEANT]

Es-tu sûr que tu n'as que modifier comme action pour architecte ou installateur. Il pourrait y avoir créer, valider...
Tu pourrais indiquer une relation de dépendance entre les classes.
Puis utiliser les notions de service (introduire des components et des ports) pour lister les opérations effectuées.

[hed62]

En tous cas je trouvais Merise bien plus proche de l'application, on voyais mieux à quoi elle allait ressembler

Sans retomber dans le fameux débat UML/Merise :

Merise te permet de mieux comprendre l'application au niveau des données (base de données, modèle entité-relations, etc.)

UML te permet de comprendre mieux le fonctionnement de ton application, la logique métier derrière les noms de tes objets.

Les deux sont complémentaires ! J'utilise UML pour les UC, les DC, les diagrammes de séquences, je "convertit" mon DC en MPD pour obtenir ma base de données.

En effet, pas d'identifiants techniques en UML.

La génération d'une BD à partir d'un DC est possible mais je déconseille : un DC n'est pas fait pour représenter une BD, mais l'organisation métier de tes objets.

Tu peux penser que cela rajoute du boulot. Oui, c'est vrai, c'est couteux de maintenir 2 diagrammes sensiblement équivalents. Mais combien de temps regagne tu lorsque tu veux avoir une vue organisationnelle métier, ou quand tu veux avoir une vue stockage/indexation des données ?

Idem, on ne place pas de MPD en soutenance, c'est trop peu lisible, trop d'infos polluantes. Par contre, le MPD te permettra de générer au mieux ta BD.

[Yann39]

Es-tu sûr que tu n'as que modifier comme action pour architecte ou installateur. Il pourrait y avoir créer, valider...
Tu pourrais indiquer une relation de dépendance entre les classes.
Puis utiliser les notions de service (introduire des components et des ports) pour lister les opérations effectuées.

Oui c'etait juste un exemple pour savoir si je pouvais faire une ternaire, mais c'est un peu plus volumineux dans mon diagramme complet


Sinon j'ai regarder un peu les ternaires sur le net et j'ai bien compris comment ça fonctionne, je n'ai n'ai pas besoin dans mon DC.

Mais bon il y a beaucoup de choses que je trouve bizarres dans UML, je vous épargnerez ça. Je vais d'ailleur jeter un coup d'oeil aux cours sur le net car on a pas vraiment d'explications claires en cours...

Merci pour vos précisions

[hed62]

Mais bon il y a beaucoup de choses que je trouve bizarres dans UML

Peut être est ce parceque tu ne les comprend pas ou qu'elles ont été mal expliquées.

N'hésites pas à poser ces questions dans un topic séparé, j'essaierai d'y répondre au mieux!

[Yann39]

Ok dernière petite chose alors

Lorsque j'ai ceci :


Cela va me créer dans ma bdd une table paiement avec l'id du particulier ET l'id de l'installateur !
Hors je voudrais avoir une table paiement avec un seul id qui corresponde soit à un installateur soit à un particulier.

Je ne voit pas comment faire...


PS : Et j'ai trouvé comment enlever les flèches dans PowerMAC, il faut décocher l'option "navigable" du coté de la relation ou il y a la flèche, je l'avait déjà fait mais je pensais que ça ne fonctionnais pas vu qu'il fallait bouger la page pour que la flèche s'enlève (petit bug d'affichage).

[Yann39]

J'ai posé une colle ?

Dans le même genre :
Si j'ai par exemple une classe PRODUIT et une classe TELECOMMANDE. Une télécommande étant un produit j'ai fait une dépendance entre les 2.
PRODUIT -----------------> TELECOMMANDE

Le problème c'est qu'avec une dépendance je n'ai pas la clé du produit qui passe dans télécommande (pour la bdd).

J'ai pensé faire ça avec une aggrégation ou une composition mais c'est faux vu qu'une TELECOMMANDE n'est ni une partie d'un PRODUIT ni un composant d'un PRODUIT.

Une solution ?



EDIT : C'est bon en fait, c'est parceque je faisait une Dépendance au lieu d'une Généralisation dans PowerAMC...
C'est en écrivant le problème que j'ai vu la solution

[hed62]

J'ai posé une colle ?

Pas du tout laisse moi le temps de revenir

Il te suffit d'avoir une interface "Personne" dont hériteront Particulier et Installeur :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
 
Paiement -*----1..1--> Personne <|---Particulier
                                <|---Installeur

J'ai pensé faire ça avec une aggrégation ou une composition mais c'est faux vu qu'une TELECOMMANDE n'est ni une partie d'un PRODUIT ni un composant d'un PRODUIT.

Puisque une telecommande EST UN produit, il te faut un héritage.


(ah ben tu t'es auto répondu..)

[hed62]

Pour encore mieux concevoir, tu ajoutes dans l'interface les méthodes GetNom() et GetAddresse() qui forceront toutes les personnes à avoir un nom et une adresse.



Ensuite, pour abuser un peu, tu mets une classe abstraite entre l'interface et les classes concrètes, cette classe possèderas deux attributs et un constructeur prenant les deux paramètres nom et adresse, et répondra à l'interface en retournant les attributs (respectivement nom et adresse dans GetNom et GetAdresse).
Enfin, les deux classes concrètes sont débarrassée de la gestion de leur nom et adresses, et se concentrent sur leurs aspects spécifiques, je pense notamment au prénom du particulier.

De même si tu veux que le particulier réponde Nom_Prenom à GetNom, il te suffit de surcharger la méthode de la classe abstraite.

Si tu as des remarques ou des questionnements sur ce principe de conception, n'hésite pas.

[Yann39]

OK Merci.
Le pire c'est que j'avais déjà tenté une classe Personne mais vu que là encore je faisait une dépendance au lieu d'une généralisation mes clé ne bougeais pas :/

Sinon que veuts-tu dire par interface ? Les méthodes ne se mettent pas dans la classe en dessous des attributs ?
J'ai bien des interface dans powerAMC mais je ne sais pas comment ça s'utilise nous ne l'avons pas vu en cours. Si je comprend bien c'est pour éviter d'avoir 2 fois les méthode GetNom() et GetAdresse() dans les 2 classes ?

Et puis si je veut gérer un compte (login, pass) pur chaque client et installateur, il vaut mieux que je mette les attributs dans la classe client? dans les 2 classes héritières? ou encore dans une classe compte séparée? Sachant que ce n'est pas le même type de compte (compte entreprise pour les installateur).

Désolé si mes questions n'ont plus trop de rapport avec le sujet initial mais ça m'embête de recréer un topic à chaque fois.

[hed62]

Sinon que veuts-tu dire par interface ? Les méthodes ne se mettent pas dans la classe en dessous des attributs ?

Quelles sont tes connaissances en programmation/conception orientée objet ? Si tu ne sais pas ce qu'est une interface...

Tu peux voir une interface comme une classe ne possédant aucun attribut, et qui oblige ses classes filles à implémenter les méthodes qu'elle définit. Cela te permet de regrouper les classes ayant des points commun au niveau opérations.

Par exemple, jai un logiciel de dessin. Il manipule des carré et des cercles. Je veux pourvoir récupérer le périmètre et l'aire de chacun, et dessiner toutes les formes.

J'aurais donc l'interface IForme avec GetPerimetre, GetAire, Dessiner.
Puis deux classes implémentant cette interface : Carré et Cercle.

Cela me permet de manipuler des IForme indépendamment du fait qu'elle soient des Carré ou des Cercles : cela s'appelle le polymorphisme.

Les méthodes ne se mettent pas dans la classe en dessous des attributs ?

Oui, sinon c'est bien là qu'elle sont.

Si je comprend bien c'est pour éviter d'avoir 2 fois les méthode GetNom() et GetAdresse() dans les 2 classes ?

Oui tout à fait, même si cela permet d'autres choses.

nous ne l'avons pas vu en cours

Ok je comprend mieux.

ça m'embête de recréer un topic à chaque fois.

Tant que tu reste dans les DC, c'est bon.

Pour ton histoire de Compte, pose toi la question : à qui revient la responsabilité de porter son log/pass ? Au client ? A l'installateur ? Aux deux (et donc ca tombe dans la classe abstraite?)
Pour ce qui est du type de compte, idem : à qui de savoir quel est le type de compte : Le Client, l'Installeur, Les deux ? Le compte lui même ?
Ensuite, comment va tu gérer ce type de compte, quels impacts cela aura t il ? (prix mensuel, possibilités suplémentaires, etc) Si tu me dit un particulier à un compte simple, un installeur a un compte pro, un compte pro est attaché forcément à un installeur et un compte simple est forcément ataché à un particulier, alors Type de compte est inutile, puisqu'il s'agit d'une bijection de type de personne.
En effet : la personne possède en elle même les info pour décider si le compte est pro ou simple. Par contre si tu me dis qu'un installeur peut éventuellement avoir un compte simple, ou un particulier avoir un compte pro, alors Type de compte est bien nécessaire?

Comprends tu ? Sinon, qu'est ce qui te poses problème ?

[Yann39]

Si si bien sûr je sais ce qu'est une interface c'est simplement que je ne voyais pas trop comment ça s'implémentait en UML (les relations, symboles, etc..) mais j'ai trouvé 2/3 trucs sur le net là

Pour le type de compte l'impact sera juste que le particulier payera par carte bancaire pour chaque programmation, alors que l'installateurs ne paie pas directement, il dispose d'un abonnement mensuel, le compte de l'entreprise est donc débité pour l'ensemble des programmations qu'il effectue dans le mois. Il faudra d'ailleur que je gère un type de paiement...

Pour les comptes je pense que le particulier doit créer son compte sur le site, mais pour un installateur c'est plutôt l'entreprise qui propose le service qui lui créera son accès après demande de la part de l'installateur.

Je vais réfléchir à tous ça.

Merci.