Skip navigation

Dans le désordre:

The Object Primer, Scott W. Ambler,
UML 2,0 : Reference Guide, CampusPress,
GNU/Linux Application Programming, M. Tim Jones,
Domain Driven Design, Eric Evans,
Pattern Oriented Software Architecture, vol4, F. Buschmann & al.,
Design Patterns, E. Gamma & al.,
Analysis Patterns, Martin Fowler,
Object Oriented Analysis and Design with Applications, 3rd, Grady Booch & al.,
Model Driven Software Development, Markus Völter & al.,
The Data Model Resource Book, vol 1, 2, Len Silverston,
Méthode orientée-objet intégrale MACAO, Jean-Bernard Crampes,
Data Modeling Essentials, G.C. Simsion & al.,
Information Dashboard Design, Stephen Few,
The Data Warehouse Toolkit, 2nd, Ralph Kimball,
The Data Warehouse Lifecycle Tookit, Ralph Kimball,
Piloter l’entreprise grâce au datawarehouse, J..M. Franco & al.,
Business Inteligence Roadmap, L.T. Moss& al.,
Information Modeling and Relational Databases, 2nd, Terry Halpin & al.,
Implementation patterns, Kent Beck,
Beautiful Code, too long,
Modern Structured Analysis, Edward Yourdon,
Le Traité de la Réalité Virtuelle, vol. 1, Mines de Paris,

entre autres.

salut à tous,
après une petite recherche google sur ce concept (A.G.S.I.), je me suis rendu compte que mon blog n’était pas recensé (enfin, celui-ci du moins).
Donc que faire sinon écrire un petit billet pourtant ce nom ? Atelier de Génie de Système d’Information (en anglais, Computer-Aided Information System Engineering, ou CAISE)

Quel est l’objectif ? Si vous savez ce qu’est un Atelier de Génie Logiciel, alors vous êtes proches de comprendre de quoi il s’agit en incorporant à ce concept la « gestion » d’un système d’information dans sa globalité : de l’infra-structure à la super-structure.

Si vous n’avez jamais entendu parler d’un tel logiciel (Borland Delphi, MS Visual Studio, PC SOFT WinDev, etc), c’est un type de logiciel qui permet de réaliser des applications de « a à z », en gérant ses versions, son cahier des charges, etc. Certains sont plus ou moins réussis (prenant plus ou moins biens en compte plus ou moins de choses essentielles ou non).

Donc en remplaçant « Logiciel » par « Système d’Information », on ne prend plus seulement en compte le côté software de la force, mais aussi le côté hardware, et donc aussi (pour « bridger », ponter) les deux, il faut le « network » (qui est aussi du hardware mais en même temps du software, uh -openDNS, etc; que ce soit dans du CISCO ou sur un Linux, c’est du software tournant sur du hardware-).

Concrètement, avant d’aller plus loin, il faut aussi percevoir deux éléments fondamentaux dans la décomposition d’un système d’information, et ce d’un niveau fonctionnel. J’y vois donc deux éléments, l’infra-structure qui supporte la super-structure (un peu comme en architecture de bâtiment).

Concrètement, j’entends par « infra-structure » ce qui permet à la « super-structure » d’exister. Les deux sont intimement liés. Mais on peut les découpler !
C’est-à-dire, pour le premier, les ordinateurs, les réseaux de l’entreprise, les systèmes d’exploitations, etc; pour le second, ce sera les applications métiers des utilisateurs du système d’information.
S’il y a des développeurs, le S.I. doit pouvoir gérer le développement (d’applications, du S.I. lui-même, etc). S’il y a des comptables, il doit être à même de proposer une solution comptable. Le tout est intégré avec le tout : toute application est connectée au vocabulaire, aux concepts de l’entreprise. L’application comptable est une simple application comptable, mais qui permet aisément de relater les produits inscrits sur les lignes comptables, de rappeler la fiche client et sa gestion (type CRM), etc.

D’un point de vue développement, il s’agit concrètement de réaliser une « méta-application » (on est en plein « model-driven development »), un méta-modèle, un langage en bref. Puis les utilisateurs (les développeurs de S.I., par exemple), créeront des modèles correspondant à l’entreprise qu’ils modélisent. Le tout étant cadré (au travers du méta-langage), il y aura possibilité de générer plusieurs éléments (qui pourront ensuite être modifiés, la génération est ici amenée dans un esprit de prototypage, de retours utilisateurs rapide, génération de la doc, etc); ce qui est un gain de temps considérable.

Qu’est-ce que j’entends par modéliser une entreprise ? Concrètement, parlons de l’entreprise de mon père, l’Espace du Sommeil à Antibes, qui est relié à deux autres magasins à Nice (même enseigne).

On verra sur un modèle trois éléments (de type « boite rectangulaire ») typés « Magasin », nommées « EDS Antibes », « EDS Barberis » et « EDS Raimbaldi », par exemple, tous reliés à un réseau nommé « RPV EDS » (Réseau Privé Virtuel Espace du Sommeil, c’est moi, configurateur du S.I. de l’Espace du Sommeil, qui aurait créé ce modèle de configuration, en quelques cliques, vous voyez bien ici que ce qui est représenté à l’écran représente une certaine réalitée -on peut aller plus loin dans la modélisation en marquant dans le modèle le fait qu’un magasin est une localité géographique et rapporter tout ça sur google maps par exemple-). Tout ça parce qu’à ce niveau, le méta-modèle parle de types de locaux d’entreprise, et de types de liaisons entre eux.

Puis à côté, un jolie bouton nommé « Déployer le S.I. » qui vous proposera une action immédiate ou retardée. Dans tous les cas il vous sera explicité ce qui est nécessaire de réaliser avant, pendant et après, étape par étape (1: connecter l’ordi 2: connecter au réseau 3: allumer, etc), etc.

L’idée me parait « unifiante », car réunissant tous les concepts au sein d’un même outil, ce qui évite pas mal de choses du genre : redondance de l’information (resaisies, etc), redondance des mécaniques applicatives (gain d’espace, de temps en recherche et développement, tracking de bugs, factorisation du code, maintenance et évolutivité de la solution, ré-utilisation, etc) et modèles par la même (qui est en soi un logiciel, retombant dans le même discours qui précède).

L’idée me parait « porteuse » car explicite, via le « model-driven », dans des modèles, de quoi il s’agit. On sépare deux niveaux : le méta-modèle (la légende d’une carte routière par exemple, qui décrit 1) ce qui est considéré dans la carte 2) ce qu’il est possible de voir sur la carte, selon la perspective qu’on a de l’histoire).
Ce qui permet de mieux comprendre ce de quoi on parle, de pointer les problèmes du doigt pour mieux y répondre (bien formuler un problème peut amener sa solution).

L’idée me parait « exigente » tend il faut formuler de modèles (celui du réseau, de linux, d’apache, de mysql, de php, et donc des systèmes d’exploitation, des serveurs web, des sgbdr, des interpréteurs de scripts -comme une espèce de « dualité » modèle-méta-modèle-, etc) et toute l’artillerie lourde qui va avec (« générateurs », « validateurs », « transformateurs », « mélangeurs », etc).

Cela fait un moment que je n’ai pas continuer le développement des projets en cours type php5, symfony, etc, car j’avais d’autres choses sur le feu, un peu plus personnels. Maintenant que c’est passé, je vais revenir au fondamentaux de ce projet : finir php5, symfony, doctrine, continuer celui du système d’information (avec justement les langages de réseau, de système d’exploitation, de serveurs web, de sgbdr, d’interpréteurs de scripts, etc).

Je ne vais pas « tout faire » d’un coup. Je vais faire le minimal sur chaque élément pour créer un prototype qui fonctionne dans une certaine optique (déployer un s.i. en générant des scripts et en les exécutant, ce n’est pas encore arrêté).

http://www.rue89.com

http://www.bakchich.info

http://www.mediapart.fr

http://www.pcinpact.fr

http://www.lesmotsontunsens.com

http://www.electronlibre.info

http://www.contreinfo.info

http://www.agoravox.fr

http://www.spreadthetruth.fr

Jiddu Krishnamurti :

« Se libérer du connu »,

« Le sens du bonheur »,

« De la connaissance de soi »,

« Réponses sur l’éducation »,

« De l’amour et de la solitude »,

« Dialogues entre J.K. et David Bohm »;

Alfred Korzybski :

Théorie de la « Sémantique Générale »,

« Une carte n’est pas le territoire », aux éditions L’éclat, pour une lecture francisé,

« Manhood of Humanity : The Science and Art of Human Engineering » (accessible gratuitement sur le site du  projet Gutenberg),

« Science and Sanity »;

Une conférence, en anglais, de 2*8h, absolument…….. renversante.
A voir absolument.  partie 1 partie 2

Cet article est protégé par un mot de passe. Pour le lire, veuillez saisir votre mot de passe ci-dessous :

Gros effort de remise en question ?
C’est un peu ça : ne pas oublier qu’on ne voit pas les choses, tous, de la même manière. Ceci vaut dans tous les domaines que la pensée humaine peut définir.

Ainsi, quand je dis de quelqu’un qu’il est con, à mon sens, celà s’arrête selon ma perception des choses d’une part, dans un contexte spatio-temporel précis d’autre part, et pour finir, sur un sujet précis (même si ce dernier est abstrait, le fait qu’il soit identifié en fait un élément précis).

J’ai donc décidé de mettre en berne tous mes billets politiques jusqu’à ce que j’ai fais le vide dans les propos que j’ai pu tenir, pour ne rapporter que des faits dans un premier temps, puis établir des questions qu’amènent ces faits, dans un second temps (toujours dans ma propre perception des choses, dans des contextes spatio-tempo-subjectifs).

Je demande donc « pardon » à toutes les personnes qui ont pu se sentir blessés par mes propos. Mais s’il vous plait, relativisez aussi de votre côté. L’effort du pardon se doit d’être bi-partie, pour être entier.

Je suis ouvert à toutes questions de toutes personnes sur ces sujets, évidement (sachant qu’il existe un cache google, par exemple 😉 et que d’autres services doivent bien avoir « screenés » ces billets pour m’être fait connaître auprès d’eux, de ma propre initiative).

Bien à vous.

Je vois bien trop de gens penser, « croire » que les Bilderberg, le New World Order ne sont que des théorie conspirationnistes, relevant de la pure forfaiture de pauvres personnes névrosées.

Je vais ici expliquer, expliciter les deux approches de la théorie du complot.

Le Top-Down et le Bottom-Up.

Le Top-Down

Historiquement cette approche est représentée par Hitler et son accession au pouvoir, et ce qui en a suivi.
Il a eu accès au Top de la pyramide des pouvoirs, permettant ainsi des ramifications vers le Down, la masse, entrainant la guerre.

Le Bottom-Up

Le Bottom-Up est une toute autre histoire.
Il s’agit de partir de la masse pour revenir (voire créer si nécessaire) le Up.
Il est évident que le « New World Order » n’existe pas en tant que tel. C’est un concept, un nom qui permet de regrouper tous ces gens qui n’agissent que dans un seul but : créer le « Top » par un nivellement, une hiérarchisation (inhumaine) de la masse, créant un « Top » (revenant alors au Top-Down. D’ailleurs Hitler n’était qu’un outil de ce Bottom-Up).
Prenons l’argent. C’est le meilleur moyen (au vue de sa création et des disparités qu’elle créé au travers de la raréfaction des besoins vitaux, des vols et viols de l’Humanité) de partir d’une masse pour créer une hiérarchie (qui était déjà là, mais invisible).

Le problème reste entier pour eux. Une fois revenue dans l’approche Tom-Down, leur empire s’effondrera. Comme Hitler a été vaincu.

La masse gagne toujours.

MAIS : au vue des technologies, chimères, il se peut que la masse puisse être abrutie ou entièrement controllée par eux avant que le réveil de l’humanité n’est eu lieu. A nous de propager ces faits aux gens sans opinion, croyants, etc.

est-ce bien nécessaire ?

est-ce bien nécessaire ?

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.

Pour faciliter le développement des modèles ecore j’ai réalisé un petit wizard Epsilon qui permet de définir les propriétés des EPackages d’un modèle ecore, d’un simple clique.

Voici le code :

wizard setNestedPackagesInfos {

guard : self.isTypeOf(EPackage)

title : ‘Set properties of nested packages’

do{
for(package in EPackage.allInstances() ){
package.nsPrefix := package.name.toLowerCase();
package.nsUri := package.generateNsUri();
}
}
}

operation EPackage generateNsUri () : String {
var ret : String;
if(self.eSuperPackage.isDefined())
{
ret := self.eSuperPackage.generateNsUri() + ‘/’ + self.name;
}
else
{
ret := self.nsUri;
}
return ret;
}

C’est aussi simple ! Ne reste plus qu’à en faire un plugin pourquoi pas ? Mais j’arrive pas à exporter 😦

Salut !

Concernant mon projet open source de modélisation d’applications web à l’aide du cadre applicatif Php 5, Symfony.

Ce petit post pour revoir les outils utilisés et pourquoi :

  1. Epsilon Generation Language
    Permet de générer du texte à partir d’instances de méta-modèles
  2. Epsilon Wizard Language
    Permet de définir des wizards utilisables depuis les éditeurs EMF générés
  3. Epsilon Transform Language
    Permet de définir des transformations entre plusieurs modèles en source vers plusieurs modèles cible, de différents méta-modèles
  4. EMF
    Permet de définir des méta-modèles ecore
  5. Epsilon Eugenia
    Permet de réaliser des éditeurs graphiques semi-automatiquement à partir d’un méta-modèle ecore
  6. GMF
    Cadre applicatif pour la réalisation d’éditeurs graphiques sur base ecore

Tous sont basés sur Eclipse Ganymed.

Maintenant la liste des projets qui vont être créés:

  1. php5
    Définition du métamodèle de Php5 dans sa perspective objet (Class, Interface, Namespace, etc) > 5.2.3
  2. doctrine
    Définition du métamodèle de Doctrine (Record, Connection, etc) > 1.0.6
  3. symfony
    Définition du métamodèle de Symfony (Project, Application, Module, etc) > 1.0

Chacun de ces projets nécessitent plusieurs artefacts:

  1. un méta-modèle
  2. un générateur
  3. des wizards pour faciliter l’instantiation de modèles
  4. des contraintes pour valider les instances de métamodèles
  5. un éditeur hierarchique (parent/enfants)
  6. un éditeur graphique (boite-relations)

Il y a aussi les transformations vers une cible technologique définie.
Concrètement, le méta-modèle Php5 doit être vu comme une cible technologique, puisqu’il y a derrière un générateur de code.
A contrario, Symfony, bien qu’implémenté en Php5, reste purement conceptuel : c’est une utilisation du méta-modèle Php5.

Exactement, lorsqu’on créé une application Symfony, on écrit du code Php5.
Donc lorsqu’on modélisera une application Symfony, on écrira un modèle Symfony, qui sera transformé ensuite en modèle Php5, de là le code sera généré.

Là, on réutilise. Enfin on capitalise.

Il faut donc rajouter un projet .xxx2php5 pour Symfony et Doctrine

Les contraintes sont dans un autre projet pour l’instant mais il se peut bien qu’ils rejoignent le projet du méta-modèle ce qui serait aussi sensé.

Ce qui au final donne ça :

  1. php5.model
  2. php5.generator
  3. php5.model.wizards
  4. php5.model.checks
  5. php5.editor
  6. php5.modeler
  7. doctrine.model
  8. doctrine.generator
  9. doctrine.model.wizards
  10. doctrine.model.checks
  11. doctrine.editor
  12. doctrine.modeler
  13. doctrine.doctrine2php5
  14. symfony.model
  15. symfony.generator
  16. symfony.model.wizards
  17. symfony.model.checks
  18. symfony.editor
  19. symfony.modeler
  20. symfony.symfony2php5

Pourquoi Php5 ?

L’objectif est de permettre la modélisation d’applications symfony et symfony étant un framework php il est sensé que ce métamodèle étende le métamodèle de php5, ou alors permet une transformation vers ce méta-modèle.
Dans tous les cas, le méta-modèle Php5 est nécessaire.

Doctrine aussi est un framework php5, et lui aussi étendra le métamodèle php5 ou permettra une transformation vers.

Pourquoi Symfony ?
Symfony est un framework Php5 implémentant le motif de conception Modèle-Vue-Controleur et est pluggable avec Doctrine, un ORM en Php5 lui aussi, s’appuyant sur DBA pour l’accès aux bases de données. De fait, c’est le plus puissant et le plus aboutit des frameworks php5.
C’est bien un framework (cadre applicatif), pas un CMS ou autres Joomla !

Pourquoi Doctrine ?
Doctrine est un Object Relational Mapper écrit en Php5, c’est aussi le plus puissant et le plus aboutit des ORM php5. Il implémente le DQL, dérivé du HQL d’Hibernate du monde des barbus de Java.

Les artefacts sont produits en utilisants les outils en regard:

  1. métamodèle : EMF
  2. generateur : Epsilon Generation Language
  3. wizards : Epsilon Wizard Language
  4. checks : Epsilon Validation Language
  5. editor : EMF éditeur xml automatiquement généré
  6. modeler : GMF éditeur généré grâce à Eugenia

Donc au final j’abandonne Acceleo qui est un trés bon produit mais je préfère epsilon car bien plus complet dans tous les domaines de la méta-modélisation (s’incruste dans n’importe quel éditeur EMF, M2M, M2T, manque T2M).

Flow3 est un sérieux concurrent de Symfony, implémentant les concepts DDD d’Eric Evans. Quand ce dernier possèdera une documentation,c’est à dire quand Php 5,3 sera stable et que phpDoc sera mis à jour, sûrement que je créérai un modeleur pour ce dernier.

But for now, Let’s play.