Ing´ enierie dirig´ ee par les mod` eles

Etat de l’art

2.4 Ing´ enierie dirig´ ee par les mod` eles

Figure 2.12 – Chronogramme d’ex´^{ecution des tˆ}^{aches correspondant au comportement du r´}^{eseau de Petri} avec inhibiteurs `a stopwatch

2.4 Ingénierie dirigée par les modèles

Comme nous nous intéressons à l’ingénierie système d’un point de vue temps réel, nous présentons dans cette section le paradigme nommé ingénierie dirigée par les modèles (IDM) qui est une pierre angulaire dans la conception logicielle des systèmes temps réel. En effet, l’IDM permet de fluidifier le passage d’une étape à l’autre lors des cycles de développement grâce l’interopérabilité entre les outils de modélisation, d’analyse, de transformation et de génération de code.

L’ingénierie Dirigée par les Modèles-IDM (Model-driven Engineering) est un paradigme pro-metteur pour le développement de logiciels. L’IDM est une pratique de l’ingénierie des systèmes qui décrit à travers des modèles le problème posé et sa solution. Le but de l’IDM est d’aug-menter le niveau d’abstraction dans la représentation d’un système et l’automatisation de sa construction. Dans l’IDM, les modèles jouent un rôle important dans le développement de logi-ciels. L’automatisation de la production du système peut être réalisée par des transformations de modèles.

Définition 2.4.1 Un modèle est une abstraction et une simplification de systèmes permettant de comprendre et de fournir des réponses relatives au système modélisé. Ensuite, un système peut être décrit par différents modèles liés les uns aux autres.

Les modèles sont considérés comme des entités centrales dans l’IDM. Un modèle est une re-présentation abstraite d’un (ou partie de) système. Il montre une vue partielle du système en simplifiant ce qui doit être capturé ou automatisé. Par conséquent, une meilleure représentation du système nécessite souvent plusieurs modèles. L’utilisation de modèles a pour objectif d’am´ e-liorer la qualité du logiciel obtenu, car il est plus facile de comprendre, de simuler, d’analyser et de valider des modèles abstraits que les programmes informatiques.

Définition 2.4.2 Un méta-modèle est une abstraction permettant de mettre l’accent sur les propriétés du modèle lui-même. Un méta-modèle décrit les différents types d’éléments du modèle et la fa¸con dont ils sont agencés.

Pour connaˆıtre la nature des différents modèles utilisés dans les systèmes informatiques, on identifie deux relations. La première relation est représentée par, indiquant une représentation d’un objet qui est modélisé à travers un modèle. Par exemple, un programme informatique peut ˆ

etre représenté par un diagramme de classes. La deuxième relation est conforme à, indique la dépendance d’un modèle à un langage de modélisation. Un modèle est conforme à son m´ eta-modèle comme un programme est conforme à la grammaire du langage de programmation selon lequel il est écrit [Sch06].

Fi gure 2. 13 – Il lus trat ion de s con ce pt s de m ´et a-mo d ´el isat ion

2.4. ING ÉNIERIE DIRIG ÉE PAR LES MOD ÈLES

La figure 2.13 représente la modélisation d’un réseau de Petri (RdP). La partie (a) de la figure représente un RdP avec l’arc inhibiteur. Ce réseau comprend quatre places et deux transi-tions connectées par les arcs. Les arcs normaux sont représentés par les flèches, cependant l’arc inhibiteur a un cercle à la fin de l’arc. La partie (b) de la figure représente le méta-modèle de réseau de Petri de la partie (a). En effet, un réseau se compose des places (instances de la classe Place), des transitions (instances de la classe Transition) et des connexions (instances de la classe Connection). Les connexions relient les noeuds (instances de la classe Node). Un noeud peut être soit une place soit une transition. Il y a deux types de connexions : l’arc normal (instance de la classe NormalArc) et l’arc inhibiteur (instance de la classe InhibitorArc). Une connexion a une source et une cible qui sont des noeuds. Chaque noeud peut avoir un ensemble d’arcs entrants (ayant le rôle inputRel ) et un ensemble d’arcs sortants (ayant le rôleoutputRel ). La partie (c) de la figure représente le méta-méta-modèle du réseau de Petri. Ce méta-méta-modèle se compose des éléments et des relations de trois types différents : composition, héritage et référence. Ce méta-méta-modèle est conforme à lui même car si on cherche à méta-modéliser ses éléments on obtiendra un méta-méta-méta-modèle qui lui ressemble.

2.4.1 M´eta-mod´elisation

La méta-modélisation est le processus de définition du méta-modèle d’un langage de mo-délisation. Un langage de modélisation est un langage artificiel qui peut être utilisé pour exprimer des informations ou connaissances de systèmes dans une structure. Un langage de modélisation peut être graphique ou textuel.

— Les langages de modélisation graphiques se basent essentiellement sur l’utilisation des diagrammes avec (i) des symboles nommés qui représentent des concepts, (ii) des liens qui relient les symboles et représentent des relations, et (iii) diverses autres notations graphiques pour représenter des contraintes ou des propriétés.

— Les langages de modélisation textuelles peuvent utiliser des grammaires normalisées pour créer des expressions.

Afin d’organiser et de structurer les modèles, l’OMG (Object Management Group) [OMGc] a défini une architecture appelée ; “Architecture à 4 niveaux” représentée dans la figure 2.14.

Figure 2.14 – Architecture `^{a 4 niveaux d´}^{efinie par l’OMG [WO01]}

— Le niveau M3 correspond au MOF (Meta-Object Facilities) [OMGe]. Le MOF est un lan-gage de définition de méta-modèles. Les langages de niveau M3 sont conformes à

eux-mêmes, c’est-à-dire qu’ils peuvent se définir. Par exemple, le langage Ecore [Ecl] est une implémentation du MOF, intégrée au framework de devloppement Eclipse sous forme d’un plugin nommé EMF (Eclipse Modeling Framework ) [emf].

— Le niveau M2 contient les méta-modèles définis par M3, comme les méta-modèles de UML (Unified Modeling Language) [G⁺02], de CWM (Common Warehouse Metamodel ) [PCTM02], de BPMN (Business Process Management Notation), etc.

— Le niveau M1 contient les modèles qui sont conformes aux méta-modèles du niveau M2, par exemple, les modèles exprimés en diagrammes de classes d’UML.

— Le niveau M0 représente les systèmes réels ou les codes exécutables correspondant aux modèles du niveau M1.

2.4.2 Transformation de mod`eles

La transformation de modèles permet à un ou plusieurs modèles sources d’être automati-quement transformés en un ou plusieurs modèles cibles selon des règles de transformation. On peut définir des correspondances entre des modèles du même langage ou des modèles de lan-gages différents. Les outils de transformation sont essentiels pour maximiser les avantages de l’utilisation de modèles et minimiser les efforts de construction du système modélisé. Ainsi, ils peuvent considérablement améliorer la productivité du développement logiciel.

Définition 2.4.3 Une transformation de mod`eles est une fonction ϕ : S → C, telle que : ϕ prend en entrée un ensemble de modèles source S et génère en sortie un ensemble de modèles cible C. S et C sont les ensembles de modèles conformes à deux ensembles de méta-modèles. Si les deux ensembles de méta-modèles sont identiques, la transformation du modèle est appelée endogène, sinon elle est appelée exogène.

Figure 2.15 – Transformation de mod`^{eles en mod`}^{eles en IDM}

La figure 2.15 montre une vue d’ensemble du mécanisme de transformation de modèles tel qu’il est utilisé via l’ingénierie dirigée par les modèles. En général, une transformation de modèles est un programme composé d’un ensemble de règles de correspondance. Une règle de transformation est une description de la manière dont un ou plusieurs éléments du langage source peuvent être transformés en un ou plusieurs éléments du langage cible.

On s’intéresse à deux types d’approches de transformation de modèles.

— La transformation de modèles à base de graphe en modèles à base de graphe (Model to Model - M2M). Ce type de transformation est supporté par des langages de description de

Dans le document Aide à la validation temporelle et au dimensionnement de systèmes temps réels dans une démarche dirigée par modèles (Page 42-46)