Malgré l'envie qu'on peut en avoir, il ne suffit pas de cliquer le bouton «Generate>Java» qu'on voit apparaître dans le menu «Tools» ou dans les menus contextuels des packages et classes pour générer du code. En effet, depuis UML2, le passage du modèle UML au code se fait en passant par un modèle intermédiaire, le «modèle de déploiement» où à chaque classe on fait correspondre un artefact «source» qui va assurer entre autres la gestion du code interne et la connexion des classes avec des fichiers (on peut par exemple très bien ranger plusieurs classes dans un même fichier source).

• choisir le langage cible du projet : menu «Micellaneous > Java default definition»  cette opération est obligatoire, si un langage cible n'est pas sélectionné, aucune génération dans ce langage ne peut avoir lieu ;
• choisir des commentaires à la mode javadoc : menu «Project > Edit > Edit generation settings», sélectionner l'onglet «Java[1]» et cocher la case «Generate Javadoc style comment».

Le projet est organisé en paquetages qui traduisent l'architecture du programme. Dans chaque paquetage une Class_view va permettre la définition des classes et relations ; un ou plsieurs diagrammes de classes peuvent être associés à ces Class_views.

Lors de l'édition des classes, attributs, méthodes et relations, la sélection de l'onglet «Java» dans le panneau d'édition permet d'avoir une prévisualisation de la génération de code qui sera obtenue :

• vous constatez que les commentaires que vous avez mis dans le champ Description de l'onglet UML se retrouvent sous forme de commentaire Javadoc dans le code généré, vous avez donc intérêt à bien documenter ce champ au moment de la conception, ceci fera autant de temps gagné par la suite ;
• vous pouvez faire des adaptations de détail de génération en adaptant le modèle (template) présent dans le champ «Declaration».

Si, à ce stade vous essayez d'activer la génération de code (par «Generate > Java»), vous obtiendrez l'erreur : «C1 : does not have associated artifact». En UML 2 les artifacts représentent les fichiers sources, objet, librairie, exécutable, jar etc. La génération produit des fichiers source, et les artifacts sont utilisés pour dire quels sont ces fichiers sources.

Les artifacts doivent être placés dans une deployement_view que vous pouvez créer dans chaque paquetage ; habituellement, on crée une deployement_view correspondant à une class_view dans chaque paquetage (mais ça n'est pas une obligation).

Il faut alors associer les deployement_views aux class_views : ouvrez le dialogue d'édition de la class_view et sélectionnez pour le champ «deployement view» la deployement_view qui a été créée dans le même paquetage. Cette association faite, vous voyez apparaître dans le menu contextuel de chaque classe l'item «Create source artifact» qu'il vous suffit de sélectionner pour créer l'artifact «source» correspondant.

De fait chaque template de classe, méthode, etc peut être adapté individuellement comme nous l'avons vu précédemment, mais on peut également faire des modifications de génération qui vont affecter tout le projet en éditant les generation settings.