IPM - Ingénierie Par Modélisation

Par Olivier Haas janvier 15, 2023

IPM (v2) est un AGL (Atelier de Génie Logiciel) de type IPM/IDM (Ingénierie Par Modélisation / Ingénierie Dirigée par les Modèles).

1. Caractéristiques-clés
2. Distributions
3. Cas d’utilisation
4. Vision
5. Positionnement
6. Agenda
7. Tarifs

 
 

1. Caractéristiques-clés

  • Plateforme d’intégration d’OGL (Outil de Génie Logiciel).
    • IPM est construit autour de notre produit SDS ; des machines à états réalisent l’intégration des outils.
  • Superposition du cycle projet avec le cycle d’abstraction/modélisation, contrairement à ce qui a cours habituellement dans l'état de l’art.

    • Architecture classique habituelle : IPM - Archi IDM classique sans IPM

    • Architecture IPM : IPM - Archi IDM avec IPM

  • Persistance des modèles UML sans référentiel externe, directement dans un langage de programmation (Java, C, C++, OCaml, …).
    • Les artefacts de modélisation ne sont pas persistés dans un référentiel attaché à l’outil de modélisation graphique choisi (EnterpriseArchitect, Modelio, HOPEX, etc.), mais dans des fichiers de code source d’un langage de programmation quelconque. Un modèle est ainsi considéré au même titre que tout composant applicatif.
  • Indifférenciation programme/modèle (due au point précédent).
    • Un programme est un modèles, et réciproquement ; cela apporte linéarité et simplification.
  • Atelier interactif de mise au point des transformations de modèles.
    • Le point à la fois le plus porteur de valeur et le plus délicat dans l’Ingénierie Dirigés par les Modèles étant l'écriture des transformations de modèles, IPM comporte un atelier spécifique d'écriture, de test, d’exécution pas-à-pas, etc., de ces transformations. Des outils de preuve formelle destinés à ne pas contrevenir à la cohérence et à la complétude sont également dispoibles.
  • Architecture ouverte sous les aspects de la visualisation et du stockage (persistance) des modèles.
    • Tout outil graphique est branchable sur la plateforme IPM, dans le cadre d’une transaction sur le modèle.
  • Unicité de type de modèle.
    • Les modèles de l’application quel que soient leurs niveaux d’abstaction, les modèles de transformation de modèle, les modèles de génération de code, etc., sont considérés de la même façon. L’intérêt rétiré en est une linéarité générale et donc une grande simplification.
  • Transformation de modèle et génération de code écrites en OCL, Prolog, OCaml, Gallina (Coq), …
    • Selon vos préférences et les caractéristiques de vos besoins, les transformations peuvent être écrites dans plusieurs langages.
  • Mise à disposition en infonuagique (SaaS).
    • IPM est disponible sur nos machines : voir notre solution d’infogérance IPM.
  • Bibliothèques de transformations de modèles.
    • Les modèles réalisatn des transformations de modèles sont publiables en bibliothèques. Ces modèles y sont organisés en topologie sémantique suivant les modèles qu’ils prennent en entrée et en sortie (en superposition d’une formule du lambda-calcul typé).

 
 
 

2. Distributions

 
 
 

3. Cas d’utilisation

3.1. Cas typique

  1. Une pré-étude de la topologie sémantique (cartographie des langages, des “univers du discours”, y compris ceux des outils, avec leurs relations réciproques) de l’organisation ou de l’application, est effectuée.
  2. Sur la base de cette topologie sémantique, l’ordonnancement global du projet est déduite (GANTT à grosses mailles).
  3. Pour chaque itération :
    1. La conception détaillée des langages est effectuée/corrigée.
    2. Parallèlement :
      • Les transformations inter-langages sont écrites/corrigées (en OCL, Prolog, OCaml, Gallina (Coq).
      • Parallèlement, les spécifications sont modélisées/corrigées en UML au moyen d’un outil de modélisation du marché, paramétré pour persister/exporter les modèles sons la forme d’artéfacts du langage de votre choix.
    3. Les transformations sont exécutées, automatisant ainsi les tâches de spécification détaillée et de codage.
    4. Les éventuels tests et/ou évaluations du résultat sont effectués.

3.2. Variantes

  • La pré-étude de topologie sémantique peut intégrer une mise en œuvre d’Ingénierie Dirigée par les Modèles déjà présente dans votre organisation. Une phase de migration sera alors conçue, d’ailleurs elle-même en IDM/IPM.

 
 
 

4. Vision

  • Définitions préalables :
    • L’IPM (Ingénierie Par Modélisation) désigne l’ingénierie effectuée uniquement par modélisation, ce qui va donc au-delà de l’IDM (Ingénierie Dirigée par les Modèles).
    • L’IDM, appelée aussi MDE (Model-Driven Engineering) ou MDD (Model-Driven Development), est la démarche consistant à organiser l’ingénierie logicielle par un réseau de modèles, dont chacun détient la spécification du logiciel pour un aspect précis de celui-ci.
    • UML (Unified Modeling Language) est le langage communément utilisé pour la rédaction des modèles.
    • OCL (Object Constraint Language) est un langage complétant UML afin de pouvoir spécifier des invariants ou des pré/post-conditions sur un modèle UML.
    • MDA (Model-Driven Architecture) est une normalisation de l’IDM basée sur UML, effectuée par l’OMG (Object Management Group) à partir de 2001.
    • On a les relations inter-modèles notables suivantes :
      • Méta : Un méta-modèle définit le langage dans lequel un modèle peut être écrit.
      • Raffinage : Un modèle conséquent est plus raffiné qu’un antécédent lorsqu’il reprend les spécifications de celui-ci tout en les rapprochant de l’implantation machine.
      • Transformation : Opération par laquelle un modèle est déduit automatiquement, ou semi-automatiquement, d’un autre.  
         
  • Bénéfices attendus de l’IDM ?
    • En distinguant les aspects, on espère rendre certains modèles stables, et partant, de gagner en performance et en qualité. Ce bénéfice est parfois désigné sous le syntagme de « maîtrise de la chaleur technologique ».
    • En automatisant les déductions d’un modèle à l’autre, on espère là aussi gagner en performance et en qualité. Ces automatisations peuvent représenter la sédimentation de bonnes pratiques ou de savoir-faire. Elles peuvent aussi être le siège de preuves ; preuves que le modèle cible est un reflet fidèle du modèle source.
    • En manipulant des modèles dont chacun est attaché à un aspect précis, on espère ouvrir la compréhension des spécifications à une population plus large, et par là même faciliter la communication entre les divers intervenants d’un projet.  
       
  • Quel constat ?
    • Si certains outils de modélisation peuvent se prévaloir d’un certain succès commercial, l’échec est patent sur plusieurs axes :
      • L’échange de modèles, malgré la définition de normes (XMI (XML Metadata Interchange) et UMLDI (UML Diagram Interchange)), reste toujours problématique.
      • La transformation de modèles, fonctionnalité pourtant la plus cruciale et la plus porteuse de valeur, résiste, et aucune implémentation n’est encore convaincante.
      • Le recours massif à l’offshoring atteste de l’échec de MDA.
      • MDA s’avère incompatible, en l’état, avec les méthodes agiles, tandis que, tout au contraire, l’IDM devrait aider, fluidifier, accélérer, toutes les tâches, et donc entrer en synergie avec l’agilité.  
         
  • Quel diagnostic ?
    • Le modèle économique de l’outil de modélisation UML est pathogène quant à l’intérêt général de l’industrie logicielle.
    • L’architecture MDA est :
      • théoriquement mal construite ;
      • techniquement trop complexe.  
         
  • Notre solution pour l’IDM
    • Nous avons effectué :
      • une refondation théorique ;
      • une ré-architecturation.
    • Les apports pour l’ingénieur logiciel sont :
      • l’utilisation du ou des langage(s) de programmation pour manipuler, utiliser, et persister les modèles ;
      • l’utilisation de l’outil de son choix pour visualiser les modèles ;
      • une seule sorte de modèle (dans MDA, les sortes de modèles sont pléthore : CIM, PIM, PSM, PDM, le tout multiplié par 3 niveaux d’abstraction) ;
      • une indifférenciation entre Transformation de Modèle et Génération de Code, unifiées sous le concept de compilation ;
      • l’utilisation de Prolog afin de traiter simultanément l’ingénierie et la rétro-ingénierie ;
      • d’être doté d’un AGL (Atelier de Génie Logiciel) disponible en SaaS (la plateforme réalisant la nuagification des OGL), et composable au gré de ses besoins par greffe d’OGL (Outil de Génie Logiciel).

 
 
 

5. Positionnement

  • Tout type d’organisation et de projet est candidat à retirer des bénéfices de l’IDM/IPM : bénéfices qui se compteront en termes de valeurs, de qualité, et de maîtrise du risque.

 
 
 

6. Agenda

  • La solution sera mise en ligne en février 2023.

 
 
 

7. Tarifs

  • Les contextes pouvant être très différents, tant qualitativement que quantitativement, il nous semble plus pertinent d’aborder la question tarifaire dans le cadre d’une réponse globale à votre besoin : voici notre formulaire de contact.

Recherche

Catégories

Tags