J'ai le plaisir de vous annoncer la première version officielle du module de génération Acceleo pour "Spring Framework". Il est disponible avec la toute nouvelle version d'Acceleo 2.2.

Le module Acceleo "JEE/Spring" se base sur une modélisation UML2 stéréotypée afin de générer des applications basée sur le socle technique Spring.

Il génère des applications respectant une architecture en couches :

  • Interface utilisateur
  • Objets de transferts
  • Services métiers
  • Accès au données


Présentation de la cible technique :

Spring est un conteneur dit « léger », c'est-à-dire une infrastructure similaire à un serveur d'application JEE. Il assure la logique de création des objets et la gestion leurs dépendances. L'intérêt majeur d'un tel conteneur réside essentiellement dans la possibilité de n'utiliser exclusivement que des POJO (objets java simple n'implémentant aucunes interfaces spécifiques). Il offre aussi la possibilité de réaliser un coupable faible entre les couches applicatives avec le programmation par interface tout en permettant de spécifier des traitements par déclaration au niveau de l'assemblage des dépendances; traitements tels que la sécurité, les transactions,... L'inconvénient majeur souvent avançé par ses détracteurs reste néanmoins l'utilisation de fichiers XML parfois complexes à maintenir afin de définir les dépendances.

Hibernate est un framework utilisable avec la plateforme JEE et permettant de gérer le mapping objet / relationnel, paradigme consistant à persister des objets dans une base de données relationelle.

Modélisation :


Le générateur JEE-Spring permet l'exploitation de modèles UML 2.1 enrichis d'un certain nombre de stéréotypes spécifiques et correspondant aux couches applicatives. Vous devez utiliser un modeleur compatible avec cette norme, Topcased correspondant à un outil de ce type et étant fournit avec la version bundle d'Acceleo.

Schéma d'architecture simplifié

SpringModule

La figure ci-dessus illustre les stéréotypes permettant de définir une sémantique particulière aux éléments UML. Dans le contexte d'architecture JEE, sont mis à disposition les différents stéréotypes suivants :

  • Le stéréotype <<Entity>> s'applique aux classes du domaine métier;
  • Le stéréotype <<Dao>> s'applique aux classes d'accès aux données implémentant la logique de sauvegarde et de restauration des entités du domaine;
  • Le stéréotype <<Service>> s'applique aux classes dîtes service métier ou encore traitement métier;
  • Le stéréotype <<Transactionnal>> s'applique aux opérations des services métiers afin de leur spécifier un comportement transactionnel. Les deux propriétés "isolation" et "propagation" sont offertes afin de préciser la stratégie de gestions des transactions;
  • Le stéréotype <<Remote>> s'applique aux opérations des services métiers afin de les exposer en tant que service web;
  • Le stéréotype <<Dto>> s'applique aux classes de transferts de données souvent utilisées en tant que paramètres de retour des méthodes de services.


Fonctionnalités du générateur


Au niveau de la couche de service :
  • Génération de l'ensemble des fichiers de configuration Spring
  • Possibilité d'utiliser des objets de transferts afin de constituer une couche de médiation
  • Gestion des transactions avec la programmation orientée aspect
  • Chargement paresseux des objets tout au long d'une même transaction (patron de conception "ThreadLocal Session")
  • Support de l'exposition de méthodes de services en tant que service Web à l'aide de l'outil XFire
  • Tests JUnit
Au niveau de la persistance :

Le générateur intègre les meilleures pratiques Hibernate afin de fournir une meilleure productivité et des performances optimales.

Navigation transparente entre les objets métiers

  • Héritage
  • Associations 1-1, 1-*, *-*
  • Navigabilité unidirectionnelle et bidirectionnelle
  • Optimisations
  • Utilisation de simples fichiers Java de type POJO

Mapping vers la base de données

  • Gestion du cache sur les données persistées
  • SQL en 3NF
  • Contraintes d'intégrité
  • Concurrence d'accès
  • Clef technique

Couche d'accès applicatif sur les données DAO

  • Couche dédiée à l'accès aux données et au requêtage
  • Pas de dépendance directe entre les objets métiers et Hibernate
  • Méthodes de recherche évoluées
  • Gestion des transactions
  • Tests JUnit


Démonstration :

L'installation du générateur est détaillée sur la page d'installation des modules.

Installez le projet de démonstration à l'aide du menu "Project ..", puis sélectionnez "JEE-Spring Demo" dans le menu "Examples/Acceleo" :

demo-1

L'assistant crée un nouveau projet "org.acceleo.sample.demo.spring" dans votre espace de travail.

  • Le répertoire src contient les sources générés;
  • Le répertoire resources contient les fichiers de configuration de Spring et d'Hibernate;
  • Le répertoire tests contient les tests unitaires;
  • Le répertoire lib contient les librairies utiles au bon fonctionnement du projet;
  • Le répertoire model contient :
    • Les fichiers conception.uml et conception.umldi correspondant au modèle de l'application;
    • Les fichiers profile.uml et profile.umldi correspondant au profile UML utilisé pour la génération;
  • Le fichier spring.chain permettant de lancer les opérations de génération;
  • Le fichier spring.properties permettant de spécifier les options de génération;

demo-2

Le modèle conception.umldi ci-dessous décrit :

  • Un <<Entity>> Product représentant la notion de produits, est composé des propriétés name et color,
  • Un <<Dao>> ProductsDao chargé des opérations de lecture et mise à jour des instance de produits. Les DAOs proposent systématiquement les méthodes CRUD (Create-Read-Update-Delete), ces dernières ne devant pas être modélisées. Il est toutefois possible d'ajouter des opérations tels que findProductByColor;
  • Un <<Service>> ProductsServices proposant les opérations métiers suivantes :
    • getListOfProducts : fournit la liste complète des produits
    • getProduct : retourne un produit à partir d'un identifiant donné. On notera que cette méthode est <<Remote>> et sera donc publiée en tant que service Web.
    • addProduct : ajoute un produit. On notera que cette méthode est <<Transactional>>, en cas d'erreur de traitement la base de donnée ne sera pas modifiée et restera donc intègre.
    • updateProduct : met à jour un produit
    • removeProduct : supprime un produit

Les dépendances modélisées représentent :

  • Du <<Service>> vers le <<Dao>> : l'instance du <<Dao>> doit être injectée dans le service.
  • Du <<Dao>> vers l'<<Entity>> : le <<Dao>> a la responsabilité de gérer l'<<Entity>> dépendante.

demo-3

Quelques exemples de fichiers générés :
  • Le fichier src/org/acceleo/sample/demo/spring/services/I_ProductsServices.java constitue l'interface Java du service :

demo-4

  • Le fichier src/org/acceleo/sample/demo/spring/services/I_ProductsServicesWebService.java constitue l'interface Java du service Web chargée d'exposer uniquement les méthodes <<Remote>> du service :

demo-5

  • Le fichier src/org/acceleo/sample/demo/spring/services/impl/ProductsServicesImpl.java constitue la classe Java chargée d'implémenter les deux interfaces du service :

demo-6

  • Le fichier resources/META-INF/spring/component.xml correspond au fichier principal de configuration de Spring. Ce dernier inclut l'ensemble des fichiers de configuration des différentes couches applicatives :

demo-7.png

  • Le fichier resources/META-INF/spring/org.acceleo.sample.demo.spring/layer-services.xml correspond au fichier de configuration de Spring définissant les objets de la couche de services métiers :

demo-8.png


Reste à faire & Contribuez ! :