Contents

Introduction

BlueXML permet réellement de créer un ERP adapté et adaptable à vos activités et à votre structure. Cette présentation définit comment BlueXML utilise une approche MDA pour obtenir un ERP totalement généré pour une entreprise grâce à l'approche MDA. Nous définirons quel est le formalisme utilisé ainsi que les différents diagrammes. Nous verrons la cohérence entre les modèles rédigés et l'ERP obtenu. Nous verrons également quels outils peuvent être utilisés pour modéliser.

Approche MDA

ApprocheMDA MDA.jpg

Tout d'abord, on va définir ce qu'est l'approche MDA (Model Driven Architecture), c'est-à-dire architecture dirigée par les modèles. A partir de modèles basés sur le domaine fonctionnel, on génère un ERP qui est une image de ces modèles. Cet approche permet de s'adapter à tous les contextes et d'obtenir une application personnalisée pour chaque entreprise sans développement supplémentaire. On a dépassé l'époque où les développeurs créaient une application de A à Z mais l'objectif est de générer cette application simplement et de la faire évoluer de la même manière.

ApprocheMDA MDA2.jpg

L'approche MDA est organisée de cette manière : on rédige les modèles qui sont une représentation des activités d'une entreprise ; on intègre ces modèles dans le générateur BlueXML et on obtient un ERP qui est une image des modèles rédigés. Les modèles pourront servir par la suite pour générer d'autres outils par exemple ou de changer de technologie. Pour résumer, l'approche MDA, c'est pouvoir générer une application à partir de modèles.

Formalisme utilisé

Nous allons définir maintenant quel est le formalisme utilisé pour rédiger ces modèles. On a un formalisme assez proche de celui fourni par UML.

Formalisme UML

Pour résumer, UML (Unified Modeling Language) est un langage de modélisation graphique largement répandu dans le domaine de l'informatique. Il est très complet et comprend 13 types de diagrammes pour UML1. C'est un formalisme assez lourd à appréhender et à prendre en main de manière optimale. UML est un formalisme très abouti et non propriétaire régi par l'OMG (Object Management Group).

ApprocheMDA UML1.jpg

Voici l'arborescence des diagrammes fourni dans le formalisme UML1. On s'aperçoit que la couverture fonctionnelle est énorme mais certains diagrammes sont inutiles pour une génération d'un ERP. De plus, certains concepts sont absents et nous permettent pas de représenter convenablement la configuration de l'ERP souhaité.

Lien : http://www.uml.org/

Formalisme BlueXML

Pour obtenir un modèle propre, BlueXML a défini son propre formalisme qui reprend certains concepts UML afin de ne pas réinventer des concepts déjà existants. De plus, on y a ajouté des concepts supplémentaires comme les méta-informations ou informations supplémentaires permettant par exemple de configurer l'affichage des formulaires.

ApprocheMDA MetaModele OBL.jpg

Voici le formalisme défini par BlueXML, il est en effet très simple car il contient seulement une vingtaine d'éléments. Pour comparer, le formalisme UML contient plusieurs centaines d'éléments. Ce formalisme simplifié permet donc un apprentissage rapide afin d'accélérer la modélisation et de se concentrer réellement sur le domaine fonctionnel.

Les différents types de diagrammes

  • Les cas d'utilisation
    • Définition globale du portail
    • Organisation des différentes « portlets »
    • Création des différents types d'utilisateurs
    • Définition des droits d'accès
  • Les diagrammes de classes
    • Définition des données
    • Définition de la représentation graphique
    • Définition de contraintes spécifiques

Seulement 2 types de diagrammes sont présents dans le formalisme d'BlueXML. Le premier type de diagramme est le diagramme de cas d'utilisation qui permet de définir globalement le portail, l'organisation des portlets (ou brique du portail), les différents types d'utilisateurs (DRH, chef d'atelier...) ainsi que les droits d'accès (un DRH n'aura pas accès aux mêmes fonctionnalités qu'un chef d'atelier).

Le second type de diagramme est le diagramme de classes qui permet de définir les concepts manipulés dans le domaine fonctionnel ainsi que des contraintes supplémentaires comme des contraintes de visualisation.

Voici comment se situe le formalisme BlueXML par rapport à UML, on a sélectionné l'essentiel des diagrammes afin d'obtenir des modèles de configuration simples et centrés sur le domaine fonctionnel.

Les cas d'utilisation

Formalisme

Quels sont les éléments concernés par ce type de diagramme ?

  • Acteur (ou Profile) : représente un type d'utilisateur,
  • Cas d'utilisation : représente un niveau dans l'arborescence du portail.

On va voir quels sont les éléments principaux d'un diagramme de cas d'utilisation. Il y a 2 types d'éléments. Le premier élément est l'acteur représenté sous forme d'un bonhomme, permettant de représenter un rôle dans l'entreprise (DRH, chef d'atelier...). Le second élément est le cas d'utilisation, représenté sous forme d'une bulle, qui représente une grande fonction de l'entreprise. On définit simplement par un lien qu'un rôle a accès à un domaine fonctionnel précis qui contient ensuite des sous-domaines fonctionnels.

ApprocheMDA UC1.jpg

Génération

ApprocheMDA UC Generation.jpg

On peut voir sur ce diagramme un role "anonymous" qui est connecté à 7 grands domaines fonctionnels qui sont proposés sous forme de bannière.

ApprocheMDA UC Generation2.jpg

Un domaine fonctionnel peut bien avoir évidemment des sous-domaines fonctionnels afin de structurer les fonctions de l'ERP.

ApprocheMDA UC Generation3.jpg

Il faut ensuite définir des "portlets" (brique du portail) qui permettront de contenir des informations. Ces éléments peuvent avoir différentes représentations et on peut les organiser comme on le souhaite.

Les diagrammes de classe

Quels sont les éléments concernés par ce type de diagramme ?

  • Classe : élément comparable à un objet du domaine. Une classe possède également un ensemble d'attributs et d'opérations.
    • Domaine financier : un budget, un tableau de bord
    • Domaine immobilier : achat, vente, location
    • ...
  • Attribut : caractéristique d'un objet (couleur, taille, format)
  • Opération : action exécutable sur un objet. (par exemple : générer un rapport ou une note à partir d'un objet)

ApprocheMDA CD1.jpg

Sur cet exemple, on a une page HTML (la classe Html) qui contient deux caractéristiques qui sont l'ordre et le résumé. La classe Html hérite de la classe EmbeddedContent qui contient comme caractéristique le contenu de la page HTML. Comme un héritage classique, la classe Html hérite donc de la caractéristique contenu. De même, la classe Html hérite de la classe Content donc une page HTML possède une caractéristique de titre. Une page HTML est relié également à 3 nomenclatures (grâce à l'héritage) qui sont la langue, le pays et le statut (validé ou non). Une nomenclature est une liste finie de valeurs, une énumération. On peut imaginer la nomenclature Civilité avec comme valeur M, Mme et Mlle. La nomenclature Language nous permet donc d'obtenir un portail multilingue. Une page HTML contient également des catégories afin d'organiser les pages HTML.

ApprocheMDA CD Generation.jpg

Après la génération, on obtient notre formulaire dans lequel nous pourrons insérer les données. Toutes les caractéristiques du modèle sont bien présentes dans le formulaire. On peut évidemment faire évoluer ce modèle et donc l'ERP de la même manière.

La personnalisation du portail

On a pu voir que certains champs étaient représentés de différentes manières. C'est grâce à notre formalisme et aux méta-informations ou informations supplémentaires que l'on a pu ajouté des contraintes et plus particulièrement des contraintes de visualisation.

Ces informations supplémentaires nous permettent d'indiquer si c'est une zone de texte avec ou sans mise en forme possible, la taille du champ, s'il est obligatoire, s'il est caché...

Avec quels outils modéliser ?

Il est possible de modéliser vos diagrammes avec des éditeurs UML classiques libres (ArgoUML, Umbrello...) ou propriétaires (Rational Rose, MagicDraw...) ou avec l'éditeur spécifique développé par le projet BlueXML.

BlueXML Developer Studio

BlueXML a développé un éditeur spécifique afin de configurer l'ERP de manière optimale. C'est un plugin basé sur Eclipse donc portable sur la majorité des systèmes d'exploitation. C'est un éditeur totalement adapté à la création et à la configuration d'un ERP accompagné d'un ensemble de fonctionnalités afin de simplifier la gestion de modèles. Il manipule notre formalisme donc permet une configuration simple. Il est développé en accord et en adéquation avec le projet BlueXML donc suivra les évolutions du projet BlueXML.

Ensemble d'outils complémentaires :

  • Générateur de code Java
  • Générateur d'une documentation HTML
  • Exportation automatique des diagrammes sous forme d'image
  • Outil de recherche dans les modèles
  • Outil de recherche de diagramme

Technologies de pointe

On utilise pour cet éditeur des technologies de pointes :

ApprocheMDA Eclipse.jpg Eclipse Environnement de développement très répandu dans le domaine de l'informatique

http://www.eclipse.org/

ApprocheMDA Topcased.jpg Topcased Projet développé par Airbus qui nous a permis d'obtenir une amorce d'éditeur

http://www.topcased.org/
http://topcased-mm.gforge.enseeiht.fr/website/index.html

ApprocheMDA ATL.jpg ATL Technologie de transformation de modèles développée par l'Université de Nantes qui nous a permis de réaliser des transformations depuis UML1 et vers UML1 et UML2. Technologie intégrée actuellement à la majorité des outils MDA.

http://www.eclipse.org/m2m/atl/
http://www.sciences.univ-nantes.fr/lina/atl/

ApprocheMDA Acceleo.jpg Acceleo Technologie de génération de texte qui nous a permis d'obtenir les classes Java et qui est actuelllement intégré à Eclipse.

http://www.acceleo.org/pages/accueil/fr

Une solution ouverte

ApprocheMDA SolutionOuverte.jpg

BlueXML Developer Studio n'est pas une solution fermée. Grâce à la technolgie ATL, nous avons pu réaliser des importations depuis UML1 ainsi que des exportations vers UML1 et UML2. Ceci permet de changer d'éditeurs si on le souhaite et conserver ces modèles fonctionnels afin de les utiliser dans d'autres contextes.