Génération de code JAVA Module Application de Synthèse UML/JAVA Génération de code JAVA à partir d’un modèle UML sous PowerAMC V. Deslandres, IUTA Lyon

Introduction Génération totale ou restreinte La génération de code, ça n’est pas immédiat : processus en 3 étapes Compléter le modèle d’analyse (nous, on se limite au diagramme de classes) modèle de conception Vérifier le modèle Générer le code module UML/JAVA

Génération partielle de code Il est possible de restreindre la portée de la génération au contenu d'un package particulier C’est très utile lorsque les différents packages sont affectés à différents développeurs. Chacun d'entre eux peut alors générer son package indépendamment des autres. La génération depuis un package permet de produire un modèle indépendant. module UML/JAVA

Processus de génération de code 3 étapes : Étape 1: Ajouter au MOO d’analyse les détails d’implémentation nécessaires pour obtenir un MOO dit « de conception » : Identifiants Types des données, visibilité Supprimer les relations entre les classes et les transformer en attributs Migrer un rôle navigable en tant qu'attribut dans une classe Définir les objets persistants Classes « techniques » (calendrier, classes abstraites, design pattern…) Etc… module UML/JAVA

Étape 2: Vérification du modèle Dans un AGL, la génération de fichiers source .java, d'objets PowerBuilder, ou de fichiers XML commence toujours par une vérification de la validité du MOO Si le modèle est incorrect ou si une erreur est détectée, la génération est interrompue. module UML/JAVA

Paramétrage de la vérification Les erreurs et avertissements sont affichés dans la fenêtre Paramètres de vérification du modèle. Vous pouvez définir le degré de sévérité pour les problèmes que la vérification détecte et faire en sorte que certains problèmes soient corrigés automati-quement module UML/JAVA

Degré de sévérité de la vérification En cliquant sur les icônes, on ajuste la sévérité à la règle erreur avertissement correction automatique par l’AGL module UML/JAVA

Règles de vérification de PowerAMC Par exemple: Les noms et les codes de classe doivent être uniques dans le modèle ou le package (dans le même espace de nom) Correction auto: modifie le nom ou le code de classe en y ajoutant un numéro Lorsqu'il existe une réalisation entre une classe et une interface (au sens java), vous devez mettre en œuvre les opérations de l'interface au sein de la classe Les fichiers externes incorporés dans les classes doivent avoir un chemin d'accès valide Etc. module UML/JAVA

Règles de vérification de PowerAMC Pour voir toutes les règles de vérification du modèle MOO : Regarder « Guide de l’utilisateur » Chapitre 14 – Gestion des MOO Page « Objets contrôlés lors de la vérification de modèle » module UML/JAVA

Étape 3 du Processus : génération de code vers un SGBD Une fois le MOO complété et vérifié… deux alternatives : Si on désire utiliser un SGBD et JDBC: Depuis le MOO de conception, générer d’abord un Modèle Physique de Données (MPD) qui réalise la correspondance ‘objet  relationnel’ Générer ensuite les tables de la Base de Données avec le SGBD souhaité Rq: on peut choisir le SGBD lors de la génération du MPD (Cette opération est détaillée ci-après) module UML/JAVA

Étape 3 avec des fichiers Si on souhaite fonctionner avec des fichiers (sérialiser les objets créés lors de l’application Java) : Générer directement les classes Java depuis le MOO Conception module UML/JAVA

Correspondance objet-relationnel La correspondance O/R permet de gérer la persistance des objets dans une base de données relationnelle. Ainsi dans un MOO, vous pouvez lier des classes à des tables en générant, dans PowerAMC, un modèle physique de données, à partir du modèle orienté objet cette opération est appelée « correspondance objet-relationnel » module UML/JAVA

Correspondance Objet/Relationnel MPD Classe  Table Attribut  Colonne Opération  Requêtes SELECT ou UPDATE associées à une table Association  Référence, référence de vue, table ou vue La correspondance O/R permet notamment : de définir les requêtes SQL pour les opérations des classes concernées Deux types de correspondances : Automatiques Définies par l’utilisateur Cf Guide Utilisateur, Chapitre 14 - MOO, « Mise en correspondance d'objets dans un MOO » module UML/JAVA

Attention ! Création des noms de tables avec guillemets ! (fonction de la version du SGBD mentionnée ??)  utiliser les guillemets aussi dans les ordres SQL select * from "Article" module UML/JAVA

Remarque : d’un MOO à un autre Si on veut implémenter le modèle d’analyse avec différents langages (.NET, XML, JAVA) : mieux vaut générer un MOO d’abord par type d’implémentation avant de transformer le MOO d’analyse en MOO de conception Puis faire la génération de code depuis chaque MOO obtenu module UML/JAVA

Générer plusieurs MOO Phase d’analyse Phase de conception (VB.NET) (XML) (Java) génération de modèles génération de codes code VB.NET Fichiers XML Classes Java Phase d’analyse Phase de conception Phase de mise en œuvre module UML/JAVA

Sur la génération de modèles à partir du MOO… On peut donc générer à partir d’un MOO : des MPD, d’autres MOO, mais aussi des MCD ! Deux possibilités depuis le MOO : Créer un nouveau modèle (option par défaut) contenant les objets convertis MàJ un modèle existant, issu d’une ancienne génération module UML/JAVA

MàJ un modèle généré précédemment En fait l’AGL va créer un modèle par défaut contenant les objets convertis depuis le MOO puis les fusionner ensuite dans un modèle existant. Des options sont disponibles pour la fusion : vous pouvez choisir de mettre à jour, supprimer ou ajouter des objets dans le modèle existant (modèle à fusionner, dans le volet droit) en fonction des modifications apportées dans le modèle par défaut (dans le volet gauche) module UML/JAVA

Modèle de conception Définir les identifiants Identifiant de MOO = clef primaire de MPD Fenêtre Propriété de l’attribut Case à cocher dans l’onglet Détail : « identifiant primaire » On obtient la fenêtre Propriété en cliquant sur l’attribut de la classe dans le navigateur d’objet (ou Double clic sur la ligne de l’attribut depuis la fenêtre Propriété de la Classe) module UML/JAVA

Créer un identifiant double-clic module UML/JAVA

Modèle de conception Identifiants combinés (clef relative) Lorsqu’un identifiant est défini à partir d’une combinaison d'attributs de classe Créer un nouvel identifiant pour la classe (onglet Identifiant), puis cliquer sur l'outil Afficher les propriétés. Cliquer sur l'onglet Attributs Cliquer sur l'outil Ajouter des attributs et sélectionner les attributs qui composent l’identifiant module UML/JAVA

Création d’une clef relative Fenêtre de la Classe Ceci est un exemple… On peut aussi préférer créer un identifiant de DA propre module UML/JAVA

Génération de code JAVA Vous pouvez générer des fichiers source Java à partir des classes et interfaces d'un modèle Classes que vous aurez sélectionnées Un fichier séparé, doté du suffixe .java, est généré pour chaque classe ou interface choisie Un fichier de génération est également créé. Vous ne pouvez générer du code qu'à partir d'un seul modèle à la fois. Rappel : une source Java peut contenir plusieurs classes, alors qu'un fichier Java .class ne peut contenir qu'une seule classe. module UML/JAVA

Pour générer le code Java Depuis le MOO conception : Sélectionnez Langage-Générer du code Java pour afficher la boîte de dialogue de génération. (Sélectionner les classes voulues en cas de génération restreinte) module UML/JAVA

Sélection des tâches (tâches à exécuter lors de la génération) On peut ne rien sélectionner d’autre ! Bien souvent le code java devra être complété module UML/JAVA

Résultats module UML/JAVA

Pour l’application DA : sérialisation, JDBC ou …. + on connaît déjà + c’est facile + pas besoin d’ORACLE pour faire tourner - pas de SGBD (on doit gérer soi-même la cohérence des données) - Moins bien noté dans l’évaluation JDBC + on met en œuvre ce qu’on n’a qu’entrevu + avantages du SGBD (données cohérentes, clefs, jointures…) + MySQL server, OK chez soi + mieux noté dans l’évaluation Plus complexe Choix d’ORACLE : exécution solo à l’IUT module UML/JAVA

Pour l’application DA : … ou encore ODBC + avantages du SGBD (données cohérentes, clefs, jointures…) + on utilise ACCESS, plus simple et OK chez soi ACCESS : pas top (Solution de facilité) Procédure d’installation : pas possible sur tous les postes (droits d’ajouts pilote ODBC) Ça reste assez simple tout de même !! module UML/JAVA

Configuration On a la possibilité de définir les exécutables Java qui seront utilisés dans le processus de génération de code jar, java, javac, javadoc… module UML/JAVA

Configuration avec l’item Variables boîte de dialogue Options générales (menu Outils) module UML/JAVA

Options de génération pour Java Options Pour Description Génération des imports de package Java A utiliser pour déclarer l'importation de tout le package Tri des membres de classe par type Java Trie les attributs et opérations par type d’abord Tri des membres de classe par visibilité Java Trie les attributs et opérations par visibilité Génération du fichier build.xml Ant Java Génère le fichier build.xml. (Vous pouvez utiliser ce fichier si vous avez installé Ant) Génération d'opérations Get et Set de champ EJB Génère des opérations Get et CMP dans les interfaces de composant Set de champ CMP dans les interfaces EJB Génération d'opérations Get et Set de champ CMR dans les interfaces de composant EJB Génère des opérations Get et Set de champ CMR dans les interfaces EJB Ajout du code source des classes Java dans le fichier JAR EJB Inclut le code des classes Java dans le fichier JAR Etc. Ant est un outil de compilation (comme Make) qui utilise un script nommé 'build.xml‘ On peut télécharger le package Ant à partir du site Web d'Apache (www.apache.org). module UML/JAVA

Reverse Engineering Pour ceux qui auront fini Une fois l’application réalisée en JAVA, reconstruire le modèle UML associé par « Reverse Engineering » et comparer avec votre modèle initial ! module UML/JAVA