Demain, tous développeurs?

L'approche DSML (Domain-Specific Modeling Languages)

Dans le monde du génie logiciel, un DSML est un langage de modélisation dédié à un domaine précis.

A l'inverse du MDA qui utilise des méthodologies de modélisation généraliste, la modélisation spécifique à un domaine (DSM) lui utilise une méthodologie qui est centrée sur un domaine spécifique et qui a pour but de perfectionner la productivité. L'idée c'est de baisser l'espace de conception afin d'avoir dans la plupart des cas une seule gamme de produit par organisation. Ainsi le niveau d'abstraction des modèles est élevé et la génération totale de l'implémentation sera sur mesure pour l'organisation, d'où le gain de productivité.

Le principe de la modélisation DSM est simple, et réside dans la notion de langage de modélisation spécifique à un domaine (Domain-Specific Modeling Language ou DSML). On rassemble l'ensemble des connaissances du domaine d'application dans un langage de modélisation qui lui est dédié, on en fait des modèles et à partir de ces modèles on génère du code.

L'approche DSML fait partie d'un environnement complet avec un générateur de code et un environnement d'exécution (framework) pour former les DSM.

Figure 14 : DSML

L'UML (Unified Modeling Language)

Entre 1989 et 1994 : le nombre de méthodes orientées objet est passé de 10 à plus de 50, où chacune proposait son propre langage de modélisation. Toutes ces méthodes avaient pourtant d'énormes points communs (objets, méthodes, paramètres, ...). Au milieu des années 90, UML est l'accomplissement de la fusion de précédents langages de modélisation objet : Booch, OMT, OOSE principalement issus des travaux de Grady Booch, James Rumbaugh et Ivar Jacobson. Les principales influences de l'UML sont :

· Booch : Catégories et sous-systèmes

· Embley : Classes singletons et objets composites

· Fusion : Description des opérations, numérotation des messages

· Gamma, et al. : Frameworks, patterns, et notes

· Harel : Automates (Statecharts)

· Jacobson : Cas d'utilisation (use cases)

· Meyer : Pré- et post-conditions

· Odell : Classification dynamique, éclairage sur les événements

· OMT : Associations

· Shlaer-Mellor : Cycle de vie des objets

· Wirfs-Brock : Responsabilités (CRC)

Figure 15 : Historique de l'UML

Aujourd'hui, UML est le langage de modélisation orienté objet (OO) le plus connu et le plus utilisé et s'applique à plusieurs domaines tels que : OO, RT, Déploiement, Requirement,... Peu d'utilisateurs connaissent le standard, ils ont une vision outillée d'UML (Vision Utilisateur) où 5% ont une forte compréhension, 45% une faible compréhension, 50% aucune compréhension.

Il y a trois utilisations possibles d'UML :

· Comme un langage pour faire des croquis, esquisses, ébauches... (explorer)

Probablement la manière dont UML est le plus utilisé aujourd'hui : pouvoir échanger, communiquer rapidement autour d'une idée où les modèles ne sont pas forcément à 100% complets. Ses objectifs sont d'analyser, réfléchir et décider (brainstorming)

· Comme un langage de spécification de modèles, patrons... (spécifier). On spécifie ici, des modèles complets, prêts à être codés, utilisés pour prendre des décisions poussées de design, des modèles issus du Reverse Engineering (afin de réfléchir dessus, d'améliorer la conception, de casser des dépendances, etc.). Il y a également une possibilité de faire du round-trip engineering (Génération de code et Reverse engineering)

· Comme langage de programmation (produire). Ici, on veut tout mettre dans le modèle, le modèle UML devient alors la source du code afin de pouvoir générer et compiler du code à partir du modèle.

C'est ce dernier point qui va nous intéresser.

La génération de code conduit à plus de productivité (la structure d'une centaine de classes, d'opérations, ... sont générés en un seul clic). Il y a également moins d'erreurs car le savoir faire est codé dans les générateurs de code.

Les principes d'un générateur de code consistent en :

· un ensemble de règles décrivant la correspondance entre concepts du modèle et concepts du langage (Java par exemple, voir ci-après).

· paramétrages d'option (dans certains cas/outils)

o Choix des constructions dans le langage cible (Vector ou ArrayList en JAVA)

o Générer les accesseurs et les constructeurs

o Implanter les méthodes abstraites

· Un moteur de génération de code avec en input le modèle et en output le code.

Voici à titre d'exemple quelques règles sur la génération de code UML 2 vers JAVA :

· Une classe UML correspond à une classe JAVA ayant le même nom.

· Une interface UML correspond à une interface JAVA ayant le même nom

· Si une classe UML est associée à une autre et que l'association est navigable, il y a alors un attribut dans la classe JAVA qui va correspondre à la classe UML. Le nom de cet attribut correspond au nom du rôle de l'association. Si l'association spécifie une cardinalité supérieure à 1, alors l'attribut de JAVA est une ArrayList.

· Une opération d'une classe UML correspond une opération d'une classe JAVA ayant le même nom, ainsi que les noms des éventuels paramètres.

Cette liste est non exhaustive, il existe encore beaucoup de principes mais qui ne seraient pas pertinents ici.

UML se décompose en trois sous ensemble :

· En vue

· En diagramme

· En modèles d'élément

Les vues :

· des cas d'utilisation : montrent les besoins de chaque acteur du système

· logique : montrent comment les besoins des acteurs peuvent être satisfaits

· d'implémentation : montrent les dépendances entre les modules

· des processus : montrent la vue temporelle et technique

· de déploiement : montrent la position géographique et l'architecture des éléments

Les diagrammes :

Ils sont au nombre de treize, représentant différents aspects du système.

Figure 16 : L'ensemble des diagrammes UML

Je vais vous présenter succinctement les principaux diagrammes UML

Point de vue fonctionnel :

Cas d'utilisation : OMG définit le cas d'utilisation par une "représentation d'un ensemble de séquences d'actions qui sont réalisées par le système et qui produit un résultat observable intéressant pour un acteur particulier".

Point de vue statique :

Diagramme de classes : va représenter les classes qui interviennent dans le système.

Diagramme d'objets : représente la vue statique d'un ensemble d'instance de classe

Point de vue dynamique :

Diagramme de séquences : représente les interactions entre les objets dans la réalisation du processus de l'application

Diagramme de collaboration/communication : il possède les mêmes constituants que le diagramme de séquences mais il met davantage l'accent sur les objets impliqués dans l'interaction que sur l'aspect temporel des échanges.

Diagramme d'état/transition : description d'un objet aux changements de son environnement.

Diagramme d'activité : modélise les traitements effectués par une opération.

Point de vue déploiement :

Diagramme de composants : sert à montrer le lien entre les différents composants d'une application

Les modèles d'élément :

Ce sont les briques des diagrammes. Ce sont tous les éléments qui vont permettre de concevoir les diagrammes.

Figure 17 : Quelques modèles d'élément UML

La méthode de développement UML respecte un processus strict. Après avoir lu le cahier des charges, il y a établissement en parallèle le diagramme de cas d'utilisation (UC) et de classes (seulement avec les attributs). A partir du diagramme de UC on établit les diagrammes de séquences d'analyses et d'activités. On peut ainsi peaufiner le diagramme de classes avec les opérations et finir par les diagrammes de séquences de conception.

Figure 18 : Méthode de développement UML

Classes d'analyse

Classes de conception

Activités

Séquence de conception

Séquences d'analyses

Cas d'utilisation

En parallèle

Cahier des charges