Discussion :

[babar75]

Et oui, c'est encore moi.

Actuellement, dans Bouml, l'import XMI des composants ne tient pas compte de la relation de composition (les "nested components" d'UML2).
Après l'import d'un code XMI comme celui-ci :

Code :

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

1
2
3
<packagedElement xmi:type="uml:Component" xmi:id="BOUML_0x49e1a70" name="Main">
    <packagedElement xmi:type="uml:Component" xmi:id="BOUML_0x49e74e0" name="Subsystem1"></packagedElement>
</packagedElement>

on retrouve Subsystem1 et Main au même niveau, alors que l'un est un sous-composant de l'autre...

Baptiste
PS : je développe un outil de reverse-engineering basé sur XMI, et je fais tous mes tests sur Bouml, Rose, Argo, etc... D'où mes constatations et mes retours...

[bruno_pages]

ok, merci pour l'info, ce sera corrigé

puisqu'on parle d'XMI, un collègue à vu un problème avec les fichiers XMI produits par les outils sous Eclipse : les informations d'agrégation sont de l'autre coté par rapport à ce que font Bouml, Enterprise Architecte, Visual Paradigm, Jude ...

avec l'exemple en pièce jointe, sous Eclipse aggregation="composite" se trouve dans la définition de b (ce qui par ailleurs est logique), par contre pour les autres outils cela se trouve (bizarement, mais j'ai été forcé de faire pareil) dans la définition de a.

ainsi Bouml produit :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
<?xml version="1.0" encoding="UTF-8"?>
<xmi:XMI xmi:version="2.1" xmlns:uml="http://schema.omg.org/spec/UML/2.1" xmlns:xmi="http://schema.omg.org/spec/XMI/2.1">
	<xmi:Documentation exporter="Bouml" exporterVersion="1.5.3"/>
	<uml:Model xmi:type="uml:Model" xmi:id="themodel" name="r">
		<packagedElement xmi:type="uml:Package" xmi:id="BOUML_0x9e80f88" name ="r">
			<packagedElement xmi:type="uml:Class" name="A" xmi:id="BOUML_0x9f3f1b0" visibility="package" isAbstract="false" >
				<ownedAttribute xmi:type="uml:Property" name="b" xmi:id="BOUML_0x9edae80" visibility="protected" association="ASSOC_BOUML_0x9edae80" aggregation="none">
					<type xmi:idref="BOUML_0x9f404d0"/>
				</ownedAttribute>
			</packagedElement>
			<packagedElement xmi:type="uml:Class" name="B" xmi:id="BOUML_0x9f404d0" visibility="package" isAbstract="false" >
				<ownedAttribute xmi:type="uml:Property" name="a" xmi:id="BOUML_0x9f41610" visibility="protected" association="ASSOC_BOUML_0x9edae80" aggregation="composite">
					<type xmi:idref="BOUML_0x9f3f1b0"/>
				</ownedAttribute>
			</packagedElement>
			<packagedElement xmi:type="uml:Association" xmi:id="ASSOC_BOUML_0x9edae80" visibility="protected">
				<memberEnd xmi:idref="BOUML_0x9edae80"/>
				<memberEnd xmi:idref="BOUML_0x9f41610"/>
			</packagedElement>
		</packagedElement>
	</uml:Model>
</xmi:XMI>

tout cela est lié au problème numéro 9889 http://www.omg.org/archives/issues/msg11540.html

peux-tu faire l'essai avec les outils dont tu disposes produisant de l'XMI 2 et me donner le résultat ?

merci

[babar75]

peux-tu faire l'essai avec les outils dont tu disposes produisant de l'XMI 2 et me donner le résultat ?

Malheureusement, je m'appuie surtout sur des outils UML 1.4. Mes tests avec UML2 se font avec Bouml et Papyrus (Eclipse).
Et en effet, je confirme, sous Eclipse.
Avec papyrus, un schéma comme le tien produit le code :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
  <packagedElement xmi:type="uml:Class" xmi:id="_D9EhMPbLEdyqMIxpCJk6pA" name="A">
    <ownedAttribute xmi:id="_JX-DofbLEdyqMIxpCJk6pA" name="b" type="_Gp7JAPbLEdyqMIxpCJk6pA" isUnique="false" aggregation="composite" association="_JX-DoPbLEdyqMIxpCJk6pA">
      <upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_JYH0ofbLEdyqMIxpCJk6pA" value="*"/>
      <lowerValue xmi:type="uml:LiteralInteger" xmi:id="_JYH0oPbLEdyqMIxpCJk6pA"/>
    </ownedAttribute>
  </packagedElement>
  <packagedElement xmi:type="uml:Class" xmi:id="_Gp7JAPbLEdyqMIxpCJk6pA" name="B">
    <ownedAttribute xmi:id="_JYH0ovbLEdyqMIxpCJk6pA" name="a" type="_D9EhMPbLEdyqMIxpCJk6pA" isUnique="false" association="_JX-DoPbLEdyqMIxpCJk6pA">
      <upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_JYH0o_bLEdyqMIxpCJk6pA" value="1"/>
      <lowerValue xmi:type="uml:LiteralInteger" xmi:id="_JYH0pPbLEdyqMIxpCJk6pA" value="1"/>
    </ownedAttribute>
  </packagedElement>
  <packagedElement xmi:type="uml:Association" xmi:id="_JX-DoPbLEdyqMIxpCJk6pA" name="Association_A_B" visibility="protected" memberEnd="_JX-DofbLEdyqMIxpCJk6pA _JYH0ovbLEdyqMIxpCJk6pA"/>

Page 39 de Superstructure 2.1.2, on lit :

Semantic Variation Points
Precise semantics of shared aggregation varies by application area and modeler.
The order and way in which part instances are created is not defined.

On peut peut-être considérer que ça englobe le problème que tu signales.

[bruno_pages]

ok

J'ai installé Papyrus hier soir pour quelques essais, dont les relations

Apparemment avec lui les relations dessinées sont exclusivement uni-directionnelles, et on ne peut pas faire d'agrégation ou de composition.

Je n'ai pas trouvé comment faire un export XMI, même en faisant un projet EMF basé sur le projet Papyrus [edit]ou alors il faut considérer que le .uml est un .xmi ?[/edit]

En tout cas ne n'arrive pas, mais alors vraiment pas, à me faire aux temps de réponse, comment peut-on utiliser ce genre d'usine à gaz ?

[babar75]

Apparemment avec lui les relations dessinées sont exclusivement uni-directionnelles, et on ne peut pas faire d'agrégation ou de composition.

Bin si (quand même !). Regarde le fichier joint à mon dernier post : il est fait avec Papyrus. Il faut sélectionner ton association. Dans la fenêtre des propriétés de l'asso (dans le bloc "Properties" habituel, en version plugin Eclipse), tu peux alors préciser la navigabilité, la visibilité, et, au niveau de chaque rôle, la multiplicité et l'aggregationkind (c'est donc là que se situe l'inversion dont tu parles).
Attention, le diamond des aggrégations n'apparaît sur les diagrammes que si l'asso est définie comme navigable dans les deux sens.

Mettre une extrêmité à "composite" force la multiplicité de l'autre extrêmité à 0..1. Mais rien ne t'empêche de remodifier manuellement celle-ci ensuite pour la mettre à *... Hum.

Je n'ai pas trouvé comment faire un export XMI, même en faisant un projet EMF basé sur le projet Papyrus [edit]ou alors il faut considérer que le .uml est un .xmi ?[/edit]

Oui, le fichier qui porte l'extension ".uml" contient les données UML. Simplement, le namespace xmi est précisé au niveau d'un élement UML, tandis que Bouml le donnes au niveau d'un élement XMI...

En tout cas ne n'arrive pas, mais alors vraiment pas, à me faire aux temps de réponse, comment peut-on utiliser ce genre d'usine à gaz ?

En effet, c'est pas super véloce, comme Argouml.
Mais là, c'est le problème d'Eclipse en général.
Et graphiquement, les diagrammes de Papyrus sont assez moches.
En plus, pour les exporter, ou pour générer du code, il faut installer d'autres plugins !!

En revanche, je trouve la palette d'objets disponibles plutôt fournie, il y a la gestion des profiles, et les contraintes. De plus, ergonomiquement, il y a souvent des arborescences qui sont proposées, plutôt que des listes déroulantes (l'affectation d'un type à une valeur de propriété est pas mal faite par exemple).
Et il est plutôt souple (en particulier, on peut facilement créer les élements "on the fly" (classes, artifacts), sans devoir passer préalablement par telle ou telle vue)...

[bruno_pages]

Bin si (quand même !).

ok, je vais faire des essais

Attention, le diamond des aggrégations n'apparaît sur les diagrammes que si l'asso est définie comme navigable dans les deux sens.

tu devrais leur envoyer un rapport de bug à ce sujet

Oui, le fichier qui porte l'extension ".uml" contient les données UML. Simplement, le namespace xmi est précisé au niveau d'un élement UML, tandis que Bouml le donnes au niveau d'un élement XMI...

le problème est qu'il ne s'agit pas d'un XMI légal, par exemple un <ownedAttribute ...> n'a pas de xmi:type

on peut facilement créer les élements "on the fly"

c'est également le cas dans Bouml depuis toujours au niveau des diagrammes, et depuis quelque temps déjà au niveau des dialogues, par exemple

• le bouton type lorsque tu edites un attribut permet de créer une nouvelle classe pour le typer
• le bouton message lors de l'édition d'un message dans un diagramme de sequence/communication permet d'ajouter une opération,
• le bouton behavior lors de l'édition d'une action de type call behavior permet de creer une activité ou machine à état
• etc ...

(re) Bouml n'est pas aussi rigide que tu le penses

[bruno_pages]

l'import XMI des composants ne tient pas compte de la relation de composition (les "nested components" d'UML2)

la 4.2.1 est disponible et corrige (entre autre) ce problème

P.S. faites plutôt vos download sur source forge, le serveur sous Free est très utilisé (la 4.2 y a été téléchargée plus de 23000 fois ) et est donc lent.