Bilan et Positionnement

Dans cette section, nous avons pr´esent´e l’´evolution du pouvoir d’optimisation dans l’approche classique bas´ee sur l’IDM pour le d´eveloppement des syst`emes embarqu´es. Cette approche se base g´en´eralement sur les optimisations du compilateur. Nous avons ´etudi´e les niveaux d’optimisation du compilateur GCC (le niveau SSA et le niveau RTL) et nous avons vu que malgr´e l’´evolution du pouvoir d’optimisation du GCC, les d´eveloppeurs ne sont pas satisfaits par la performance du code ex´ecutable produit `a partir des mod`eles UML. Ils modifient souvent manuellement le code C++ produit par les g´en´erateurs de code pour l’optimiser. Cette modification manuelle du code ´elargit le gap entre le mod`ele et le

code et affecte les validations et les analyses qui peuvent ˆetre faites au niveau mod`ele. Nous avons ´egalement pr´esent´ees deux techniques d’optimisation au cours de la g´en´eration de code : la modification des r`egles de g´en´eration de code (adopt´ee par le g´en´erateur de code BridgePoint) et l’ajout d’une forme interm´ediaire (adopt´ee par le g´en´erateur de code RIALTO et l’approche Polis). Les optimisations au cours de la mod´elisation sont souvent assur´ees par les outils de refactoring et de validation. Cependant, le refactoring de mod`eles concerne g´en´eralement la probl´ematique de lisibilit´e et de maintenabilit´e (et non pas d’optimisation).

Nous allons montrer dans ce travail de recherche que pour produire un code binaire optimis´e en termes de taille de code `a partir des mod`eles des syst`emes embarqu´es, des passes d’optimisations sont exig´ees dans toutes les ´etapes de l’approche de d´eveloppement de ces syst`emes. Nous allons ´egalement montrer que la g´en´eration de code, bien qu’elle paraisse une ´etape essentielle dans le d´eveloppement des syst`emes, n’est pas utile pour les optimisations [77] au contraire, elle est la cause de la perte d’informations (utiles pour les optimisations) li´ees `a la s´emantique du langage UML. Nous proposons ainsi une nouvelle mise en œuvre de l’approche dirig´ee par les mod`eles pour le d´eveloppement des syst`emes embarqu´es qui ´elimine l’´etape de la g´en´eration de code. Cependant, nous ne sommes pas les premiers `a essayer de compiler directement les mod`eles UML. En effet, plusieurs travaux tels que [78] et [79] se sont int´eress´es `a la construction de machines virtuelles UML qui ne produisent pas de code de 3`eme _{g´en´eration `a partir des mod`eles UML mais g´en`erent `a}

la place un code interm´ediaire (bytecode) interpr´et´e par la machine virtuelle pour produire le code binaire. Toutefois, la recherche que nous avons men´ee sur les machines virtuelles UML [80] et [81] a montr´e que ces outils sont souvent conc¸us pour simuler les mod`eles et en particulier les activit´es UML et par la suite ne s’int´eressent pas `a l’optimisation du code ex´ecutable. La seule machine virtuelle UML permettant de compiler `a la fois les activit´es et les machines `a ´etats est la machine virtuelle UML (UVM) propos´ee par Schattowsky et Muller [82]. Cette machine virtuelle UML n’est pas disponible et ne s’int´eresse pas `a la production du code compact `a partir des mod`eles UML. Par cons´equent, nous allons nous positionner uniquement par rapport aux travaux de g´en´eration de code.

Le tableau 2.3 pr´esente 4 outils de g´en´eration de code sur les quelles se base l’approche existante dirig´ee par les mod`eles pour le d´eveloppement des syst`emes embarqu´es. Ils sont classifi´es selon les crit`eres suivants : les diagrammes UML comportementaux pris en compte, le langage cible produit et les optimisations support´ees.

Critères de classification Rhapsody BridgePoint + iUML RIALTO

Diagrammes comportementaux UML supportés

Activités, Machine à états, Séquence

Machine à états Machine à

états

Code cible C/C++/Java/Ada C/C++/Ada/ C++/ Vhdl

Techniques d’optimisation autres que les optimisations du GCC

-- Archetyes S-Graph

Les g´en´erateurs de code profitent des optimisations des compilateurs de code mais favorisent aussi la modification manuelle du code g´en´er´e par les d´eveloppeurs en produisant un code lisible que le d´eveloppeur maitrise (3`eme _{ligne du Tableau 2.3). En}

compilant directement les mod`eles UML, notre approche pr´eserve les fondements de l’IDM qui consid`ere le mod`ele comme la seule repr´esentation du syst`eme qui peut ˆetre modifi´ee, empˆechant ainsi la modification manuelle du code qui affecte les validations et les analyses faites au niveau mod`eles.

Le compilateur de mod`ele que nous proposons compile directement les mod`eles UML tout en profitant des optimisations des compilateurs de code. Il permet aussi d’am´eliorer quelques unes. Plusieurs g´en´erateurs de code commerciaux tel que Rhapsody (deuxi`eme colonne du Tableau 2.3) s’int´eressent plut ˆot `a la production d’un code lisible et maintenable et ne favorise pas les optimisations. D’autres g´en´erateurs de code se basent sur des techniques d’optimisation telle que la modification des r`egles de g´en´eration de code (Archetype) adopt´e par BridgePoint et iUML (troisi`eme colonne du Tableau 2.3). Nous avons vu que cette technique, bien qu’elle implique une interaction avec l’utilisateur, exige une maitrise des patterns de g´en´eration de code et leurs impacts sur la performance du code binaire g´en´er´e. Nous allons montrer dans cette th`ese que les optimisations impl´ement´es dans la forme interm´ediaire S-Graph du g´en´erateur de code RIALTO (derni`ere colonne du Tableau 2.3) peuvent ˆetre am´elior´ees.