Génération de code

Génération de code

Nous avons comparé au chapitre 3 la sémantique UML avec la sémantique Java. Nous avons alors proposé des règles de correspondance permettant de construire automatique- ment une partie d’un modèle UML à partir d’une application Java. Soulignons que ces règles représentent une façon parmi d’autres de passer de Java vers UML. Elles consti- tuent un des ponts sémantiques de Java vers UML.Dans le présent chapitre, nous allons proposer un pont sémantique inverse, permettant de construire automatiquement une application Java à partir d’un modèle UML. Ce pont permettra de réaliser l’opération de génération de code Java à partir de modèles UML.À toute propriété d’une classe UML doit correspondre un attribut appartenant à la classe Java correspondant à la classe UML. Le nom de l’attribut doit être le même que le nom de la propriété. Le type de l’attribut doit être une correspondance Java du type de la propriété UML. Si le nombre maximal de valeurs pouvant être portées par la propriété est supérieur à 1, l’attribut Java est un tableau.À toute opération d’une classe UML doit correspondre une opération appartenant à la classe Java correspondant à la classe UML. Les noms des opérations doivent être les mêmes. Étant donné que Java ne supporte que les directions in et return, si l’opéra- tion contient des paramètres de direction out ou inout, nous considérons qu’il n’est pas possible de générer du code Java. Sinon, pour chaque paramètre de l’opération UML dont la direction est in doit correspondre un paramètre de l’opération Java. Les noms des paramètres doivent être les mêmes. Les types des paramètres doivent être une correspondance Java des types des paramètres UML. Si l’opération UML contient un paramètre de direction return, l’opération Java doit définir un retour qui lui correspond. Si l’opération UML ne contient pas de paramètre de direction return, l’opération Java retourne void.

Si une classe UML A est associée à une classe UML B et que l’association soit navi- gable, il doit correspondre un attribut dans la classe Java correspondant à la classe UML A. Le nom de l’attribut doit correspondre au nom du rôle de l’association. Le type de l’attribut doit être une correspondance Java de la classe UML B associée. Si l’association spécifie que le nombre maximal d’objets pouvant être reliés est supé- rieur à 1, l’attribut Java est un tableau. Si l’association n’est pas navigable, nous considérons qu’il n’est pas possible de générer du code Java.Si une classe UML hérite d’une autre classe UML, il doit correspondre une relation d’héritage (extends en Java) entre les classes Java correspondantes. Comme Java ne supporte pas l’héritage multiple, si une classe UML hérite de plusieurs autres classes UML, nous considérons qu’il n’est pas possible de générer du code Java.Lorsque nous avons défini notre opération de Reverse Engineering, nous avons précisé que le code des traitements associés aux opérations était intégré au modèle à l’aide de notes UML. Nous pouvons donc ajouter la règle suivante à nos règles de génération de code, qui ne sera exploitable que si le modèle contient des notes de code (ce qui est garanti si le modèle UML est obtenu à partir d’une opération de Reverse Engineering) :

Si une classe UML est associée à une autre classe UML et que l’association soit navi- gable, il doit se trouver un attribut dans la classe Java correspondant à la classe UML. Le nom de l’attribut doit correspondre au nom du rôle de l’association. Si l’association spécifie que le nombre maximal d’objets pouvant être reliés est supérieur à 1, le type de l’attribut Java est de type ArrayList. Sinon, le type de l’attribut doit être une corres- pondance Java de la classe UML associée. Si l’association n’est pas navigable, nous considérons qu’il n’est pas possible de générer du code Java.Notons pour finir que ces règles de correspondances ne prennent pas en compte la sémantique de contenance des associations, Java ne supportant pas un tel concept. Nous considérons donc qu’il est impossible de générer du code Java si le modèle UML contient des associations d’agrégation ou de composition.En résumé, les règles de correspondances que nous venons de présenter permettent de décrire brièvement le fonctionnement d’une opération de génération de code Java à partir de modèles UML. Contrairement aux règles de l’opération de Reverse Engineering, ces règles contiennent des contraintes sur la nature des modèles UML à partir desquels peut se faire la génération. Par exemple, il n’est pas possible de générer du code Java si des classes du modèle UML ont des héritages multiples ou si les opérations du modèle UML utilisent les directions out ou inout.