Choisir et déployer un langage de modélisation conceptuelle. Quelques Clés.

[Cette article est aussi disponible aussi en Anglais]

Le choix d’un ou plusieurs langages de modélisation conceptuelle dans le cadre du déploiement d’une démarche d’ingénierie (Model Based System Engineering – MBSE) doit nécessairement donner lieu à une « introspection professionnelle » afin de bien définir les motivations (intentions de modélisation) que l’on désire supporter. Quelques soient les choix opérés, ils sont moins importants que les justifications qui vous conduisent à les faire ainsi que les savoir faire qu’ils permettent de magnifier ; le travail de communication, fondamental à la réussite d’un projet de déploiement MBSE, doit s’appuyer sur ces savoir faire. Enfin, un déploiement MBSE est un travail au long cours, incrémental et qui s’opère à des rythmes différents au sein d’une organisation ; la maîtrise de la cohérence des modèles et intentions associées doit être perçue comme un enjeu majeur.

1. INTRODUCTION

L’ingénierie système dirigée par les modèles (ISDM ou MBSE (Model-Based System Engineering[1] dans la littérature anglaise)) est clairement « dans le vent » (46,4 x106 résultats sur Google contre 20,4×106 résultats pour « Computer-Aided Design ») ; ce n’est pas pour nous déplaire et nous pensons vraiment que l’ISDM[2] constitue une technique de base qui permettra de mieux aborder la complexité des systèmes à bâtir et de réduire leur coût et leur durée de mise sur le marché. Si, pour certains types de modèles (mathématiques, géométriques…), le choix d’une technique de modélisation ne relève pas d’un choix cornélien (Mathlab, MGS[3]…), pour d’autres, plus particulièrement pour les modèles conceptuels, ce n’est pas toujours le cas. 

Cet article, qui ne veut pas être dogmatique et donc qui se positionne au-delà des luttes de chapelles qui malheureusement existent aussi dans le monde de la modélisation conceptuelle, tente de donner au lecteur les clés nécessaires dont il aura besoin pour se faire une opinion sur la démarche de déploiement de l’ISDM la mieux adaptée au sein de son organisation. Après une présentation très rapide des fondements de la modélisation conceptuelle, nous présenterons une classification de quelques uns de ces langages de modélisation conceptuelle ainsi que quelques unes de leurs caractéristiques permettant d’opérer des choix. Ensuite sont évoqués les problématiques principales du déploiement d’une démarche ISDM et ce quels que soient les choix de langages pouvant être faits. 

2. LA MODÉLISATION CONCEPTUELLE (FONDEMENTS)

Il nous semble important, avant d’aller plus avant dans cet article et de fournir les clés attendues par le lecteur, de replacer très brièvement la modélisation conceptuelle dans son contexte historique et téléologique (qui concerne l’étude des finalités). La modélisation conceptuelle peut être considérée comme une branche technique et pragmatique de la sémiotique (étude des signes et de leur signification) qui trouve ses racines dès le 17e siècle dans l’ouvrage d’épistémologie (un domaine de la philosophie des sciences) de John Locke « Essai sur l’entendement humain »[4]. Si l’on se permet cette dernière assertion, c’est surtout pour souligner l’importance, lorsque l’on mène une démarche de modélisation conceptuelle, d’étudier de manière critique la méthode, les formes logiques et modes d’inférence utilisés dans le domaine métier ciblé par le travail de modélisation conceptuelle. En effet, mettre en œuvre une démarche de modélisation conceptuelle revient à vouloir maîtriser dans un contexte métier donné le fameux triangle sémiotique « Réalité » – « Concept » – « Signe »[5]

Pour arrêter là le discours théorique et être plus prosaïque, si l’on se place dans le cadre de l’ingénierie d’un système, la modélisation conceptuelle sert un ou plusieurs objectifs[6] comme par exemple :

  • L’élucidation des besoins
  • La spécification fonctionnelle
  • La spécification comportementale
  • L’optimisation des interfaces et la recherche de l’architecture optimale
  • La génération automatique de code

Pour ce faire, la modélisation conceptuelle permet de simplifier une réalité en concepts embarquant un savoir-faire implicite, et de les représenter sous forme de signes afin de faciliter leur manipulation, leur étude et leur communication.

 

Figure 1 : deux exemples de notations pour la modélisation de systèmes

La modélisation conceptuelle a pris son essor dans le monde de l’ingénierie (ingénierie logicielle) dans les années 70 mais n’a vraiment commencé à être populaire que dans les années 90. Ces années ont coïncidé avec une mutation/crise dans l’industrie logicielle, concomitante avec l’explosion de la bulle Internet, qui a eu pour conséquences dans la modélisation conceptuelle de :

  • trop mettre en avant l’outillage de modélisation conceptuelle, et donc des langages (Booch, OMT, UML, …) au détriment de la méthode.
  • mais, pire encore, de créer dans la conscience une inversion du lien de causalité entre l’intention/la finalité et l’acte de modélisation conceptuelle : « Si l’on fait de la modélisation conceptuelle, c’est que l’on est informaticien et que l’on cherche à automatiser la production du code, donc si l’on n’est pas informaticien ce n’est pas adapté… »

Il semblerait toutefois que depuis quelques années l’on soit arrivé à une certaine maturité des outils de modélisation conceptuelle, et que l’intention de modélisation reprenne la place qui lui revient de droit ; ce qui explique aussi la popularité croissante des DSML (Domain-Specific Modelling Language).

Quoi qu’il en soit, que l’on choisisse d’utiliser un DSML ou un langage dit « standard » il est primordial que l’intention/finalité de modélisation soit le guide de navigation. Nous verrons cela plus en détail dans la suite de cet article.

3. LANGAGE « UNIVERSEL » (UML / SYSML) ET LANGAGE SPÉCIALISÉ

Il existe de nombreux langages de modélisation différents, et ceci depuis longtemps ! Comment s’y retrouver parmi tous les *ML issus d’UML[7] (SysML, SOAML, WebML, etc.) et les autres langages, tels que AADL[8], SDL, Modelica[9], etc. ?

3.1. Une classification de langages existants

Essayons de proposer une classification à plusieurs dimensions de ces langages :

  1. Spectre intentionnel : quel est l’objectif de chaque langage ? Se veut-il être très général, couvrir une large gamme de problèmes différents, et ceci depuis l’analyse amont jusqu’à la conception détaillée ? Ou vise-t-il plutôt à résoudre un problème spécifique dans un domaine particulier ? La complexité du langage risque bien d’être proportionnelle à son spectre intentionnel : comme exemple, UML 2 qui se veut universel avec ses 14 types de diagrammes différents… En revanche, SADT[10] se voulait également indépendant du domaine avec ses 2 types de diagrammes, mais clairement positionné sur l’analyse et non la conception de systèmes.
  2. Niveau de formalisation sémantique : on distingue couramment les langages formels, comme … pour lesquels une représentation mathématique est possible, et par conséquent des propriétés du modèle peuvent être prouvées mathématiquement, et les langages semi-formels comme UML, où un certain niveau de formalisation est proposé, mais où il reste des ambiguïtés, des « points de variation sémantiques », ne permettant pas la preuve formelle. Par exemple, si l’on considère plusieurs modeleurs UML proposant des capacités de simulation, il a été montré que le même modèle conceptuel (par exemple basé sur les diagrammes d’états) peut donner des résultats de simulation différents, voire contradictoires suivant les outils.

En complément de ces deux premières dimensions, on pourrait aussi ajouter :

  1. Niveau de diffusion : il existe une énorme différence entre la diffusion mondiale et transverse à tous les domaines techniques d’UML et la faible pénétration de SDL en dehors du domaine des télécommunications. De même, un formalisme comme le Grafcet[11] n’est pas vraiment sorti de France.
  2. Standard opposé à propriétaire : là encore, gros avantage aux mastodontes publiés par l’OMG[12] ! UML et SysML ont des spécifications publiques, et du coup de très nombreux outils commerciaux se disputent le marché des utilisateurs potentiels. Certains formalismes intéressants (comme ceux des outils MATLAB/Simulink) ont le gros inconvénient d’être propriétaires, obligeant ceux qui les adoptent à être pieds et poings liés à l’éditeur unique des outils support, avec tous les risques connus que cela implique (non-concurrence, évolutivité, pérennité, etc.)
  3. Existence d’un écosystème : ce critère est souvent lié au précédent, puisque les langages standard ont plus de chance d’avoir toute une offre diverse et variée autour d’eux. Cependant, il peut exister de rares langages propriétaires possédant un écosystème riche, de par leur prééminence sur un marché de niche, ou au contraire des langages standard finalement peu utilisés et donc avec un écosystème assez pauvre.
  4. Adéquation à la culture des utilisateurs : plus un langage est général, et plus il risque d’être éloigné de la culture de ses utilisateurs. En outre, un langage comme SysML, destiné à l’ingénierie système, étant lui-même issu d’UML, majoritairement utilisé par des informaticiens, et masquant mal les concepts « orientés-objet », risque fort au final de passer à côté de sa cible, ou tout au moins de laisser les non-initiés « au bord du chemin »…

3.2. Avantages d’UML / SysML

UML a maintenant plus de quinze ans d’existence, et constitue un standard international de facto (http://en.wikipedia.org/wiki/Unified_Modeling_Language). Il est le résultat d’années de travail d’experts internationalement reconnus[13], pour lui donner une très grande puissance d’expression (nombreux concepts et diagrammes) et une excellente couverture des besoins de modélisation courants. Pour ceux qui souhaitent analyser et concevoir leurs architectures sans avoir à définir un nouveau langage (ce qui relève d’un savoir-faire particulier), et de partir sur le capital-confiance d’une notation standard, l’utilisation d’UML est un bon choix. UML est bien adapté à la description de concepts de haut niveau, et à la définition d’un glossaire général qui sera utilisé pour décrire les concepts du projet, facilitant une communication plus large.

L’écosystème autour d’UML (http://www.uml.org/) est très riche, autant par le nombre d’intentions de modélisations basées sur UML (appelés profils, tels que UPDM, MARTE, TelcoML, BioML, etc.) que par la multitude d’outils de modélisation (http://uml-directory.omg.org/vendor/list.htm) qui permettent de le mettre en œuvre. Ces outils ne permettent pas seulement de créer des modèles UML/SysML, mais aussi de générer automatiquement de la documentation, d’établir des liens avec des exigences textuelles, de générer du code, etc.

De nombreux professionnels sont formés à UML/SysML en école d’ingénieurs ou à l’université, voire avant en France, puisque SysML est depuis peu au programme des terminales STI2D et de certains BTS.

3.3. Inconvénients d’UML / SysML

Cependant les avantages que nous venons de détailler sont contrebalancés par des inconvénients réels, qu’il ne faut pas sous-estimer.

Tout d’abord, on ne peut pas nier une apparente complexité d’UML due au nombre important de concepts et diagrammes disponibles (14 types de diagrammes différents depuis UML 2.3 !). Cette complexité est malheureusement assez mal masquée par les outils existants qui restent difficiles à maîtriser en dehors d’une utilisation très réductrice en termes de nombre de diagrammes. Les outils sont également difficiles à personnaliser, en particulier pour restreindre les diagrammes et les palettes de commandes dans chaque diagramme, ce qui permettrait justement de combattre cette complexité apparente.

Du coup, il est absolument nécessaire de définir très tôt dans le projet une démarche (intention) de modélisation détaillée pour choisir le sous-ensemble nécessaire et suffisant d’UML qui sera utilisé et éviter ainsi de se perdre dans les méandres du langage. L’ordre dans lequel seront utilisés les diagrammes retenus doit également être décidé assez tôt, donnant lieu idéalement à un « template » de modèle réalisé avec l’outil sélectionné. Tout cet effort méthodologique ne peut être réalisé sans le concours de « mentors » expérimentés, pas forcément disponibles dans l’entreprise.

Dans le cas particulier de SysML, l’origine orientée-objet du langage UML dont il est issu n’est que partiellement masquée (notions d’opération, de généralisation / spécialisation, et même d’object flows et object nodes dans le diagramme d’activité …). Cette origine « objet » est clairement un frein à l’adoption pour les ingénieurs de l’ingénierie système non familiers du monde du développement logiciel.

3.4. Avantages des langages spécialisés (DSML)

Un langage spécialisé va cibler plus particulièrement un domaine spécifique, ou intention de modélisation particulière. Du coup, il permettra de capturer l’information avec un plus grand degré de précision et laissera moins de place à l’interprétation. La plupart des langages spécialisés, de par leur couverture moindre, embarquent une sémantique plus riche/formelle et sont souvent utilisables pour une vérification et une génération plus poussées. Le positionnement des DSML est donc une tentative d’équilibre entre le spectre intentionnel (moins large qu’un langage universel) et la formalisation sémantique (plus riche).

Un langage spécialisé devrait aussi être plus parlant pour l’expert puisqu’il utilise son vocabulaire métier, les concepts du domaine, au lieu de concepts plus généraux parfois éloignés de la culture de l’utilisateur. De même, le nombre de concepts de diagrammes est beaucoup plus limité, facilitant l’apprentissage du langage. Sa mise en œuvre est également facilitée avec des outils dédiés, qui peuvent être très compacts et performants.

3.5. Inconvénients des langages spécialisés (DSML)

Un écueil important est cependant à éviter : ne pas réinventer la roue ! Si le DSML finit par ressembler trop à UML, il vaudrait mieux envisager d’utiliser directement UML, ou un sous-ensemble d’UML. Même si UML a des défauts, ils sont maintenant connus, et nombre d’entre eux ont été gommés. Créer un DSML non nécessaire pourrait amener à répéter un certain nombre d’erreurs qui ont fini par être résolues dans le cas d’UML. Et, enfin, la création d’un métamodèle et d’un outil l’exploitant relève d’un savoir-faire tout particulier qui n’est pas souvent existant dans une organisation.

3.6. Une approche « hybride » ?

Il n’est pas obligatoire de choisir entre DSML « pur » et xML. En effet, si un DSML peut être créé à partir de la page blanche, il peut aussi l’être en tant que profil UML. Dans ce dernier cas, celui qui définit le langage et son environnement outillé va pouvoir profiter de toutes les fondations conceptuelles d’UML, mais aussi de son écosystème. Bien sûr, en contrepartie, une expertise du méta-modèle UML est requise, ce qui peut être un frein important.

En comparaison, un DSML « pur » ne nécessite aucune connaissance d’UML. Mais il faut alors développer soi-même toute l’infrastructure supportant le langage. Une tentative récente dans le domaine de l’ingénierie système est illustrée par l’outil open-source Capella (www.polarsys.org/capella/), basé sur un formalisme défini initialement par Thales pour ses besoins propres. Les ingénieurs système de cette société ne retrouvaient pas leur approche fonctionnelle favorite dans les langages standards tels qu’UML et SysML. Ils ont donc décidé de créer un DSML mieux adapté à la culture de leurs utilisateurs et inséré dans une méthode de modélisation appelée ARCADIA (www.polarsys.org/capella/arcadia.html). La création d’un écosystème autour de Capella est l’objectif du projet Clarity (www.clarity-se.org/), récemment lancé.

4. SE RAPPROCHER DE L’EXISTANT POUR FACILITER LE CHANGEMENT (MAGNIFIER LE SAVOIR-FAIRE)

Comme nous l’avons dit plus tôt, la modélisation conceptuelle permet de simplifier une réalité en concepts (cf. chapitre 2).

La nature de ces concepts et la manière de conceptualiser cette réalité dépendent énormément du savoir-faire et de l’expérience du modélisateur. Il est important que ce savoir-faire soit décrit d’une manière ou d’une autre afin de :

  • faciliter l’acte de modélisation, et son enseignement,
  • servir de documentation de base pour la définition de l’environnement de modélisation.

En outre, la description de ce savoir-faire permet d’éviter le syndrome de « la page blanche » chez les modélisateurs les moins expérimentés. Selon que l’on choisisse de supporter sa démarche de modélisation conceptuelle par un langage « standard » (UML, SysML, AADL, etc.) ou bien alors un langage dédié (DSML), ce travail de description du savoir-faire est plus ou moins formel et se réalise différemment.

4.1. Magnifier le savoir-faire

Dans le cas de l’utilisation d’un langage « standard », ce travail de documentation du savoir-faire doit se faire prioritairement sous la forme de guides opérationnels présentant pragmatiquement le processus de modélisation.

Ce travail doit être établi par au moins un binôme de compétences :

  • une bonne connaissance du métamodèle du langage,
  • une bonne connaissance du domaine métier de modélisation et des pratiques associées.

Dans le cas particuliers d’UML et SysML, ces guides sont simplifiés par la mise en place de profils adaptés.

Dans le cas de l’utilisation (ou de la volonté d’utiliser) d’un langage « dédié » (DSML), l’approche se doit d’être totalement différente, et beaucoup plus conceptuelle. En effet, même si à terme, la rédaction de guides opérationnels de modélisation est utile, ici il est important de considérer ce savoir-faire comme des éléments d’exigences que le DSML se doit de satisfaire. Pour ce faire il faut rédiger :

  • des scénarios de conception exprimés en langage métier (c’est-à-dire sans aucune mention d’artefacts de modélisation),
  • des règles de cohérence de données métiers.

En effet, ces éléments vont se positionner comme besoins pour la réalisation d’un « métamodèle » qui va structurer votre langage « dédié » (DSML).

En termes de gestion du changement et de communication, la promotion et la mise en avant de ce savoir-faire permet de mieux faire accepter l’adoption de techniques de modélisation conceptuelle qui se positionnent comme simple outil du métier, et moins comme une révolution culturelle.

4.2. Faire évoluer le savoir-faire plus que de le révolutionner

La mise en œuvre de techniques de modélisation conceptuelle est bien entendu l’occasion d’améliorer ses pratiques d’ingénierie, mais si l’on veut augmenter les chances de leur acceptation, ces pratiques ne doivent pas remettre trop en cause (voire, pire, oublier) les savoir-faire existants. Une fois que les nouvelles pratiques sont mises en place, on peut gager que l’amélioration progressive de ces pratiques sera aussi l’occasion d’améliorer (ou capitaliser l’amélioration de) son savoir-faire en ingénierie.

Là encore, le choix d’un langage “standard” ou “dédié” aura un impact particulier :

Dans le cas de l’utilisation d’un langage “dédié” (DSML), une modification du savoir-faire entraîne une modification du métamodèle qui structure fondamentalement le langage, et entraîne donc un risque technique.

Dans le cas de l’utilisation d’un langage “standard”, une modification du savoir-faire n’entraînera qu’une modification des guides et/ou de profils de modélisation (dans le cas d’UML ou SysML) et donc pas ou peu de risque technique sur le langage. Toutefois pour les langages « profilables » (UML, SysML), le risque technique du langage dépend de la complexité de la technique de modélisation car il est fonction de la conjonction de la complexité du métamodèle du langage et de celui du profil implémenté

En conclusion :

  • Même si elle relève d’une pratique particulière, la modélisation conceptuelle doit permettre la pratique métier et non pas l’inverse sous peine d’un rejet de la part des équipes et donc d’une inefficacité de la technique.
  • Selon la maturité de vos savoir-faire en ingénierie, de leur complexité et du niveau de support de ces savoir-faire par votre environnement de modélisation, l’usage d’un langage « standard » ou « dédié » sera plus ou moins dans sa zone de confort technique.

5. INTEROPÉRABILITÉ DES MODÈLES : LA GESTION DES RÉFÉRENTIELS

5.1. Préambule

Il nous semble important d’avoir en tête une vision « gestion de configuration » lorsque l’on entreprend le déploiement d’une démarche ISDM, afin d’être préparé lorsque la maturité de votre démarche et/ou le nombre de modèles le justifiera.

Il est une chose importante en modélisation conceptuelle : « l’humilité face aux choix effectués ». En effet, choisir une technique de modélisation à un instant t, peut ne pas être justifié à t + Δt ou bien alors cette technique peut ne pas être suffisamment bien adaptée à un autre contexte technique et/ou organisationnel. Il peut en résulter, lorsque l’on déploie une démarche d’ingénierie basée sur les modèles, de manipuler un ensemble de modèles, basés sur des techniques de modélisations différentes (Utilisation de langages « standard » et/ou dédiés).

Les techniques de modélisations sur la base de langages « standards » peuvent avoir des modalités[14] d’applications différentes selon les contextes, et bien sûr les techniques de modélisation basées sur des langages dédiés reposent sur des métamodèles différents selon le domaine ciblé. Bien entendu, si l’on adopte une démarche basée sur les modèles cela implique qu’il existe des « correspondances » et de la « traçabilité » entre des artefacts de ces modèles

 

Figure 2 : un exemple de relations possibles entre modèles et intentions de modélisation

Si l’on ajoute maintenant la dimension « temps », ces modèles évoluent bien entendu, mais les techniques (intentions) de modélisations aussi.

 

Figure 3 : Quelles versions des modèles et intentions de modélisations sont compatibles avec quelles versions d’autres modèles et intentions de modélisations ?

Il semble nécessaire de gérer en cohérence les relations qui existent entre les modèles et intentions. Exemples :

  • chaque version du modèle d’architecture « Segment Orbite » n’est compatible (ne satisfait) qu’avec un certain nombre de versions des « besoins marketing »,
  • chaque version du modèle d’architecture « Segment Orbite » a été réalisée selon une version particulière de l’intention de modélisation « Maîtriser les interfaces techniques et fonctionnelles », mais reste toutefois « compatible » avec un ensemble de versions de cette intention de modélisation.
  • Pour rendre plus efficace la maîtrise des coûts, nous allons faire évoluer la méthode d’allocation de coûts, et par conséquent créer une nouvelle version des intentions de modélisations « Maîtriser les interfaces techniques et fonctionnelles ». 

Cette situation est clairement délicate, et certains diront que l’utilisation d’un modèle unique résout tout cela…

Si nous décidons que le paradigme du modèle unique (voire de la « modalité d’application »/ « intention de modélisation » unique) n’est pas envisageable, dans ce cas il faut se faire une raison et mettre en place les moyens de maîtriser ces cohérences. Ce travail de gestion de la cohérence revient à déployer des techniques de gestion de configurations (de référentiels) de ces modèles :

  • gestion de version de modalités/Intentions,
  • gestion de version des modèles,
  • gestion de compatibilité/applicabilité de modèles.

5.2. Gestion de versions de modalités

Une modalité doit être nécessairement représentée par un document explicatif/justificatif de la manière d’utiliser le langage.

Pour une modélisation basée sur un langage « standard », ce dernier s’accompagne en général d’un lot d’adaptations de l’outil support et, dans le cas d’UML/SysML, d’un profil particulier.

Pour une modélisation basée sur un langage « dédié », il s’accompagne nécessairement d’un lot de créations[15]/adaptations de l’outil support s’appuyant sur un métamodèle.

La gestion de version de modalité consiste donc à gérer en configuration les éléments suivants :

  • Document explicatif de la modalité. Ce document doit référencer en tant que documents applicables d’autres documents qui doivent aussi faire partie de la configuration :
  • documents de processus techniques,
  • documents de processus d’entreprise,
  • documents méthodologiques.
  • Métamodèle / Profil
  • Adaptation outillage

5.3. Gestion de versions des modèles

Un modèle est nécessairement réalisé selon une modalité particulière.

La gestion de version d’un modèle consiste donc à gérer en configuration les éléments suivants :

  • la modalité,
  • le modèle (et les modèles « inclus »[16]).

5.4. Gestion de compatibilité/applicabilité de modèles

Comme nous l’avons dit plus haut, un modèle n’est jamais unique ; il peut en effet être en relation avec d’autres modèles :

  • qu’il inclut (Exemple : Le modèle « Moteur » inclut le modèle « Freins »),
  • dont il est issu (Exemple : un modèle destiné à la génération automatique de code temps réel synchrone peut être issu d’un modèle de conception préliminaire ne nécessitant pas de compétence particulière en systèmes temps réel synchrones,
  • avec lesquels il entretient des correspondances (Exemple : le modèle « moteur » possède des correspondances avec des artefacts se trouvant dans le modèle mécatronique du véhicule.

 On sent bien que, si elle veut être maîtrisée, la gestion de configuration de ce réseau de modèles doit s’appuyer sur un cadre méthodologique basé sur des règles de compatibilité.

Exemples :

  • Un modèle ne peut inclure que des modèles basés sur la même modalité/intention,
  • Un modèle ne peut être issu d’un modèle que s’il partage avec ce dernier les mêmes documents applicables[17] de type « processus techniques », ou du moins des documents applicables considérés comme « compatibles »,
  • Un modèle ne peut entretenir des correspondances avec un modèle que s’il partage avec ce dernier les mêmes documents applicables[18], ou du moins des documents applicables considérés comme « compatibles ».

Il est important de ne pas « prendre peur » de cette complexité, c’est le prix « honnête » à payer pour bénéficier des énormes gains procurés par le déploiement d’une démarche d’ingénierie basée sur les modèles.

6. CONCLUSION

Mettre en œuvre une démarche ISDM n’est jamais trivial. Il faut être pragmatique, certes, mais pas naïf. Oublions le rêve de simplicité mis en avant par les éditeurs d’outils de modélisation : il ne suffit pas d’acheter un environnement de modélisation outillé pour être en mesure de déployer une ingénierie système basée sur les modèles.

Il faut tout d’abord mettre en œuvre une démarche de modélisation conceptuelle et, pour cela, définir avec précision l’(ou les)intention(s)/finalité(s) de modélisation. Ensuite, l’on pourra choisir un langage de modélisation : soit opter pour l’une des variantes d’UML, soit construire son propre DSML. Ce qu’il est important de noter, c’est qu’il n’est pas possible d’avoir un jugement de valeur absolu des différents langages dans cette classification, tant le contexte de modélisation est important.

 

En effet :

∙ si vous désirez aller vers la modélisation conceptuelle, mais que vous ne savez pas vraiment comment vous y prendre et que vous avez du mal à déterminer les intentions de modélisation, alors dans ce cas n’envisagez même pas un DSML, car les risques de ne pas fournir la bonne solution de modélisation dans les temps sont trop grands ;

∙ si vous devez « embarquer » beaucoup de néophytes dans la démarche de modélisation, l’utilisation d’un langage dit « standard » peut entraîner une trop grande pluralité des interprétations et finalement ne pas convaincre les utilisateurs.

Au-delà de toutes luttes de chapelles, considérez seulement les langages à votre disposition comme un ensemble de boîtes à outils. Et si vous ne trouvez pas votre bonheur avec les langages existants, envisagez la création de votre DSML, d’autant que des méta-outils performants existent maintenant pour aider à bâtir votre propre environnement de modélisation. Citons en particulier l’open-source Sirius des sociétés Thales et Obeo (http://www.obeo.fr/fr/produits/eclipse-sirius), ou son équivalent payant Obeo Designer (http://www.obeodesigner.com/). C’est, par exemple, grâce à la technologie mise en œuvre dans Sirius que Thales a pu développer un outil de modélisation système autour de sa démarche de modélisation ARCADIA (Capella).

Enfin, il faut partir du principe qu’il est fort possible que vous finissiez par manipuler assez rapidement un ensemble de modèles basés sur des intentions/finalités de modélisation différentes et qu’il s’agira de les gérer en cohérence (en configuration) si vous ne voulez pas être dépassé par le déploiement de votre démarche ISDM. Il est important de ne pas « prendre peur » de cette complexité, c’est le prix « honnête » à payer pour bénéficier des énormes gains procurés par le déploiement d’une démarche d’ingénierie basée sur les modèles.

 

Auteurs: Joseph ARACIC et Pascal Roques

© Crescendo Technologies


[2] Ingénierie Système Dirigée par les Modèles (Model Based System Engineering -  MBSE)

[3] http://fr.wikipedia.org/wiki/Mod%C3%A8le_g%C3%A9n%C3%A9ral_de_simulation

[4] http://www.gutenberg.org/ebooks/10615

[5] C. K. Ogden et I. A. Richards : The Meaning of Meaning: A Study of the Influence of Language Upon Thought and of the Science of Symbolism ; London: Routledge & Kegan Paul, 1923

[6] Plus le nombre d’objectifs est grand et plus le modèle conceptuel est délicat à réaliser.

[7] UML (Unified Modeling Language - www.uml.org) un langage de modélisation graphique destiné à comprendre et décrire des besoins, spécifier et documenter des systèmes, esquisser des architectures logicielles, concevoir des solutions et communiquer des points de vue. UML unifie à la fois les notations et les concepts orientés objet. UML s’articule autour de quatorze types de diagrammes, chacun d’eux étant dédié à la représentation des concepts particuliers d’un système logiciel.

[8] AADL (Architecture Analysis and Design Language) est un langage de description d’architecture destiné aux systèmes embarqués (contextes : automobile, aéronautique et spatial notamment). Sa standardisation est en cours sous l’autorité de la SAE (Society of Automotive Engineers).

[9] Le langage de modélisation orienté objet Modelica est destiné à permettre une modélisation de systèmes complexes, par exemple des systèmes comportant des composantes mécaniques, électriques, hydraulique, thermique, etc. Il est libre et promu par l’association à but non lucratif Modelica Association (www.modelica.org).

[10] SADT (Structured Analysis and Design Technique) utilise un enchaînement graphique de boîtes élémentaires pouvant être raffinées de façon descendante en d’autres modèles SADT (boîtes + flots). Les modèles utilisés peuvent être des actigrammes (les boîtes sont les fonctions et les flots sont les données) ou des datagrammes (l’inverse).

[11] Mode de représentation et d’analyse d’un automatisme, particulièrement bien adapté aux systèmes à évolution séquentielle, c’est-à-dire décomposable en étapes. Il est dérivé du modèle mathématique des réseaux de Petri

[12] L’OMG (Object Management Group - www.omg.org) est un groupement d’industriels dont l’objectif est de standardiser autour des technologies objet, afin de garantir l’interopérabilité des développements. L’OMG comprend actuellement plus de 800 membres, dont les principaux acteurs de l’industrie informatique, mais aussi les plus grandes entreprises utilisatrices dans tous les secteurs d’activité.

[14] Dans le cas d’UML et SysML, ces modalités sont représentées par des profils.

[15] Dans le cas de l’utilisation d’un outil comme Sirius (www.obeo.fr/fr/produits/eclipse-sirius)

[16] voir plus bas

Share on Facebook
Share it on Viadeo
Share on LinkedIn
Post on Twitter
Google Buzz (aka. Google Reader)

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

*

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>