Génération de code JAVA

1. 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

2. 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

3. 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.

4. 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…

5. Étape 2: Vérification du modèle • La procédure de 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.

6. 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 automatiquement

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

8. 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, vous devez mettre en oeuvre 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.

9. 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 »

10. É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) • 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

11. É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

12. 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 »

13. 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 »

14. 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"

15. Remarque • 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

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

17. 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 nouveaumodèle (option par défaut) contenant les objets convertis • MàJ un modèle existant, issu d’une ancienne génération

18. 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)

19. 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)

20. Créer un identifiant double-clic

21. 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.

22. Création d’une clef relative Fenêtre de la Classe

23. 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.

24. 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)

25. Sélection des tâches (tâches à exécuter lors de la génération) On peut ne rien sélectionner ! Bien souvent le code java devra être complété

26. Résultats

27. Sérialisation + 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 Pour l’application DA :… ou encore ODBC

28. ODBC + avantages du SGBD (données cohérentes, clefs, jointures…) + on utilise ACCESS, plus simple et OK chez soi Procédure d’installation pas vue en cours ? Pour l’application DA :sérialisation, JDBC ou ….

29. 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…

30. Configuration avec l’item Variables • boîte de dialogue Options générales (menu Outils)

31. Options de génération pour Java OptionsPourDescription Critère principal de tri des membres de classe Java Trie les attributs et opérations par type ou par visibilité 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 CMP dans les interfaces de composant EJB Génère des opérations Get et 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.

32. 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 le modèle initial !