Validation modéle et code

**hegros** · 16/05/2009, 15h53

Suite à un échange avec Hephaistos007 j'ai décidé d'ouvrir ce post.(voir 2-3 dernières réponses)

Merci Hephaistos007, je comprends mieux cela facilite aussi l'écriture de test automatisé comme le test de modéle uml ou/et de code et surement pleins d'autres choses.

Par contre quand tu dis qu'en langage naturel c'est plus difficilement exploitable en fait il s'agit de spécialiser un analyseur syntaxique par exemple pour les gardes dans les diagrammes d'état.

La question est surtout comment à mon niveau de modeleur-concepteur-developpeur je peux intégrer un niveau de transformation de mon langage naturel avant d'envoyer le tout à la moulinette de la norme ou de l'outil logiciel que j'utilise (comme eclipse ou encore bouml) ?

Pour ceux qui connaissent le sujet beaucoup ou peu vous pouvez tentez alors d'exposer pour les autres ou de poser des questions afin d'explorer le sujet

**Vlade** · 16/05/2009, 16h49

Il y a un mécanisme dans la Structure UML du model afin de validé le metamodel. Ce mécanisme est simple, il suffit d'ouvrir la structure uml avec l'éditeur Eclipse et de sélectionner le menu Validate Model.

D'abord pour simplifier les débats il faut voir ce qu'on appel historiqument model, metamodel et meta metamodel. On parle aussi de niveau 0, 1, 2, 3.
Aujourd'hui grâce aux nouvelles technologies EMF l'approche traditionnelle est "has been".
Le model sont les diagrammes UML.
Le metamodel est la sauvegarde en XMI corespondant à la norme UML. C'est la structure UML du Model.
Le meta metamodel est le MOF qui est un language au dessu qui a permis de définir l'UML.

La validation du modèle et tests aujourd'hui en UML 2.2 doit se faire au niveau de la Structure UML (c'est à dire le metamodel). Le metamodel doit être unique et regrouper tous les diagrammes UML. Le diagramme UML doit être un viewer du modèle et non pas le modèle lui-même.

En partant de ces règles, il n'y a plus de problème dans la validation du modèle, de test et de synchronization de code. Si par contre des utlisateurs veulent toujours utilisés les anciennes approches UML avec un diagramme qui donne une vue du modèle et qui crée un metamodel par vue alors ce débat devient intéressant car plus d'actualité.
Cette approche des vues métiers découpés sans cohérence entre elle sont des usines à gaz

J'ai lu un certains nombres de livres UML que je recommende seulement à mes ennemies

**hed62** · 19/05/2009, 08h37

Le model sont les diagrammes UML.
Le metamodel est la sauvegarde en XMI corespondant à la norme UML. C'est la structure UML du Model.
Le meta metamodel est le MOF qui est un language au dessu qui a permis de définir l'UML.

Je me trompe peut être, mais je ne suis pas tout à fait d'accord :

si le métamodèle n'est que la sauvegarde en XMI de la modélisation, on ne "monte" pas d'un niveau. Par contre, le langage employé (XMI + règle de construction) , ça je veux bien que ce sois le métamodèle.

La sauvegarde en XMI est plutot donc la traduction des diagrammes avec le langage du méta modèle, non ?

Ou alros, je décale tout d'un niveau (ça commence à remonter à quelques années tout ça ^^)

**TheLeadingEdge** · 19/05/2009, 09h28

comment à mon niveau de modeleur-concepteur-developpeur je peux intégrer un niveau de transformation de mon langage naturel

Si on évite les maths, ce qui me vient à l'esprit comme langage ''formel'' pour modéliser c'est B. C'est fortement basé sur la logique des prédicats. Il y a même eu un outil ''atelier B'' mais je ne sais pas s'il existe encore.
Si ça t'intéresses, pour avoir plus d'informations (en français) il faudrait rechercher Habrias. C'est un prof d'IUT qui en faisait pas mal la promotion il y qques années.

**Vlade** · 19/05/2009, 11h56

Hervé,

Je comprend ta remarque et tu as raison dans l'absolue.
Jusqu'a présent on avait des vues métiers réprésenté par des diagramme UML. De cette vue métier ont sauvegardait un fichier xmi qui était appelé le model. Si un utlisateur avait plusieurs vue, cela faisait plusieurs models et il fallais ensuite une transformation pour rajouter des règles de constructions pour avoir un metamodel. Voilà ce que font tous les outils UML du marché avant que Omondo accepte d'intégrer la vision du metamodel unique que j'ai proposé.

Ce concept consiste a monté plus haut dans l'abstraction, c'est à dire au niveau MOF en utilisant EMF. A chaque création d'élement UML ce lance un appel vers le MOF qui merge l'Id UML avec les Id existante. Donc on fait d'un coup de manière transparente ce qui nécéssitait avant 2 étapes. C'est à dire le diagramme UML est tout de suite un XMI + règle de construction du model consolidé dans un metamodel plutot que de passer par le diagramme, ensuite sauvegarde xmi et ensuite règle de consolidation.

Les avantages sont énormes pour l'utilisateur qui se libère de la gestion des modèles pour ce concentré sur son métier. Cela donne la possibilité de travailler à un niveau au dessu et directement sur le metamodel et non le diagramme comme model. Je préfére parler de Structure UML du Model plutôt que de meta model même si c'est la même chose car cela est une confusion pour l'utilisateur et on ne comprend pas bien l'esprit d'UML 2.2

Comment cela marche: La Structure UML du model est synchronisé avec les diagrammes, qui sont désormais une vue de cette structure et pas juste une vue métier graphique. La Structure UML contient le métier qui lui est crée par les diagrammes UML précédent. Toute nouvelle information est sauvegardé dans la structure uml. Toute information existante est visionable dans les diagrammes UML sans ajouter d'information. On distincte donc 2 type de modeleurs. Le premier qui crée la structure du modèle et le second qui visualise les élements UML déjà existant afin d'en produire des diagrammes UML.
Il est possible par exemple d'avoir une vue "Métier de l'assurance" et de crée une Structure UML de ce modèle métier. Ensuite la Structure UML du model assurance est donné à des équipes qui vont en sortir des vues diagrammes correspondant à leur spécificités métiers. Il s'agit dans cette étape de reconstruire des diagrammes par le drag and drop d'élément UML de l'XMI vers les diagrammes.

Cela fait une grosse économie de temps et donne déjà un socle de départ.
L'autre intérêt de cette approche est permettre un cycle complet entre les équipes de modeleurs de haut niveau, modeleur applicatif, architectes et aussi équipe de developpement. Enfin cerise sur le gateau, dans un cycle agile nécéssiatant des itérations, la structure uml du modèle métrier assurance est remis à jour à chaque itération car le modèle métier est mergé avec la Structure UML afin de partir sur une nouvelle itération. Bien sûre que dans ce cas c'est pas le modèle qui drive la génération de code, mais le modèle qui est un complément au code.

J'espère que mon explication apporte des éclaircissements sinon n'hésiter à me poser des questions je serai ravi de continuer ce débat.