Etat de l’art
3.5 Requˆ ete et sp´ ecification de mod` ele physiques
3.5.1 G´en´eralit´e
Un des axes de contribution qui est trait´e dans la m´ethodologie propos´ee concerne le lien qui peut ˆetre fait entre le monde du syst`eme et le monde physique. Toute la contribution consiste `a d´efinir une requˆete de mod`ele. Le mod`ele une fois d´evelopp´e sera int´egr´e au produit virtuel. Pr´ec´edemment, les mod`eles ont ´et´e diff´erenci´es en deux classes : les mod`eles de type ing´enierie syst`eme et les mod`eles de comportement phy-sique. Ce chapitre traite de la transition entre ces types de mod`eles, pour ´evoluer ensuite vers la sp´ecification et de la requˆete de mod`eles au sens large.
L’innovation propos´ee dans la m´ethodologie propos´ee est de baser la requˆete de mod`ele sur un mod`ele d’intention. Ce concept va ˆetre compar´e `a des concepts proches pour proposer une d´efinition initiale d’un mod`ele d’intention.
3.5.2 Lien entre mod`eles de type ing´enierie syst`eme et mod`eles phy-siques
Le diagramme SysML qui est le plus proche d’une mod´elisation physique est le diagramme param´etrique. Compos´e de ports reli´es entre eux par des flux, ce diagramme peut repr´esenter une premi`ere mod´elisation physique grˆace `a l’ajout d’´equations simples mod´elisant un comportement. Ce premier pas ne r´esout pas le probl`eme de l’obtention de ces ´equations.
ModelicaML est un outil qui permet de produire des mod`eles de comportements en se basant sur des mod`eles d’ing´enierie syst`eme [51]. La m´ethodologie qui a motiv´e la cr´eation de cet outil est n´ee de la motivation de pouvoir tester grˆace `a la simulation certaines exigences. La figure 3.23 illustre les trois ´etapes principales de l’approche qui permet de d´emarrer d’une mod´elisation syst`eme (´etape 1), grˆace `a un diagramme pa-ram´etrique, puis de g´enerer un code en langage Modelica pour la mod´elisation compor-temental et physique (´etape 2) et ensuite permettre des simulations du syst`eme pour tester des exigences (´etape 3). La simulation est dirig´ee par un s´equencement d’ac-tions regroup´ees dans un mod`ele appel´e diagramme de s´equence. D’autres approches proposent de se baser sur la compl´ementarit´e offerte entre SysML et Modelica dans
3.5 Requˆete et sp´ecification de mod`ele physiques
Figure 3.23: ModelicaML - source [50]
la construction de mod`eles de simulation [52, 53]. Elles mettent en avant l’analogie entre SysML et Modelica, pour sp´ecifier dans SysML de nombreuses informations uti-lisables pour la construction du mod`ele Modelica. Cependant, la requˆete ou mˆeme la sp´ecification de mod`eles consid`ere que l’utilisateur dispose d’une librairie de mod`eles ou bien les connaissances pour la construire.
3.5.3 Sp´ecification de mod`ele
D´efinir un mod`ele est une tˆache importante pour la collaboration. En effet, il est n´ecessaire d’identifier, de pouvoir tracer et surtout de comprendre l’utilisation du futur mod`ele. Les travaux de Sirin [54, 55, 56] permettent de mettre en place une fiche d’iden-tit´e de mod`ele (MIC, Model Identity Card ), contenant des informations class´ees selon quatre classes, pr´esent´ees en figure 3.24. Cette fiche est utilis´ee pendant la construction du futur mod`ele pour `a la fois orienter l’expert en mod´elisation, mais aussi lui trans-mettre les caract´eristiques majeures attendues. La m´ethodologie associ´ee au concept de MIC permet de construire un mod`ele global comportemental d’un syst`eme. Pour g´erer ces MIC, un rˆole d’architecte de mod`ele est d´efini. Dans la m´ethodologie que nous proposons un rˆole proche sera d´efini.
3.5 Requˆete et sp´ecification de mod`ele physiques
3.5.4 Mod`ele d’intention : extension d’analyse
Le mod`ele d’intention repr´esente la sp´ecification du mod`ele souhait´e. Cette sp´ecifi-cation prend la forme d’une requˆete et permet de demander un mod`ele physique pour des simulations. Nous ´etendons ce premier concept `a des mod`eles qui servent de base pour expliciter ou demander d’autres mod`eles. Ce travail de recherche permet ensuite de donner une d´efinition claire au concept de mod`ele d’intention pour la conception.
Figure 3.25: Mod`eles d’exigences et de solution - adapt´e de [57]
La Global Association for Software Quality (Gasq) d´ecrit dans son syllabus sur l’ing´enierie des exigences une approche de sp´ecification de mod`ele pour le domaine des logiciels [57]. Cette sp´ecification est bas´ee mod`ele et permet de supporter la construction d’un mod`ele final. Le mod`ele sp´ecifiant est appel´e mod`ele d’exigences et le mod`ele final le mod`ele de solution. La description de ces mod`eles est propos´ee sur la figure 3.25.
Dans le mˆeme ordre d’id´ee qui consiste `a utiliser la mod´elisation pour exprimer les besoins en mod`eles, mais cette fois-ci pour r´ealiser des simulations, le Modeling and Simulation Coordination Office (M&SCO) propose le concept de Simulation Conceptual Model (SCM) [58] :
“ Develop Conceptual Model results in the simulation conceptual model, the collection of information that describes the developer’s concept about the simulation and its
constituent parts. It serves as a bridge between the Developer and the User, demonstrating the Developer’s understanding of the intended use.”
Le SCM est donc un mod`ele qui permet d’exprimer un concept et de le caract´eriser avec des informations, sous forme d’hypoth`eses et de caract´eristiques.
Le concept de mod`ele sp´ecifiant est aussi d´evelopp´e avec le System Specification Model (SSM) [59]. Ce concept qui appartient au domaine du logiciel montre le besoin d’encapsuler des informations directement dans un mod`ele :
“ [SSM] represents high–level requirements that provide an abstract repreentation of functional, performance, interface, or safety characterisitcs of software components. The Specification Model should express these characteristics unambiguously to support
an understanding of the software functionality.”
Les mod`eles prescriptifs sont un dernier concept qui rejoint l’id´ee g´en´erale du mod`ele d’intention [60]. Contrairement aux mod`eles descriptifs qui expriment le comportement et les propri´et´es d’un syst`eme existant, le mod`ele prescriptif transmet le comporte-ment ou les propri´et´es attendues du syst`eme propos´e. Cette nuance fait cependant une diff´erence notable dans l’utilisation du mod`ele.
3.6 Synth`ese
Cet ´etat de l’art a permis d’identifier les travaux et recherches en relation avec la probl´ematique. L’approche globale propos´ee, bas´ee sur la mise en place d’un produit virtuel, est un axe de recherche jamais explor´e de la fa¸con d´ecrite dans la probl´ematique. En effet joindre l’analyse d’interactions dans un syst`eme `a la construction de mod`eles constitutifs `a un produit virtuel est une approche qui m´erite d’ˆetre d´evelopp´ee et test´ee. Cette approche est de plus justifi´ee par le contexte qui traite de syst`emes de propulsions innovants, donc difficiles `a mod´eliser sans analyses pr´ealables.