Utilisation de ArchGenXML :

Sommaire :

1) Introduction :

ArchGenXML est un outil pour Plone/Zope qui permet de générer automatiquement des produits pour Plone, sans avoir à générer de code python. A partir d'un schéma UML, au format xmi ou zuml, ArchGenXML va générer un dossier correspondant au produit avec ses skins, ses classes, ses paquetages...

Cet outil reprend toutes les possibilités d'Archetypes (schémas, widgets,... ) tout en garantissant un temps de développement moindre. Il n'y a plus de code à produire, il suffit de se concentrer sur les fonctionnalités du produit.

Il est aussi possible de rajouter son propre code dans le produit obtenu, il ne sera pas écrasé en cas de mise à jour avec ArchGenXML.

2) Installation :

Avant d'installer, vérifiez que vous avez bien la version 2 de Plone et un interpréteur python version 2.3 minimum.

Les sources sont disponibles ici : http://sourceforge.net/project/showfiles.php?group_id=75272&package_id=103241

Il suffit d'extraire les sources dans le répertoire de votre choix (il n'est pas nécessaire de l'installer dans le répertoire Zope). Néanmoins la commande ArchGenXML.py sera disponible uniquement dans le répertoire d'installation.

D'autres paquets peuvent être nécessaires pour avoir accès à certaines fonctionnalités d'ArchGenXML :

• i18ndude : ce paquet permet de gérer différentes langues dans Plone. Avec ce paquet il est possible de rendre un produit multi-langues. Il devient donc possible d'avoir le champ « titre » de votre produit qui s'intitule « title » dans la version anglaise de Plone, et « titre » dans la version française. Il s'installe à partir de http://sourceforge.net/projects/plone-i18n

• ATVocabularyManager : ce paquet permet de gérer des dictionnaires de vocabulaire assez conséquents. Vous aurez parfois besoin de définir les valeurs que peut prendre un champ de formulaire, il sera plus facile de faire appel à un dictionnaire extérieur que de lister tout le vocabulaire dans le schéma UML. Ce paquet est disponible sur http://svn.plone.org/svn/archetypes/ATVocabularyManager/trunk/

3. Premiers pas :

Création du modèle UML :

Nous allons commencer par créer un produit minimal pour faire plus ample connaissance avec ArchGenXML.

Pour cela, ouvrez Poseidon (ou un autre éditeur UML, mais ce tutoriel sera basé sur Poseidon) et créez un nouveau module, du nom de votre futur produit (dans l'exemple : ArtistSite). Ensuite créez un nouveau diagramme de classes (dans l'exemple : Classes). Créons une nouvelle classe, par exemple la classe Artiste, avec comme attributs :

• nom de type string

• photo de type image (le type image n'existe pas par défaut dans Poseidon, il suffit de créer un datatype image sans spécifications et ArchGenXML le reconnaîtra grâce à son nom)

• description de type string

• instrument de type string

Votre résultat devrait ressembler à ça :

capture

Note : ArchGenXML ne supporte pas les caractères spéciaux et accents, les noms de modules, classes, diagrammes de classes et d'états doivent donc en être exempts.

Génération du Produit python :

Une fois votre classe créée, sauvegardez votre projet en zuml ou xmi. Nous allons maintenant utiliser ArchGenXML. Placez-vous dans le répertoire d'ArchGenXML et lancez la commande suivante :

python ArchGenXML.py [-o <destination>] <source>

<destination> est le chemin vers le répertoire de votre futur produit. (Typiquement, dans le répertoire Products de votre instance de Zope). Il n'est pas obligatoire, par défaut ArchGenXML créera un répertoire du nom de votre module UML. Dans notre exemple, il s'agira de « ArtistSite ».

<source> est le chemin vers votre schéma UML

Utilisation du produit obtenu :

Votre produit doit être placé dans le répertoire Products de votre instance Zope, si ce n'est pas encore fait.

Démarrez le serveur Zope et rendez-vous sur votre site Plone. Dans le centre de configuration de Plone, avec l'utilitaire d'installation et de déinstallation de produits, installez votre nouveau produit.

Une fois installé vous pourrez commencer à l'utiliser, dans notre cas créer et éditer des objets « artiste ».

capture

4. Les tags :

Description :

Les tags permettent de personnaliser le comportement des attributs. Pour le moment nous avons créé un produit tout simple, une amélioration à apporter serait de rendre le champ « nom » obligatoire, ce qui n'est pas le cas dans le produit actuel. Ou encore d'avoir une liste d'instruments de musique prédéfinie au lieu de devoir taper soi-même l'instrument.

Un tag se comporte de la façon suivante : il a un nom et un contenu. On le retrouve dans un élément UML (une classe, un attribut,...). Par défaut ce contenu est une chaîne. Il est néanmoins possible d'avoir un contenu plus complexe, comme un dictionnaire ou une liste python, en préfixant le contenu par « python: ».

Il existe des tags pour les widgets, les permissions, les classes, les importations, du code python...

Les différentes valeurs des tags peuvent être trouvées ici :
http://plone.org/documentation/tutorial/archgenxml-getting-started/archgenxmlquickref

http://plone.org/documentation/tutorial/archgenxml-getting-started/tagged-value-overview

En pratique :

Nous allons améliorer notre produit précédent. Tout d'abord il faut rajouter un tag « required » de valeur « python:1 » aux attributs indispensables de la classe (comme le nom). Cela rendra obligatoire le remplissage de certains champs lorsque l'on crée un objet artiste.

Nous allons aussi créer un menu déroulant pour les instruments, avec un vocabulaire spécifique. Pour cela sélectionnez l'attribut instrument, changez son type pour « multiselection » (ce type n'existe pas par défaut, il faut créer un datatype avec son nom).

Au niveau des tags de l'attribut instrument, cela donne :

• required = python:1

• vocabulary = python:['clarinette','saxophone','trompette','piano','batterie']

Ainsi les valeurs prises par instrument ne pourront qu'être les valeurs de notre liste d'instruments.

Au niveau de Poseidon, vous devriez obtenir ceci :

capture

Au niveau de Plone, après avoir recréé le produit dans ArchGenXML et réinstallé :

capture

5. Les widgets :

Description :

Dans Archetypes, les widgets permettent de gérer l'affichage des éléments d'un produit. Un TextAreaWidget gérera du texte, un FileWidget un fichier...

Avec ArchGenXML il n'y a pas vraiment besoin de s'en occuper si l'on peut se contenter d'un produit basique. Par défaut ArchGenXML se base sur le type d'un élément pour trouver le widget qui y correspond le plus. Pour une image, il prendra un FileWidget, et pour un type multiselection il prendra un SelectionWidget.

Les widgets peuvent être personnalisés avec des tags, en voici quelques-uns :

• widget:type permet de définir le type de widget à utiliser, ex : TextAreaWidget

• widget:label correspond à l'intitulé du widget dans Plone

• widget:description correspond à la description qui apparaît dans Plone

• widget:label_msgid écrase l'identifiant par défaut du widget (à utiliser avec i18n)

• widget:description_msgid écrase la description par défaut du widget (i18n)

• widget:size et beaucoup d'autres, spécifiques à certains widgets

Note : les tags widget:label_msgid et widget:description_msgid permettent de donner un identifiant unique aux champs label et description, pour permettre l'utilisation de i18n. Pour chaque langue qu'il supporte, Plone associe un identifiant à sa traduction, le tout dans un fichier *.pot Ce qui permet d'avoir un portail multi-langues sans devoir changer les traductions sur tout le portail, il suffit de modifier le fichier *.pot

En pratique :

Nous allons modifier l'apparence du formulaire Artiste en rajoutant quelques tags. Tout d'abord le formulaire pour la description apparaît tout petit pour une description, il faudrait qu'il fasse plusieurs lignes.

Dans ses tags il suffit de rajouter « widget:type = TextAreaWidget ». Cela va signaler à ArchGenXML d'utiliser le widget TextArea au lieu du widget String qu'il prend automatiquement. Tant qu'à faire modifions aussi la description : « widget:description = Entrez une breve biographie de l'artiste »

Modifions également les tags de l'attribut « instrument » en ajoutant un tag multiValued=python:1 pour que l'on puisse sélectionner plusieurs instruments, et un tag widget:label = Instrument(s) joue(s) pour changer l'intitulé du formulaire.

Modifiez aussi le label de l'attribut « nom » pour qu'il s'affiche « nom de l'auteur » dans le formulaire.

Vous devriez obtenir ceci dans Plone :

capture

6. Les classes et stéréotypes :

Description :

Les classes peuvent dériver d'autres classes, selon les fonctionnalités voulues. Par défaut une classe simple sera dérivée de la classe « BaseContent » de Archetypes.

Pour dériver d'autres classes, il est possible de « stéréotyper » les classes, par exemple avec le stéréotype <<folder>> la classe va dériver de BaseFolder. Une classe dérivée de BaseFolder aura l'aspect d'un répertoire dans Plone.

Quelques stéréotypes :

• <<Abstract>> une classe stéréotypée « Abstract » ne sera pas considérée par ArchGenXML comme un ContentType

• <<stub>> la classe ne sera pas associée à son workflow, si elle en a un

• <<folder>> permet de faire dériver la classe de BaseFolder

• <<ordered>> permet de faire dériver la classe de OrderedBaseFolder

Quelques tags :

• base_class : permet de spécifier de quelle classe on veut dériver, ex : OrderedBaseFolder

• additional_parents : permet de spécifier d'autres classes desquelles il faut dériver

• allowed_content_types : permet de définir les documents que la classe peut contenir, ex : « Image, Document »

Les relations entre classes :

Il existe une méthode plus claire pour définir les relations entre les classes que les stéréotypes sur les classes. Différentes relations (agrégation, composition et associations) permettent de définir à partir d'où un contenu va être accessible, les contenus qu'il va contenir et ceux vers qui il va pointer.

• Avec une agrégation, le contenu peut exister à la fois de façon globale et dans son contenant. ArchGenXML va dériver le contenant de BaseFolder et ses allowed_content_types vont être réglés sur les classes de contenu. Une agrégation est représentée par un losange vide.

• Avec une composition, les classes contenues n'existent que dans leur classe contenante. Si la classe contenante n'existe plus, la classe contenue ne peut pas exister. Le code généré par ArchGenXML est le même que pour une agrégation, mais la classe contenue ne peut être générée que dans la classe contenante. Une composition est représentée par un losange plein.

• Avec une référence, il devient possible d'avoir dans une classe, une référence vers une autre classe. Dans Plone, une référence vers la classe référencée apparaîtra en tant qu'attribut dans la classe qui référence.

En pratique :

Voici un exemple d'agrégation :
capture

Dans cet exemple, Artists est un contenant, il contient des instances de la classe Artist. Il ne sera pas possible de créer un artiste en dehors d'un répertoire Artists. Pour pouvoir créer un artiste dans Plone vous devrez donc d'abord vous placer dans un répertoire Artistes. Artists porte le stéréotype <<large>> pour dériver de BaseBTreeFolder et ainsi pouvoir contenir une grande quantité d'artistes.

Remplacer la relation d'agrégation par une composition générera exactement le même résultat, à une exception près : il sera possible de créer un artiste en dehors d'un répertoire Artists.

Voici un exemple de référence :

capture

Ici, Group contient une référence vers Artist, ce qui permet d'obtenir un champ Artistes dans le formulaire Group de Plone. Dans le modèle UML, il faut tagger « artist » dans la relation avec multiValued = 1 pour qu'un groupe puisse contenir plusieurs références vers des artistes. Le résultat dans Plone est visible ci-dessous.

capture

Un exemple de référence inverse (BackReference) : Il est possible que la classe Artist utilise la référence de Group vers Artist. Ainsi on verrait apparaître dans la fiche d'un artiste le(s) groupe(s) au(x)quel(s) il appartient. Pour cela, il suffit de créer dans la classe Artist un attribut « groups » de type Backreference. Il faut ensuite lui signaler la référence à utiliser avec le tag relationship. Ici nous préciserons aussi que la référence doit apparaître uniquement avec la méthode view de Artist avec le tag widget:visible et comme valeur : python:{'view':'visible','edit':'invisible'}. De cette façon la référence apparaîtra dans la fiche Artist, mais pas dans le formulaire d'édition d'Artist.

Voici le modèle UML :
capture

Résultat dans Plone de back-référence d'artist vers Group et d'artist vers CD :

capture

NOTE : Pour qu'ArchGenXML gère les BackReferences, il faut que le produit ATBackRef soit installé (disponible sur http://cvs.bluedynamics.org/viewcvs/ATBackRef/). Lorsque vous générez le produit avec ArchGenXML, vous devez rajouter l'option –backreferences-support=YES pour qu'ArchGenXML génère la BackReference.

7. Les workflows :

Description :

Les workflows permettent de gérer le cycle de vie d'un document, en tenant compte de ses différents états de vie, et des transitions qui unissent ces états.

Pour créer un workflow, il suffit de créer un diagramme d'états dans le modèle UML pour la classe à laquelle il doit s'appliquer. Pour créer un workflow « orphelin » (c'est à dire ne l'associer à aucune classe), il suffit de donner le stéréotype <<stub>> à sa classe mère. Le nom du workflow correspondra au nom du diagramme d'états. Pour associer une classe à un workflow, il suffit de lui rajouter le tag workflow = <nom du workflow>

Les états :

Un workflow possède différents états, dont un état par défaut. L'état initial du diagramme d'états correspondra à l'état par défaut du workflow. ArchGenXML ne gère pas l'état final. Votre diagramme d'états ne devra donc pas posséder d'état final. Le nom d'un état du workflow correspondra par défaut au nom de l'état correspondant dans le diagramme d'états. Il est néanmoins possible de faire apparaître un autre nom d'état à l'utilisateur, avec le tag « label ». L'état initial doit être représenté par un état normal avec le tag initial_state=1 si vous voulez que certaines transitions reviennent vers lui.

Les transitions :

Un objet passe d'un état du workflow à un autre par une transition. On peut restreindre les transitions à certaines permissions au niveau de Plone. Par exemple rendre la transition « valider » utilisable uniquement par un modérateur ou un relecteur. Il est aussi possible d'ajouter des actions à effectuer avant ou après l'exécution d'une transition (par exemple quand un document passe de « brouillon » à « en cours de validation » il doit être signalé aux relecteurs qu'ils ont un document à relire.

Il est évidemment possible de modifier le nom d'apparition de la transition dans Plone, avec le tag label.

Chaque transition possède un champ « garde ». C'est dans ce champ que devront être définies les caractéristiques à prendre en charge par ArchGenXML, par exemple les permissions.

Les actions :

Lors d'une transition, il est possible d'exécuter une action. Cette action peut se dérouler avant ou après la transition. Il suffit de spécifier dans le champ « effet » le nom d'une méthode python à lancer. Par défaut l'action s'effectuera après la transition. Pour avoir deux actions (une pré et une post action) il suffit de les séparer par « ; » ex: preaction;postaction. Pour préciser uniquement une préaction, faites-la suivre par « ; ». ex : preaction;

Le script python à compléter se trouvera dans Extension/<nom du workflow>_scripts.py

Les permissions sur les transitions :

Les permissions d'une transition sont définies dans son champ « guard ». Voici les trois plus importantes :

• guard_roles : elle permet de restreindre la transition à certains rôles. Par exemple guard_roles:Owner;Manager restreint la transition aux utilisateurs avec le rôle Owner ou Manager.

• guard_permissions : elle permet de restreindre la transition à certaines permissions. « guard_permissions:View » ne laisse possible la transition qu'avec les utilisateurs qui ont la permission « view » sur l'objet.

• guard_expr : permet de définir à quelle condition la transition peut être utilisée. Par exemple pour interdire de changer le statut d'un cd épuisé en cd disponible s'il n'est plus en stock.

Ces permissions peuvent être combinées en une seule ligne avec le séparateur « | », par exemple « guard_roles:Owner:Manager|guard_permissions:View »

Les permissions sur les états :

Les permissions sur les états permettent de définir les utilisateurs qui ont accès à certaines opérations d'un objet. Par exemple il est souhaitable qu'un objet dans l'état « hiden » ne soit visible que par son créateur et éventuellement par l'administrateur. De même il est impensable que n'importe qui puisse modifier les contenus.

Il existe trois types de permissions différents :

• Access contents information : permet l'accès aux méta-données et au contenu d'un objet (date de dernière édition, historique des états...). Un utilisateur qui ne possède pas cette permission ne peut voir l'objet que dans des formulaires de recherche ou dans l'arborescence du site, mais ne pourra pas accéder à son contenu. Il est juste informé de sa présence. Cette permission se représente par le tag access

• Modify portal content : permet de modifier le contenu d'un objet. Cette permission se défini dans ArchGenXML avec le tag modify

• View : permet de voir un objet dans l'arborescence du site mais pas d'accéder à son contenu. Cette permission est complémentaire à Access contents information : elle permet de savoir qu'un élément existe, et Access permet de voir le contenu de cet élément. Cette permission se représente dans ArchGenXML avec le tag view.

Il suffit dans chaque tag de préciser les rôles qui ont accès aux permissions. ex : « modify=Manager,Owner » pour rendre l'édition uniquement accessible à l'administrateur et au propriétaire/auteur de l'objet.

En pratique :

Comme créer un nouveau workflow sur un artiste ou sur un groupe a peu de sens, nous allons commencer par créer une nouvelle classe « cd » pour lui appliquer par la suite un workflow.

Un cd possède un titre, un type (single, best of, album), un nombre de pièces en stock et concerne un artiste référencé dans le site. Pour plus de lisibilité, les cds seront stockés dans un catalogue.

capture

Création du diagramme d'états :

Nous allons ensuite commencer à établir le workflow d'un cd. Créez un diagramme d'états pour la classe cd. Un cd aura les états suivants : hiden, available (quand il est en stock), unavailable (plus en stock) et visible. L'état par défaut sera l'état hiden. Pour le moment nous allons nous contenter de définir les états et les transitions, sans plus.

capture

    Et au niveau de Plone :

    capture

Automatisation des transitions :

Pour le moment les transitions make_available et make_unavailable ne se basent pas sur le stock et doivent être effectuées par un utilisateur. Nous allons maintenant nous arranger pour que ces transitions se fassent automatiquement en fonction du stock.

Rajoutez un tag « trigger_type » = 0 sur les transitions make_available et make_unavailable pour rendre leur application automatique. Il faut ensuite préciser dans le workflow quand ces transitions doivent être exécutées. Pour cela nous allons rajouter dans le champ guard l'expression « guard_expr:python:object.stock>0 » dans la transition make_available, et « guard_expr:python:object.stock<1 » dans la transition make_unavailable.

capture

Plone effectuera automatiquement la transition en fonction du stock quand l'objet se trouve en état « visible » . L'utilisateur pourra uniquement effectuer les transitions « retract » et « publish ».

Modification de l'état en fonction de l'évolution du stock :

Malheureusement, DCWorkflow ne permet pas d'enchaîner deux transitions automatiques en suivant. Une transition automatique ne peut être mise que sur un état qui a des transitions non-automatiques en entrée. Il n'est donc pas possible de rajouter une transition automatique entre l'état « unavailable » et « available » qui s'effectue en fonction du stock.

Un problème se pose donc : si on modifie le stock d'un CD, son état ne changera pas. Il devient donc possible d'avoir des CD's avec 0 unités en stock qui se retrouvent dans l'état « available » !

Une solution consiste à rajouter un état « edit » et de permettre la modification d'un CD uniquement dans cet état. Ainsi l'utilisateur est obligé de sortir le cd de l'état « available » ou « unavailable » pour pouvoir le modifier, il ne sera plus possible d'avoir des CD dans un état qui ne reflète pas leur stock.

capture

Modification des permissions sur les états :

Nous avons rajouté le nouvel état « edit » et ses transitions, mais il faut maintenant rendre l'édition de CD impossible dans les autres états (sauf pour l'état « hiden », un peu similaire à l'état « edit »).

Rajoutons le tag modify=none sur les états « available » « unavailable » et « visible ». Le rôle « none » n'existe pas et sera créé par ArchGenXML, mais c'est le seul moyen pour « forcer » ArchGenXML à ne pas cocher « acquire permissions settings » pour cette permission (avec acquire permissions settings, l'onglet édition est encore accessible). Il faudra évidemment ne pas assigner le rôle « none » à un utilisateur, sinon il aura accès à l'édition de CD...

Rajoutons ensuite le tag modify=Manager,Owner et view=Manager,Owner dans les états « edit » et « hiden »pour rendre un CD en édition uniquement accessible aux Manager et Owner. Il ne sera également visible que par le Manager et l'Owner.

capture

Dans Plone, avec le rôle manager et un CD dans l'état « available », vous obtiendrez ceci :

capture

8. Méthodes :

Les méthodes permettent d'associer des fonctions à une classe précise. Elles se créent en ajoutant une méthode dans le modèle UML. Ces méthodes peuvent avoir 4 « visibilités » différentes :

• public : la méthode est accessible depuis le site Plone

• protected : la méthode n'apparaît pas dans le site Plone, mais peut être utilisée dans le code python

• private : la méthode est interne à sa classe

• package : permet l'accès à la méthode par d'autres classes du module

Les tags :

• code : permet de définir le code du corps de la méthode

• documentation : documentation de la fonction python (ce qui apparaît entre 3 «  dans une fonction python)

• permission : définit les permissions nécessaires pour accéder à la méthode. ex : python:CMFCorePermissions.View (attention il faut importer CMFCorePermissions). Pour pouvoir définir les permissions, il faut que votre fonction soit en mode « public »

• imports : permet d'importer différents modules. Ex : from Products.CMFCore import CMFCorePermissions

    Les actions :

Les actions sont des méthodes qui apparaissent en tant qu'onglets dans Plone. Plusieurs actions sont définies par défaut, comme l'action View ou Edit.

En pratique : un onglet pour lancer le python debugger :

Nous allons créer un onglet qui lance le débugger python quand on clique dessus. Le débugger python permet d'accéder directement aux méthodes et fonctions des produits lancés dans Zope. Il devient ainsi possible d'accéder aux variables des produits (pour trouver d'où vient un bug par exemple), ou de lister toutes les méthodes d'un objet (par exemple toutes les fonctions relatives à DCWorkflow)

Commençons par rajouter une méthode à une classe, par exemple à la classe CD. Nommons cette classe « pause ».

Rajoutons-lui un tag imports avec la valeur « From Products.CMFCore import CMFCorePermissions » et un tag permission avec la valeur CMFCorePermissions.View (pour rendre l'onglet accessible aux utilisateurs qui possèdent les droits d'affichage). (*)

Générez le produit avec ArchGenXML et allez éditer CD.py. ArchGenXML aura défini une fonction pause, avec un corps vide. Complétez-la comme suit :

def pause(self):

import pdb

pdb.set_trace()

Le corps de la fonction pause ne sera pas modifié par ArchGenXML lors des futures mises à jour.

(*) Note : A l'heure où j'écris ce tutoriel, ArchGenXML gère mal le tag imports. Il faut rajouter manuellement les importations dans le code, entre les balises ##code-section module-header et ##/code-section module-header. Dans notre cas, rajoutez From Products.CMFCore import CMFCorePermissions.

Vous devriez obtenir ceci dans Poseidon :

capture

Dans Plone l'onglet pause sur un cd :

capture

 Ici l'onglet pause a été « cliqué », ce qui met le site en attente (l'onglet de firefox indique un site en chargement). Si vous allez dans le terminal de Zope, vous trouverez une console pdb où vous pouvez manipuler le code python du Zope actif.

9. Documentation :

Quelques liens :

http://www.zope.org/Members/hathawsh/DCWorkflow_docs documentation sur les workflows (méthodes python à utiliser,...)

http://plone.org/documentation/tutorial/archgenxml-getting-started/tagged-value-overview liste de tous les labels de ArchGenXML.

http://www.jazkarta.com un site où vous pourrez trouver un pdf qui explique comment utiliser ArchGenXML pour créer un site de communauté musicale.

Documentation interne à ArchGenXML :

Il existe une documentation interne au code de ArchGenXML. Elle est plus complète que les documentations disponibles sur internet, car directement mise à jour par les développeurs d'ArchGenXML.

Pour accéder à la documentation sur les tags, lancez une console python. Importez ceci : from TaggedValueSupport import tgvRegistry. Ensuite entrez la commande print tgvRegistry.documentation()

Pour accéder à la documentation sur les stéréotypes, importez from StereotypeSupport import stereotypeRegistry. Ensuite lancez la commande print stereotypeRegistry.documentation()

Note : A l'heure actuelle la documentation sur les stéréotypes contient des erreurs de scripting, en effet le paquetage StereotypeSupport.py contient beaucoup d'erreurs de syntaxe. Elle sera probablement débuggée dans le futur.

Options de compilation d'ArchGenXML :

Il est possible lors de la génération du produit, d'indiquer certaines tâches à faire (ou à ne pas faire) à ArchGenXML. Par exemple pour pouvoir générer des BackReference, il faut au préalable rajouter l'option –backreferences-support=YES dans la ligne de commande.

La liste des options disponibles est disponible avec l'option –help.

Les sources du produit du tutoriel :

Le modèle UML du produit utilisé dans le tutoriel est disponible dans le fichier ArtistSite.zuml