Les classes et la génération de code sous Bouml

Nous voulons définir des classes dans le but de générer du code, pour cela nous devons premièrement créer une class view, et pour changer nous n'allons pas la placer directement dans le package projet. Pour cela affichons le menu du projet (clic droit sur foo dans le browser) choisissons new package, et nommons le package Package3. Appelez le menu de Package3 et choisissez new class view, et nommons-la Class view4 :

Créons un diagramme de classes via le menu de Class view4 et ouvrons ce nouveau diagramme :

Appuyez sur le bouton représentant une classe puis cliquez dans le diagramme (il est aussi possible de créer la classe via le menu de la class view dans le browser), appelez cette classe C1:

Parce les acteurs sont des classes, ceux-ci peuvent être ajoutés dans un diagramme de classe, via un drag and drop du browser dans le diagramme, ou en utilisant le bouton représentant une classe et en choisissant l'une d'elles dans la liste proposée, par exemple Administrator. Vous pouvez choisir un élément dans une liste défilante (combo box) soit en la parcourant via les flèches soit en tapant le premier caractère de son nom.

L'acteur est dessiné comme un acteur et non une classe standard, c'est ce qui se passe par défaut pour les classes ayant le stéréotype actor. Ceci n'est pas une obligation et peut être modifié via les drawing settings de la classe dans le diagramme, des dessins particuliers sont également utilisés pour les classes stéréotypées control, boundary et entity. On obtient donc :

Cependant, dans le mode par défaut les acteurs ne sont pas utilisés pour la génération de code, en effet par défaut le stéréotype de classe actor produit ignored dans les différents langages cibles. Pour continuer sans cette limitation, editez les generation settings allez dans l'intercalaire Stereotypes et remplacer ignored par class pour actor :

Nous voulons définir l'attribut att, et l'opération oper pour la classe C1. Appelez le menu de la classe, choisissez add attribute puis add operation. Lorsque vous ajoutez un membre de classe via le diagramme l'élément est automatiquement édité, ce n'est pas le cas via le browser. Les nouveaux éléments sont visibles dans le browser et le diagramme :

Comme vous le voyez att a la visibilité protected et l'opération est publique, car telles sont les visibilités par défaut définies via les class settings. Les class settings peuvent être positionnés au niveau de chaque package et class view et s'appliquent au sous-niveau qui ont la valeur default en suivant le même principe que celui des drawing settings comme cela a été décrit dans le précédent tutoriel.

Décidons que l'attribut att est un int, pour cela il faut l'éditer, ce qui peut être fait de différentes façons : double-clic dessus dans le browser, ou via son menu dans le browser, ou via le menu de C1 dans le diagramme en choisissant edit attribute puis att. On obtient :

Le premier intercalaire concerne les propriétés UML, comme vous le voyez, par défaut un attribut est un membre d'instance (pas un membre de classe), il est non volatile et non constant. Les autres intercalaires sont spécifiques à chaque langage de génération : avec BOUML vous pouvez définir des éléments simultanément en C++, JavaPhp et IDL. Par exemple le générateur de document HTML est un plug-out dont l'implémentation est faite en C++ et en Java, vous pouvez donc le modifier pour vos besoins propres dans votre langage préféré.

Changez le type en int, soit en choisissant parmi les types prédéfinis (modifiables via les generation settings) ou en tapant int.

Allez dans l'intercalaire C++ (en cliquant sur C++) :

Comme vous le voyez, la visibilité en C++ est celle indiquée au niveau UML, mais ce n'est pas une obligation et BOUML vous permet de ne pas avoir la même visibilité en C++, Java et IDL si vous le souhaitez. En C++, un attribut peut de plus être mutable.

Le texte affiché devant Declaration est éditable, pas celui en face de result after substitution qui montre ce que sera le code produit par le générateur C++ (sauf si vous modifiez ce dernier !). Exception faite des mots clefs signalés par ${} et les propriétés utilisateur (tagged values) signalées par @{}, tous les autres caractères sont générés inchangés, y compris les sauts de ligne. Il n'est pas très difficile de comprendre que ${type} est remplacé par int et ${name} par att, ces valeurs étant définies au niveau UML. Cela veut également dire que si vous remplacez ${type} par aze le type généré pour att en C++ sera aze, etc.

Allons dans l'intercalaire Java, le principe est le même, appliqué au langage Java :

La définition pour PHP et Idl n'est pas accessible. Pourquoi ? Rappelez-vous, au début de l'histoire (dans le premier tutoriel) je vous ai demandé de cocher C++ et Java dans le menu Langages, mais ni PHP ni IDL. Fermons le dialogue via OK, cochons PHP et IDL dans le menu Languages, rééditons l'attribut et allons dans l'intercalaire IDL :

La définition est vide, car IDL n'était pas coché lors de la création de l'attribut.

Appuyons sur le bouton Default State declaration, on obtient :

Premièrement la visibilité est privé et non protégé, car cette dernière n'existe pas en IDL.

D'autre part ${type} produit long plutôt que int, ceci permet de ne pas produire un code IDL faux et par défaut un int est traduit par long en IDL, magique, et surtout pratique !

Il y a d'autres conversions automatiquement faites par BOUML, par exemple si le type est any en UML vous aurez void * en C++, Object en Java et any en IDL. Bien évidemment ces conversions ne sont pas faites en dur et imposées par BOUML, elles sont définies et modifiables via les generation settings.

Allons dans l'intercalaire PHP, la définition est vide comme pour Idl, appuyons sur le bouton Default declaration, on obtient :

C'est une définition pour Php 5, si vous voulez produire du code pour Php 4 le mieux est de changer la visibilité (intercalaire UML) en package, et la définition devient :

Les définitions par défaut, par exemple celles des attributs, sont également modifiables via les generation settings, cela vous permet par exemple d'ajouter le '_' au nom de l'attribut en C++ comme ci-dessus dans la définition par défaut et non de le faire sur chaque attribut, ce qui serait particulièrement pénible. Je vous renvoie au manuel de référencemanuel de référence de Bouml pour plus de détails.

Faites OK pour valider les changements.

Par défaut dans un diagramme de classe seul le nom des attributs et opérations est visible, pas leur type ni leur visibilité. Appeler le menu de la classe dans le diagramme et changer trois drawing settings pour obtenir :

Le dessin de la classe devient :

N'hésitez à essayer les autres drawing settings, et lisez le manuel de référencemanuel de référence de Bouml pour plus de détails.

Nous voulons ajouter une association unidirectionnelle de C1 vers Administrator, appuyez sur le bouton correspondant et dessinez la relation comme vous l'aviez fait pour celles entre les use cases :

La relation est visible dans le browser, par défaut son nom est <unidirectional association>, éditez la relation :

Comme pour les attributs vous avez un intercalaire pour UML et chaque langage.

Parce que la relation est unidirectionnelle, seul un des deux rôles est éditable. De même que pour les attributs et opérations, la visibilité par défaut est spécifiée via les Class settings. Le nom du rôle produira le nom du membre lors de la génération de code, et nous retrouvons les mêmes propriétés que pour les attributs : du point de vue génération de code il n'y a pas de différences entre une relation et un attribut.

Changeons le nom en admin et allons dans l'intercalaire pour C++ :

Par défaut une association et une agrégation produisent un pointeur en C++, une agrégation par valeur ne produit pas de pointeur. Bien sûr ces définitions par défaut peuvent être modifiées via les generation settings ou juste au niveau de chaque relation en changeant le texte placé devant Declaration.

Allons dans l'intercalaire Java, évidemment pas de pointeur :

Allonsz dans l'intercalaire PHP :

Allez dans l'intercalaire PHP :

Retournons dans l'intercalaire UML, changeons d'abord le type de la relation pour avoir une association (bidirectionnelle) puis faisons les autres modifications pour avoir :

Allons dans l'intercalaire pour C++ et appuyons sur Default declaration pour les deux rôles, on obtient :

Allons dans l'intercalaire Java et appuyons sur Default declaration pour les deux rôles, on obtient :

Faisons de même pour IDL, on obtient :

Comme vous l'avez vu, les définitions par défaut tiennent naturellement compte du type de la relation et de la multiplicité, bien sûr tout est modifiable via les generation settings : vous décidez de ce qui doit être produit lors de la génération de code.

La façon dont les stéréotypes sont projetés pour chaque langage est également définie via les generation settings, ainsi vector produit vector en C++, Vector en Java, et sequence en IDL :

Validons les modifications de la relation et regardons le diagramme :

Parce que la relation est maintenant bidirectionnelle, celle-ci apparaît dans le browser sous C1 et Administrator (je les ai marqué dans le browser, c'est pourquoi elles sont rouges, les marques permettent de faire des sélections multiples dans le browser de façon plus résistante sans craindre un clic de travers les annulant).