Discussion :

[behess]

Me voici confronté à un nouveau problème.

Comme je ne sais pas si c'est une question théorique ou une mauvaise manipulation de BOUML, je rapporte ici le thread ouvert par ailleurs.

Mon modèle est donc composé d'interfaces et je veux décrire les relations qu'entretiennent ces relations avec d'autres interfaces/classes.

En fait je suis parti de classes abstraites, mais j'en ai transformé certaines en interfaces par la suite à cause de multiples héritages... or ces classes abstraites étaient pourvues de relations.

Quand je fais la génération, BOUML me génère des attributs liés aux rôles portés par les dites relations, ainsi que les setter/getter liés.

Faut-il utiliser l'option "not generated in..." pour éviter cela ?
Existe-t-il une option "globale" permettant de spécifier que les relations "partant" d'interfaces ne doivent pas être générées ?

[bruno_pages]

Mon modèle est donc composé d'interfaces et je veux décrire les relations qu'entretiennent ces relations avec d'autres interfaces/classes.

de quel type de relation s'agit-il ?
s'il s'agit d'association/agrégation cela n'a effectivement pas de sens en Java

pourquoi ne pas détruire ces relations dans ces conditions ?
ou les transformer en dépendance si besoin ?

Faut-il utiliser l'option "not generated in..." pour éviter cela ?

oui, sauf si tu supprimes les relations indésirables évidemment

Existe-t-il une option "globale" permettant de spécifier que les relations "partant" d'interfaces ne doivent pas être générées ?

non, car tes définitions Java sont incohérentes, il faut retrouver une cohérence et le code généré le sera aussi

[hed62]

pourquoi ne pas détruire ces relations dans ces conditions ?

Comment faire alors, pour spécifier qu'un IConducteur conduit un IVehicule (peut importe le type de conducteur et celui du véhicule) ?

La relation doit bien etre là.

Par contre, elle ne doit pas produire d'attribut. Ensuite, je verrais bien que l'interface donne le prototype des getters, aux classes filles de les implémenter.

[bruno_pages]

Comment faire alors, pour spécifier qu'un IConducteur conduit un IVehicule (peut importe le type de conducteur et celui du véhicule) ?

je ne comprends pas en quoi la définition d'une relation avec une définition java non vide est utilile dans ce cas

La relation doit bien etre là.

encore une fois ce peut etre une dépendance, ou alors il faut dire not generated in Java (c'est à dire vider la définition en Java)

Par contre, elle ne doit pas produire d'attribut.

si on demande à la relation de produire du code elle le fera, si on lui demande ne ne pas produire du code elle n'en produira pas, c'est aussi bête simple et clair que cela

Ensuite, je verrais bien que l'interface donne le prototype des getters, aux classes filles de les implémenter.

cela ne marche pas comme cela, si la définition de l'attribut/relation associé est vide en Java (ou autre) la définition des getter/setter sera également vide en Java (ou autre), sinon non

[behess]

de quel type de relation s'agit-il ?
s'il s'agit d'association/agrégation cela n'a effectivement pas de sens en Java

pourquoi ne pas détruire ces relations dans ces conditions ?
ou les transformer en dépendance si besoin ?

Avec les classes abstraites, c'est faisable pourtant !

Mais admettons. Dans ce cas comment spécifier que :

toute classe qui implémente une interface donnée doit être lié à une classe implémentant une autre interface donnée ?

Ex: pour dire qu'une classe "fille" doit déléguer un traitement à une autre classe "fille" ?

--> passer par une définition de constructeur/setter prenant en paramètre cette interface ? mais on perd la sémantique de délégation.

--> comme tu le suggères en utilisant uniquement une dépendance ? là aussi on perd la sémantique de délégation du traitement !

[bruno_pages]

toute classe qui implémente une interface donnée doit être lié à une classe implémentant une autre interface donnée ?

ce genre de contrainte ne peut être traitée automatiquement par le modeleur ou par un générateur de code.

demanderais-tu à Java de le faire ? la réponse est la même pour Bouml, sinon je ne vois pas pourquoi tu ne lui demandes pas non plus de produire du code à partir des UCs

d'autre part lié à n'est pas une définition normée, et avoir une relation est tout aussi vague

c'est donc à l'utilisateur de résoudre cette contrainte, et celui-ci peut par ailleurs également la décrire en OCL

[behess]

Disons que "est lié" était ici une "abstraction" de relation

En réalité c'est, dans le cas qui m'intéresse, une agrégation.

Pour le moment ce que je fais c'est dire à BOUML qu'il ne doit pas générer de code pour la relation "abstraite".

Tu es d'accord qu'en principe il n'y a pas d'autre moyen de décrire le type de concept que je désire expliciter (une relation "abstraite") ?

[bruno_pages]

oui

à la limite tu peux aussi lui mettre le stéréotype abstract

[behess]

Merci pour cette confirmation.

J'avais penser effectivement mettre un stéréotype "abstract" sur la relation

D'ailleurs en faisant de ce stéréotype de relation quelque chose de standard dans BOUML, il serait facile au logiciel d'ignorer les relations comportant ce stéréotype ; ça règlerait le problème.

En tout cas, encore merci pour ces interventions.

[bruno_pages]

D'ailleurs en faisant de ce stéréotype de relation quelque chose de standard dans BOUML, il serait facile au logiciel d'ignorer les relations comportant ce stéréotype ; ça règlerait le problème.

c'est inutile, il est déjà possible d'avoir le même résultât autrement

de plus le stéréotype serait global et s'appliquerait à tous les langages cibles à la fois, ce qui est incompatible avec une génération multi-langages en simultanée où on voudrait produire du code pour certains et pas pour d'autres

[bruno_pages]

En fait c'est la génération d'un attribut pour le rôle associé à une relation qui "part" d'une interface qui m'ennuie.

Comme tu les suggères j'ai forcé la relation à ne pas générer de code.

Mais au delà de cette "astuce" du logiciel (puisqu'il ne décide pas de lui-même de zapper les relations partant d'interfaces)

je n'empêche pas non plus un code de contenir une division par zéro explicite.

Je te signale aussi qu'en C++ une classe abstraite peut très bien avoir des attributs et des opérations non abstraites, je ne vois pas très bien de quel droit je limiterai les capacités du langage et donc de la modélisation associée

je me demandais en fait s'il était "légitime" de modéliser des relations entre interfaces en UML.

oui

d'autre part je signale que la norme dit aussi if an interface declares an attribute, this does not necessary mean that the realizing instance will necessary have such an attribute in its implementation ....
Bref la demande de génération automatique des relations dans les classes filles de l'interface n'est pas fondée car non obligatoire, donc do it yourself si besoin

Pourrais-tu aussi m'indiquer comment je peux spécifier via les génération settings ce genre de "règle" ?

les generation settings ne connaissent pas ce genre de cas particulier, le vidage de la définition doit se faire au cas par cas à la main, ou via un plug-out automatisant la chose

[hed62]

d'autre part je signale que la norme dit aussi if an interface declares an attribute, this does not necessary mean that the realizing instance will necessary have such an attribute in its implementation ....

Voila le genre de réponse que j'attendais

Donc, behess , je pense que tu devrais :

1/ Mettre les interfaces
2/ Mettre les classes filles
3/ Mettre les relations entre les interfaces
4/ Mettre les relations entre les classes filles
5/ Masquer sur le "dessin" les relations entre les classes filles
6/ Décorer le DC de contraintes OCL afin de spécifier ce qui va bien dans ton cas
7/ Retirer la génération de la relation entre les interfaces
8/ Faire la génération de la relation entre les classes
9/ Ajouter le code des contraintes OCL

C'est ainsi que je le verrais

[behess]

Je te signale aussi qu'en C++ une classe abstraite peut très bien avoir des attributs et des opérations non abstraites, je ne vois pas très bien de quel droit je limiterai les capacités du langage et donc de la modélisation associée

Je sais bien, oui. Je parlais des classes stéréotypées « interface », et uniquement de celles-ci. Ce qui n'a rien à voir avec ta réponse.

Bref la demande de génération automatique des relations dans les classes filles de l'interface n'est pas fondée car non obligatoire, donc do it yourself si besoin

Qui a demandé une telle chose ? pas moi en tout cas, relis bien ce que j'ai écrit

C'est ainsi que je le verrais

Voilà qui est tout à fait raisonnable Et c'est exactement ce que je comptais faire

Merci à vous deux pour toutes ces réponses stimulantes !

[bruno_pages]

Je sais bien, oui. Je parlais des classes stéréotypées « interface », et uniquement de celles-ci. Ce qui n'a rien à voir avec ta réponse.

mais une interface cela s'appelle une classe abtraite en C++, je parlais bien de la même chose !

[behess]

Oui mais comme une interface au sens UML n'a pas d'attribut ni d'opérations non abstraites, ça n'est pas la même chose en théorie qu'une classe abstraite qui a des attributs et des opérations non abstraites

[bruno_pages]

oui, mais Bouml ne fait pas que de l'UML, son but est aussi de produire du code. Il me faut donc autoriser le sur ensemble UML C++ Java Idl Python Php

[behess]

Effectivement, je ne sais pas comment une interface UML est implémentée dans ces différents langages. Je pensais naïvement qu'une interface UML était forcément implémentée de manière à respecter les caractéristiques théoriques d'une interface (pas d'attributs ni d'opération non abstraites)...