Skip navigation

Salut !

Ce petit fil pour vous proposer une idée de l’utilité futur des modèles ! Ces petites bêtes qui harcèlent mes potes =)

Je vais essayer de reprendre tout depuis le début.

Background technique

Systèmes et modèles

On peut considérer un modèle comme étant la représentation « dirigée » d’un système (réel ou virtuel).

Un système peut être représenté par un ensemble de modèles, chacun représentant une certaine perspective du système. En ça un modèle est « dirigé ».

Par exemple dans un système d’information d’entreprise il y a un système de gestion de bases de données relationnels généralement (le SGBDR ou RDBMS ou DB) ou toutes les instances des concepts (du modèle) de l’entreprise sont stockés.
Petit rappel, une instance est la représentation de la chose, et non sa classification. Si il y a un concept Voiture, votre voiture est représentée par une instance du classifieur Voiture (c’est une « classe » dans le paradigme « objet »). Du coup, pour « correspondre » au modèle « relationnel » des sgbdr, on dissocie la « classe » en « table ». Ainsi, un Concept est conceptualisé en classe et est enregistré sous forme de tables relationnels. On a ici 3 perspectives différentes d’une seule et même chose. Parce qu’on en parle avec des perspectives différentes, dans un but différent. C’est complètement « contextuel ».

On peut parler « en gros » d’une chose, puis « dans le détail ». C’est exactement « le tout et ses parties ». Quand on regarde dans le détail, on se « concentre » sur une seule partie de l’ensemble, ce qui ne doit jamais faire oublier qu’il faut, dans ce même temps, prendre en compte ses inter-actions dans son contexte d’existence, les autres parties et ce tout qu’il aide à faire naître.

Reprenons. Le SGBDR a une structure qui représente le modèle du système d’information dans sa perspective « relationnel ». Concrètement, ici on ne parlera pas des ordinateurs ni de classes, on parlera de tables, de colonnes et d’indexs.
Il y a aussi le modèle topologique du SIE, c’est à dire sa répartition en sites en tant que conteneurs et les nœuds de réseaux (ordinateurs, etc) en tant que contenus (c’est un modèle possible, peu riche mais illustratif).
Il y a pleins d’autres modèles, chacun représentant une perspective d’une système à un degrés apprécié au besoin.

Chaque modèle prit à part permet de diviser la vision mentale du problème pour mieux diviser le problème.
Mais lorsqu’on réunit tous ces modèles, nous avons le système d’information dans sa globalité.
On peut alors construire un outil permettant de naviguer entre les modèles de l’entreprise selon sa propre perspective (ou l’une auxquelles ont a accès) en tant qu’utilisateur.

On dit qu’un modèle est une abstraction d’un système (on se concentre sur une perspective du problème -dirigé- en oubliant volontairement les autres perspectives) en ce sens qu’on se concentre sur une perspective du système à représenter, selon un domaine précis (qui forme la perspective), et non sur la totalité du système.
Un système nécessite souvent plusieurs points de vues. En architecture, il y a le point de vue de l’électricien, du domoticien, du vitrier, du plombier et l’architecte qui tend à avoir la vision la plus globale et aussi la plus détaillée, en tout points des modèles du système. Dûr d’être architecte ! Heureusement pour eux, les architectes du bâtiment, la plupart des éléments sont industrialisés. Alors bien sûr ça fait des trucs pas beaux, mais c’est un autre problème. Dans le monde virtuel on a contrôle sur tout. Et sur encore plus de choses pourvue qu’on ait le code source.

Nous voyons donc qu’un système peut être représenté par plusieurs modèles, chacun étant une perspective du système. Mais un modèle, c’est quoi ?

Qu'est-ce qu'un modèle par rapport à un système ?

Qu'est-ce qu'un modèle par rapport à un système ?

Modèles, métamodèles, métamétamodèles.

Un ensemble de modèles représentent un système. Si on considère un modèle comme un système, on arrive à se dire qu ‘il y a un modèle représentant le modèle. Et ainsi de suite.
On arrive alors à se dire qu’il y a un modèle qui établit un langage qui définit lui même un langage qui définit lui même un langage qui définit lui même …. Mais il faut bien s’arrêter à un moment.

Ainsi l’OMG a aidé à définir MOF, Meta Object Facility qui officie comme étant le langage de plus bas niveau dans la hiérarchie des méta langages (suivant la perspective, c’est le plus haut). Il s’appel aussi M3, car c’est le méta-méta-modèle (MMM).

Du côté Eclipse de la force, MOF est implémenté par Ecore, partie intégrante du projet Eclipse Modeling Framework (EMF).

Le monde réel et ses modèles

Le monde réel et ses modèles

Nous avons donc un système représenté par un modèle qui est conforme à un méta modèle qui est lui même conforme à un autre méta méta modèle, lui même conforme à lui-même (dans la plupart des cas, 4 méta-niveaux suffisent, en fait j’en connais pas encore ou ce n’est pas suffisant ou trop).

Concrètement, prenons pour exemple un système application php type web, servi par apache.

On peut dire dans ce cas de figure que le système est l’ensemble en cours d’exécution. C’est le système d’exploitation du serveur plus le apache binaire et le php ainsi que le code php et la base de données. Concentrons-nous (faisons abstraction du reste) sur la perspective application métier faite en php pour l’exemple. Ici le code php5 est un langage de programmation. Nous avons donc un méta-modèle Php5 nous permettant de nous exprimer dans ce langage (dans sa forme abstraite). Ce métamodèle s’exprime lui même en MOF, le méta-méta-modèle qui lui-même s’exprime de lui-même. Il se conforme à lui même.

Retour

Les modèles, le nouveau code source

On sait qu’un méta-modèle permet d’exprimer la forme abstraite d’un langage. En exemple le méta-modèle de Php5 nous dit ce qu’on peut faire en Php5 : créer des classes, des interfaces, des fonctions, des directives opérationnels (appels de méthodes de classes) ou fonctionnels (opérateurs logiques – <,<, =, ==, ===, … – ou appels de fonctions). A partir d’une instance de ce méta-modèle, un modèle, on peut générer du code Php5, à l’aide d’un générateur de code qui parle le même langage : son code généré repose sur le même méta-modèle. De fait, un modèle Php5 se conforme au métamodèle Php5 (lui même se conformant à MOF). Un modèle Php5 valide permet la génération et l’exécution de code sur une plateforme Php5. D’un point de vue MDA, le méta-modèle Php5 est un modèle cible (PSM, Platform Specific Model). C’est à dire que ce modèle est destiné à être utilisé dans des transformations de modèle à texte en bout de toolchain.

On peut alors permettre la diffusion de modèles à n’importe quel niveau, celui approprié : soit au plus « bas » tel que Php5 ou Java; ou on peut en fournir de plus haut niveau comme un model Business (qui serai complètement indépendant du reste, et n’impliquerai que des requis type « il me faut une base de données relationnel », « il me faut un espace disque », etc).

Les métamodèles, le nouveau langage ?

Lorsqu’on créé un méta-modèle, il est admis qu’on créé un langage. On modélise un langage.
Typiquement, le langage Php5 peut être modélisé en Ecore (implémentation du MOF2.0 de l’OMG par l’équipe d’Eclipse EMF Project). UML est aussi modélisé en Ecore. Ecore lui-même est un langage qui s’exprime lui-même (il est auto-reflexif, « la langue parle de la langue »).
Comment ça marche ? Toute l’intelligence se trouve dans le client Eclipse et son plugin EMF. Elle est axiomatisée, formant une logique. Et puisque c’est une logique, il faut la comprendre pour en jouer.
Ainsi toute la créativité se trouve dans les méta-modèles : ces fichiers d’extension « .ecore ».
De ce point de vue, c’est un peu comme un navigateur qui est une application exécutable qui permet le rendu du DHTML, qui permet la créativité, accessible sur Internet ou dans le système de fichier de l’ordinateur. Et on voit ce que ça donne, en terme d’applications : gmail, facebook, etc. Tout ça grâce à bien des choses, mais notamment grâce à la séparation client/serveur en terme d’interface et de contrôle, impliquant la nécessité d’une application lourde (pour dire qu’il faut un exécutable binaire s’exécutant sur le système d’exploitation de l’utilisateur) côté client pour gérer l’interface utilisateur qui est définit dans un standard nommé HTML. Après c’est une question d’implémentation des standards. Certains implémentent le HTML 1.1, d’autres le 3 et le 4.
Les standards ont aussi permis d’implémenter une bonne division des perspectives du code de l’application client léger (celle faite en HTML) pour séparer le côté définition de l’affichage (emboitement des conteneurs de texte et autres controles) et définition de son style (emboitement des styles à appliquer aux conteneurs selon leurs classes ou leurs identités, CSS). Mais il reste plus sympa de se rendre compte que tout ça peut être factorisé en Javascript -ECMAScript 4-, au travers d’un cadre applicatif adapté type GEARS ou Qooxdoo.

En ce sens, les navigateurs peuvent être perçus comme des méta applications basiques (sans cadre applicatif ou intégration particulière) ou complexes (avec cadre applicatif ou intégration particulière dans le système d’exploitation), permettant une intégration normal (typique web 1.0 avec de simples liens compris par le système d’exploitation *.url par exemple) ou avisée (permissions de lectures/écritures sur le disque à certains endroits prédéfinis et accessibles uniquement à l’utilisateur en cours, accès à des périphériques médias type caméra, meilleure gestion des connexions, etc) avec le système d’exploitation hôte.
De nos jours, GEARS implémente un bon début de HTML 5 (Qooxdoo est derrière à mon sens), qui permet justement de rapprocher l’espace vide entre une application lourde et une application légère type web x.0 (via un simple lien/raccourci), ou plus précisément web « 2.0 » avec une intégration particulière plus poussée sur le système d’exploitation (type GEARS qu’il faut installer au préalable, comme .Net). Côté serveur, c’est grâce aux technologies réseaux : distribution de la charge en tout point mais aussi grâce à l’implémentation logiciel, par exemple mysql et sa gestion des réplications que ce type d’architecture logiciel offre un grand avantage : un même code peut être configuré pour une utilisation mono-poste mono-utilisateur et changé en peu de temps (celui de la migration) en multi-poste multi-utilisateur. Le tout en ayant tout le code utilisé à sa réalisation car tout est open source. Vous pouvez ainsi tout modifier selon vos besoins. Le code est capitalisé (en votre possession, avec droits de modifications impliquant souvent devoir de remettre le code source, remettre dans le tronc commun) et la formation « académique » est distribuée. Mais on s’égare un peu (je ne veux pas politiser ce débat, réservant ça à un prochain petit fil).

Concrètement, quand on créé un méta-modèle, généralement, on créé aussi des générateurs de code et/ou des transformateurs/mélangeurs vers d’autres méta-modèles (selon qu’il soit source ou cible).
Prenons un exemple. Lorsque je choisis de conceptualiser le méta-modèle de Php5 (cible) et de Symfony (source), j’ai le choix : soit Php5 et Symfony sont complètement autonomes, soit Symfony « étend » Php5.
Etant donné que Symfony est un langage « instance » du langage Php5 (comprenez que Symfony est un ensemble de classes Php5, lesquelles peuvent être définis dans un modèle « Symfony.phpmodel » qui a pour méta-modèle Php5), il peut être compréhensible que Php5 et Symfony soient complètement autonomes l’un de l’autre, découplés.

On peut aussi se dire que l’on veut, dans le langage Symfony  (quand on « parle » Symfony de même qu’on parlerait « voiture » entre potes, ou que l’on parle Thieli ou Hades chez Orange/S.-A.) aussi parler Php5, par exemple ajouter une méthode de classe à la classe « Actions »(php5::Class::Extensions::Action ? Php5::Action ? Symfony::Action ? Que faire ?) d’une classe « Module » (idem, même problématique). Ce qui est normal aussi, puisque Symfony est une instance du langage Php5. On peut s’y prendre de bien des manières, mais il ne faut jamais perdre de vue la « sémantique » véhiculée par un méta-modèle !
Si on déconnecte Symfony de Php5, on perd tout l’intérêt du méta langage : on déconnecte sémantiquement le langage Symfony du langage Php5. Pourtant, un Symfony::Module est une Php5::Class !?

Alors, mapping ou extension ?

Dans tous les cas, il faut que le modèle Php5 soit « complet » : c’est à dire qu’il comprenne la définition abstraite (métamodèle) et concrète (générateur de code, m2t, t2m) de tout le jeu d’instructions Php5 : des classes en passant par les exceptions jusqu’aux boucles for, constructs internes ou « user defined » (en fournissant un modèle de base décrivant toutes les fonctions et classes internes de Php5, dans un fichier standards.php5model type, comme le fait UML et Java. C’est une méthode !). Ainsi on peut créer un vrai engeenering round-trip modèle<->code  :une modification du modèle modifie le code, une modification du code modifie le modèle. Il y a une corrélation totale entre le code et ses modèles l’ayant « construit », par transformations. Mais pour arriver à ça, il faut créer tout plein d’outils qu’on appel des workflows : ils permettent de réaliser des « toolchain » spécifiques aux besoins. Par exemple générer les entités seulement ou seulement générer le code sql pour la création de la structure des bases de données relationnels. Mais revenons un peu plus en arrière.

Si on fait une extension du méta-modèle Php5 pour créer le méta-modèle Symfony, il faut garder à l’esprit que l’on créé une identité, un type : une méta-classe qui étend une autre méta-classe. De ce point de vue, la métaclasse Action qui étend la métaclasse Php5::Class est une Php5::Class (sic!). On vera alors un éditeur de modèle Symfony proposer la création de Php5::Class, Php5::Interface ou encore Symfony::Action !
En un clic, on a créé un éditeur dédié à Symfony et générique au langage d’instance, Php5. C’est comme la langue française et le langage d’un mécanicien parlant français.

Si on fait un mapping, les langages sont déconnectés l’un de l’autre. La « connection » ne s’effectue plus au niveau sémantique des méta-modèles mais dans une transformation de modèle à modèle, la plupart du temps, le code étant plutôt une cible technologique. Plus sûr, il y a aussi les modèles de mappings ecore.

Résumons : nous avons les moyens de créer des langages s’exprimant au travers de modèles (« la langue permet de parler de la langue », valable pour la langue française, mais pas pour toutes les langues !) et permettant des transformations en d’autres modèles ou d’en générer du texte, mais aussi de mapper les méta-modèles entre eux.

Finalement, si les utilisateurs de mon application (de modèle) ont sur leur machine un certain outil (qui serait « standardisé », type gnu toolchain puis encapsulé type aptitude de debian ou PEAR de Php) installé, ils n’ont qu’a télécharger le modèle de l’application et la « compiler ». Dans l’esprit GNU Toolchain, on télécharge le code source, puis on créé une configuration en rapport à son propre contexte utilisateur (os, compilateurs installés, librairies utilisables, bref, on parle système d’exploitation type *nix, c’est un domaine, donc un langage) et enfin on tape la commande magique : make && make install, qui a pour effet de compiler l’application et de l’installer. C’est le multi-click du Windows en mode install.

Comme dans la gnu toolchain, le code est généré après l’édition et la validation d’un modèle (instance du méta-modèle Configuration d’Application) de Configuration (type make menuconfig) confrontant le système d’exploitation et sa Configuration actuelle (instance d’un méta-modèle de Configuration de Système d’Exploitation, par exemple) aux requis de l’application à installer. On connait tous les mérites qu’apportent cette méthodologie réputée (./configure; make; make install). C’est redondant, mais bien que je parle de la même chose, je ne l’exprime pas de la même manière. Il y a tant d’angles d’attaques « morts », pour l’instant.

Ainsi, les modèles sont le renouveau du code source : distribuables, compréhensibles parce que auto-documenté par leurs méta-modèles et vérifiables parce que contraints par des descripteurs de règles de validation, réflexifs, ouvrant la voie à de meilleurs applications.
Sans parler des facultés de MOF2.0 et d’Ecore, permettant l’import de méta-modèles permettant une meilleure utilisation des ressources. Mais il y a mieux, le MOF2.0 Versioning qui gère la versionnalisation des modèles.
La version d’un modèle devient ainsi le point d’entrée du modèle d’une application.
Sans parler de tous l’outillage réalisable (et réalisé, notamment au travers d’Epsilon, merveilleuse boite à outils) en utilisant les plugins Eclipse et les extensions d’EMF et des projets liés tels que GMF, GEF, SDO, TEXIO, etc.

Voilà la « modeling toolchain » : modélisation, transformation/merging, génération d’artefacts (fichiers exécutables, de configurations, scripts de déploiements, …) et ça s’exécute. A condition qu’il y ait un cadre applicatif de modélisation et d’exécution reposant sur un même jeu de concepts !

En développant de nouveaux langages (méta-modèles, transformateurs et/ou générateurs, avec leur validateurs, puis éditeurs et modéleurs graphiques) et des outils de transformations entre les langages nouveaux et les plateformes technologiques existantes (pour commencer!), on est à même de rendre l’informatique « compréhensible » par Tata Jeannine, capitalisée par l’écriture d’applications qui créent des applications, auto-documentés par les modèles.

De la compréhension du phénomène méta à la création d’outils créateurs

Quand on comprend l’utilité de ces outils, on voit vite ce qu’on pourrait en faire :

Par exemple créer un langage de haut niveau qui permette de faire des choses type « je veux une appli web, qui me permette de gérer ce schéma, qui me permette de réaliser telles actions, qui m’affiche les choses ainsi, etc ».
Puis par des transformations, mélanges et générations on arrive à un résultat final.

Il y en a qui diront « oui mais c’est stéréotypé ». Beh ça dépend comment on s’y prend.

Par exemple, on va utiliser l’architecture « client/serveur » qu’on va implémenter à l’aide des standards du « W3C », on va utiliser côté client (le « navigateur », firefox, etc) un framework (Qooxdoo en Javascript est à mon sens le meilleur), côté serveur idem (Symfony en Php5, pluggé à Doctrine pour l’ORM qui sont à l’heure actuel, à mon sens les meilleurs, bien que Flow3 va arriver enfin documenté -c’est un énorme souhait de ma part!-).
Ainsi on peut générer du code à destination des frameworks là ou ils agissent : on réutilise du code, des librairies. Par exemple l’indexExecute (qui exécute la méthode « index » d’un « module » dans le langage « symfony ») redirigera vers le « js » écrit en qooxdoo (on pourra même spécifier par configuration à qooxdoo-build de générer le source ici, la release là, etc), et c’est lui qui génèrera les prochaines requêtes, en tant qu’application web exécutée côté client (xmlhttprequest ou iframe caché etc) -une vraie application écrite en qooxdoo-. Bref chacun est expert de son domaine et l’utilisation des modèles et des générateurs et mélangeurs permettent de créer les artefacts nécessaires sans réinventer la roue. Limite glue-model. Il n’y à qu’à regarder la ressemblance entre fichier yaml et fichier de déclaration. Les développeurs tendent à permettre aux développeur de « déclarer » tout et n’importe quoi n’importe comment. Ce n’est pas plus mal, c’est simplement un effort du « style déclaratif » qui est dû à l’effet d’encapsulation par problématique des frameworks.

Au final oui le code génère une application type, mais elle est entièrement modifiable. Et il nous appartient de créer des modèles de configurations pour chaques éléments, découplés tous ces phénomènes au travers d’entités distinctes (pas de conteneurs, juste des réferences).

Il appartient ensuite lors du merging de vérifier l’intégrité des modèles (qu’il y est bien un modèle objet, avec un modèle de conf pour chaque objet, etc).

Mais juste une chose. Quand on parle de « modèle », on parle bien de manière conceptuel. Physiquement, un modèle peut être explosé en plusieurs fichiers, plusieurs versions, etc. Grâce à XMI et donc XML.

Bref, on se créé ses propres outils, selon nos besoins.

Laisser un commentaire

Choisissez une méthode de connexion pour poster votre commentaire:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :