ch-introduction.tex 19 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356
  1. % vim:spell spelllang=fr
  2. \cleardoublepage
  3. \phantomsection
  4. \SpecialSection{Introduction}
  5. \label{ch:introduction}
  6. %\todo{ plan de l'intro : \begin{itemize}
  7. % \item résumé
  8. % \item contexte
  9. % \item langage ?
  10. % \item contributions
  11. % \item plan
  12. %\end{itemize}}
  13. %FIXME\ttodo{intro-résumé en une page max. bien calibré ou pas ?}
  14. \textit{Le sujet de cette thèse est l'élaboration de méthodes et outils pour le
  15. développement logiciel fiable s'appuyant sur des transformations de modèles.
  16. Plus précisément, la question est de savoir comment améliorer la confiance dans
  17. un logiciel et dans son processus de développement alors que les chaînes de
  18. développement se complexifient et que les outils se multiplient.}
  19. \textit{L'industrie adopte progressivement les techniques de l'Ingénierie Dirigée par
  20. les Modèles. L'un des intérêts de ce domaine est d'accélérer le développement
  21. logiciel à moindre coût par l'usage de langages dédiés et d'outils de
  22. génération de code. Dans ce contexte, les logiciels sont donc en partie issus
  23. de chaînes de transformations opérées sur des modèles jusqu'à la génération du
  24. code et sa compilation.}
  25. \textit{Dans le cadre du développement de systèmes critiques, les logiciels doivent
  26. être vérifiés afin d'être certifiés. Se pose alors la question de la
  27. qualification des logiciels utilisés dans les chaînes de développement des
  28. systèmes critiques. Il faut s'assurer que les outils n'introduisent pas de
  29. bogue à chaque étape du processus de développement et qu'une trace puisse être
  30. conservée, de la spécification au code.}
  31. %La vérification d'un logiciel peut prendre plusieurs formes plus ou moins
  32. %formelles (de la relecture de code à la preuve mathématique)
  33. \textit{Le langage {\tom} repose sur le calcul de réécriture et fournit des
  34. fonctionnalités telles que le filtrage à des langages généralistes comme
  35. {\java} ou {\ada}. Des constructions de haut niveau permettent de décrire
  36. formellement des algorithmes. Il offre la possibilité d'établir des règles de
  37. transformation pour écrire des outils de transformation sûrs.}
  38. \textit{La finalité de cette thèse est donc de proposer des méthodes et outils pour
  39. exprimer des transformations de modèles qualifiables. On s'intéresse à fournir
  40. des constructions dédiées pour décrire une transformation de modèles et pour
  41. assurer la traçabilité entre le modèle source et le modèle cible. Le but étant
  42. alors de donner des éléments de confiance supplémentaires à l'utilisateur
  43. responsable de la vérification de la chaîne de développement.}
  44. \newpage
  45. %\pagebreak
  46. %\todo{TODO: introduction à la Luc Engelen, avec une section "research questions" +
  47. %publis liées. $\Rightarrow$ plus de publis…}
  48. \section*{Contexte et motivations}
  49. %FIXME\ttodo{faut-il faire apparaitre explicitement certaines question ? comme dans
  50. %la thèse de Luc Engelen ?}
  51. Les systèmes se complexifiant, l'ingénierie dirigée par les modèles ({\idm}) a
  52. apporté des solutions pour faciliter et accélérer le développement logiciel. Ce
  53. domaine a véritablement pris son essor à la fin du XX\up{ème} siècle avec la
  54. publication de l'initiative {\mda} (\emph{Model Driven Architecture}) par
  55. l'{\omg} (\emph{Object Management Group}). L'industrie a adopté les méthodes et
  56. technologies issues du monde des modèles, y compris dans le cadre du
  57. développement de systèmes critiques. Cependant, si la manière de développer un
  58. logiciel ainsi que les technologies utilisées ont changé depuis les débuts de
  59. l'informatique, les contraintes liées à la maintenance (évolution du logiciel,
  60. déboguage) ainsi qu'à la fiabilité (qualification, certification) persistent.
  61. Les technologies des domaines critiques tels que l'aéronautique, l'automobile
  62. et la médecine reposant de plus en plus sur l'informatique, il est
  63. particulièrement important de s'assurer du bon fonctionnement des logiciels
  64. avant leur mise en production. Pour cela, il est nécessaire de les vérifier.
  65. Plusieurs approches complémentaires sont disponibles pour augmenter la
  66. confiance en un logiciel : le test, la preuve, la simulation et le
  67. \emph{model-checking}. Chacune d'entre elles comporte ses spécificités, ses
  68. avantages et ses inconvénients. Dans le cadre de la qualification et de la
  69. certification, ces approches sont rarement suffisantes une à une et sont donc
  70. généralement combinées ou pratiquées en parallèle. Lors de la certification, il
  71. est nécessaire d'avoir une confiance forte dans les outils utilisés dans le
  72. processus de développement. Cette confiance est accordée par leur qualification
  73. qui exige une traçabilité entre la spécification et l'implémentation d'un
  74. logiciel. L'intégration de l'{\idm} dans les chaînes de développement de
  75. systèmes critiques tendant à se généraliser, il est fondamental de développer
  76. des méthodes et des outils pour aider au processus de qualification des
  77. nouveaux outils.
  78. Dans ce contexte, nous nous proposons de travailler à l'élaboration de méthodes
  79. et d'outils permettant d'apporter des éléments de confiance pour la
  80. qualification du logiciel.
  81. %Pour cela, nous souhaitons pousser l'utilisation des méthodes formelles dans
  82. %l'ingénierie du logiciel, que ce soit dans un cadre académique ou industriel.
  83. Nous nous plaçons à la frontière de deux domaines : celui de l'Ingénierie
  84. Dirigée par les Modèles ainsi que celui de la réécriture de termes. L'industrie
  85. a vu l'intérêt pratique de l'{\idm} et a adopté les outils qui en sont issus.
  86. Les méthodes formelles, en particulier le domaine de la réécriture qui nous
  87. intéresse, sont quant à elles moins connues, mais indispensables pour un
  88. développement logiciel de qualité. Se placer à la frontière des deux domaines
  89. permet de tirer le meilleur des deux mondes et de pousser l'utilisation des
  90. méthodes formelles dans l'ingénierie du logiciel, que ce soit dans un cadre
  91. académique ou industriel.
  92. L'un des piliers de l'{\idm} réside dans les transformations de modèles. Nous
  93. souhaitons leur apporter plus de fiabilité en fournissant des outils s'appuyant
  94. sur le langage {\tom}. Celui-ci repose sur la réécriture et le filtrage pour
  95. manipuler et transformer des structures complexes. Il s'intègre au sein de
  96. langages généralistes tels que {\java} et offre des constructions dédiées
  97. permettant à l'utilisateur d'appréhender et d'exprimer plus aisément des
  98. algorithmes complexes à mettre en œuvre dans un langage généraliste. Fournir
  99. des constructions de haut niveau est un moyen de donner plus de confiance à
  100. l'utilisateur dans le code résultant : les algorithmes sont exprimés plus
  101. formellement et il est donc plus facile de raisonner dessus à des fins de
  102. vérification du logiciel. Un autre avantage d'une approche reposant sur des
  103. constructions dédiées réside dans la réduction des coûts de développement :
  104. l'usage de générateurs de code permet de réduire la quantité de travail et le
  105. temps par rapport à un développement manuel.
  106. \section*{Contributions}
  107. Dans ce contexte, la contribution de cette thèse comprend trois volets
  108. principaux :
  109. \begin{description}
  110. \item[Transformation de modèles par réécriture : ] Nous avons développé une
  111. méthode de transformation de modèles par réécriture de termes. Pour cela,
  112. nous opérons une transformation permettant de manipuler un modèle sous la
  113. forme d'un terme algébrique. Nous nous appuyons ensuite sur les stratégies
  114. de réécriture du langage {\tom} pour mettre en œuvre la méthode de
  115. transformation. Cette méthode se déroule en deux temps : nous effectuons
  116. d'abord une transformation par parties qui fournit des résultats partiels,
  117. puis nous résolvons ces résultats intermédiaires pour former le modèle
  118. cible résultant. Nous avons donc étendu le langage {\tom} en proposant un
  119. îlot formel dédié pour transformer les modèles. Ce nouvel îlot implémente
  120. notre méthode de transformation par réécriture.
  121. \item[Représentation algébrique de modèles : ] Pour transformer un modèle
  122. dans notre con\-tex\-te de réécriture de termes, il est nécessaire d'opérer au
  123. préalable un changement d'espace technologique. Pour ce faire, nous
  124. proposons un outil permettant de donner une vue algébrique d'un modèle. Il
  125. traduit un métamodèle donné en une signature algébrique intégrable dans
  126. notre environnement {\tom}.
  127. \item[Traçabilité d'une transformation de modèles : ] Afin de répondre aux
  128. exigences du processus de qualification, nous avons travaillé sur la
  129. traçabilité des transformations et avons proposé une traçabilité de
  130. spécification. Nous l'avons implémentée par un îlot formel dédié permettant
  131. d'ajouter une forme de traçabilité au sein d'un langage généraliste tel que
  132. {\java}.
  133. \end{description}
  134. %FIXME\ttodo{Ce paragraphe a-t-il sa place ici ?}
  135. Durant ce travail de thèse, nous nous sommes attelés à développer des outils
  136. opérationnels implémentant notre travail. Nous avons toujours gardé à l'esprit
  137. qu'ils doivent pouvoir être aussi utilisés par des utilisateurs extérieurs en
  138. vue d'un usage dans un cadre industriel. Nous avons donc expérimenté et
  139. amélioré nos outils afin de leur permettre un passage à l'échelle. De plus,
  140. tout ce que nous avons développé est disponible librement et gratuitement sur
  141. le site du projet {\tom}. L'ensemble de nos expériences reposant sur du code
  142. ouvert documenté ainsi que sur des modèles diffusés librement, cela assure leur
  143. reproductibilité par un utilisateur averti. Cet aspect d'ouverture et de
  144. diffusion libre des résultats et des données s'inscrit dans le mouvement de
  145. l'\emph{open science}, qui est indispensable à une recherche vérifiable et
  146. reproductible. Nous posons ainsi les conditions idéales pour tout utilisateur
  147. souhaitant tester, vérifier, utiliser, modifier et étendre nos travaux.
  148. %\section*{Questions de recherche}
  149. %
  150. %Des questions à trier et préciser, pour que ça devienne des questions de
  151. %recherche :
  152. %\begin{itemize}
  153. % \item Comment augmenter la confiance dans un logiciel développé avec une
  154. % approche {\idm} et destiné aux systèmes critiques ?
  155. % \item Comment améliorer la qualité du logiciel tout en limitant les coûts de
  156. % développement ? \todo{[outils accessibles, bien intégrés dans les
  157. % environnements classiques ; code réutilisable et modulaire ; facilités de
  158. % développement ; génération d'un maximum de code ; approche resolve + pas de
  159. % notion d'ordre + constructions haut-niveau + langage qui se greffe aux langages
  160. % généralistes]}
  161. % \item Quelles méthodes et techniques peut-on apporter à l'{\idm} pour
  162. % améliorer la qualité du logiciel ?
  163. % \item Peut-on utiliser des méthodes et des outils éprouvés d'autres domaines
  164. % pour ce domaine en plein essor qu'est l'{\idm} ? \todo{[s'appuyer sur Tom,
  165. % outil de transformation venant de FM]}
  166. % \item Est-il possible d'établir un pont entre le monde de la compilation et
  167. % et des grammaires, et celui des modèles ? \todo{[Tom-EMF]}
  168. % \item Comment représenter des modèles dans le monde des termes ? \todo{[Tom-EMF]}
  169. % \item Comment développer des logiciels sûrs avec une approche orientée
  170. % modèles ? \todo{[plusieurs leviers, faire de la vérification, faire des
  171. % transfo qualifiables]}
  172. % \item Les transformations étant au cœur de l'{\idm}, comment s'assurer
  173. % qu'elles n'introduisent pas de \emph{bugs} ? \todo{[transfo qualifiables,
  174. % traçabilité]}
  175. % \item Comment assurer la traçabilité d'une transformation ? \todo{[modèle de
  176. % lien]}
  177. % \item
  178. % \item L'utilisation des méthodes formelles est-elle accessible dans un milieu
  179. % non-académique qui n'est pas forcément spécialisé ? \todo{[question
  180. % rhétorique]}
  181. % \item Comment rendre les méthodes formelles utilisables en pratique dans le
  182. % milieu non-académique sans faire peur ? Mauvaise formulation évidemment :)
  183. % \todo{[pousser des outils accessibles reposant sur les MF, en restant
  184. % pragmatique]}
  185. % \item problème : outils de modélisation non qualifiés et non certifiés.
  186. % Comment certifier des outils ou aider à certifier des outils ?
  187. % \item pb MDE :
  188. % \begin{itemize}
  189. % \item beaucoup d'outils dans les chaînes de développement =>
  190. % Comment appréhender la complexité inhérente aux nouvelles chaînes de
  191. % développement ? \todo{[MDE]}
  192. % \item problématique de l'introduction d'outils "certifieurs" automatiques
  193. % \end{itemize}
  194. %\end{itemize}
  195. \section*{Plan de la thèse}
  196. \label{sec:plan}
  197. La suite de ce document se décompose en huit chapitres répartis dans deux
  198. grandes parties. La première consiste en un état de l'art de trois chapitres,
  199. traitant trois thématiques liées au contexte de cette thèse. La seconde
  200. constitue les contributions de ce travail de thèse. Nous résumons brièvement
  201. chaque chapitre.
  202. %La suite de ce document se décompose en huit chapitres répartis dans deux
  203. %grandes parties. La première consiste en un état de l'art de trois chapitres,
  204. %traitant trois thématiques liées au contexte de cette thèse :
  205. %\compresslist
  206. %\begin{itemize}
  207. %%\compresslist
  208. % \item[\textbf{Chapitre 1 --}] Un langage basé sur la réécriture : Tom
  209. % \item[\textbf{Chapitre 2 --}] Transformations de modèles
  210. % \item[\textbf{Chapitre 3 --}] Vérification du logiciel
  211. %\end{itemize}
  212. %La seconde partie regroupe les contributions de ce travail de thèse, découpées
  213. %en cinq chapitres :
  214. %\begin{itemize}
  215. % \item[\textbf{Chapitre 4 --}] Transformations de modèles par réécriture
  216. % \item[\textbf{Chapitre 5 --}] Spécification et traçabilité des transformations
  217. % \item[\textbf{Chapitre 6 --}] Outils pour exprimer une transformation de modèles en {\tom}
  218. % \item[\textbf{Chapitre 7 --}] Études de cas : illustration et utilisation du langage
  219. % \item[\textbf{Chapitre 8 --}] Résultats expérimentaux
  220. %\end{itemize}
  221. \noindent \textbf{Conseils et guide de lecture :} Chaque chapitre de la
  222. première
  223. %\paragraph{ Conseils et guide de lecture} Chaque chapitre de la première
  224. partie peut être lu indépendamment des autres. Les chapitres~\ref{ch:approach}
  225. et~\ref{ch:traceability} expliquent le fond du travail de thèse, tandis que les
  226. chapitres~\ref{ch:outils},~\ref{ch:usecase} et~\ref{ch:evaluation} sont plus
  227. techniques. Le chapitre~\ref{ch:outils} décrit les travaux d'implémentation des
  228. deux chapitres précédents. Le chapitre~\ref{ch:usecase} illustre l'utilisation
  229. des outils appliqués sur deux cas d'étude. Le chapitre~\ref{ch:evaluation}
  230. comprend des résultats expérimentaux et donne des perspectives d'évolution
  231. technique de nos outils.
  232. \subsection*{Partie~\ref{part:sota} : État de l'art}
  233. Les trois chapitres composant l'état de l'art traitent de la réécriture et du
  234. langage {\tom}~\ref{ch:tom}, des transformations de modèles~\ref{ch:notions}
  235. ainsi que de la vérification du logiciel~\ref{ch:verification}.
  236. \subsubsection{Chapitre~\ref{ch:tom} -- Un langage basé sur la réécriture : Tom}
  237. Dans ce chapitre, nous donnons le cadre formel de la réécriture et définissons
  238. toutes les notions importantes sous-jacentes au langage {\tom}. Nous le
  239. décrivons ensuite et détaillons les différentes constructions le composant.
  240. Nous nous appuyons sur des exemples simples pour les illustrer. Ce chapitre
  241. peut constituer un manuel court du langage {\tom}.
  242. \subsubsection{Chapitre~\ref{ch:notions} -- Transformations de modèles}
  243. Ce chapitre donne le cadre de la modélisation et des transformations de
  244. modèles. Nous donnons une taxonomie des transformations qui se répartissent
  245. selon les critères liés aux métamodèles et aux changements de niveau
  246. d'abstraction. Nous expliquons aussi quelles sont les approches principales
  247. pour transformer des modèles et quels sont les outils existants.
  248. %expliquons comment les classifier et quelles sont les différentes approches de
  249. %transformations.
  250. \subsubsection{Chapitre~\ref{ch:verification} -- Vérification du logiciel}
  251. Ce chapitre décrit le contexte de la vérification du logiciel et plus
  252. particulièrement celui de la qualification et de la certification. C'est dans
  253. ce contexte que s'inscrit notre travail de thèse.
  254. \subsection*{Partie~\ref{part:contrib} : Contributions}
  255. La seconde partie regroupe les contributions de ce travail de thèse, découpées
  256. en cinq chapitres résumés ci-après.
  257. %\begin{itemize}
  258. % \item[\textbf{Chapitre 4 --}] Transformations de modèles par réécriture
  259. % \item[\textbf{Chapitre 5 --}] Spécification et traçabilité des transformations
  260. % \item[\textbf{Chapitre 6 --}] Outils pour exprimer une transformation de modèles en {\tom}
  261. % \item[\textbf{Chapitre 7 --}] Études de cas : illustration et utilisation du langage
  262. % \item[\textbf{Chapitre 8 --}] Résultats expérimentaux
  263. %\end{itemize}
  264. \subsubsection{Chapitre~\ref{ch:approach} -- Transformations de modèles par réécriture}
  265. Dans ce chapitre, nous exposons notre approche de transformation de modèles
  266. dans notre environnement utilisant la réécriture. Elle consiste à représenter
  267. des modèles sous la forme de termes en opérant un changement d'espace
  268. technologique, puis à effectuer une transformation par parties du modèle
  269. source. Chaque partie est transformée sans notion d'ordre grâce à une stratégie
  270. de réécriture. L'ensemble des transformations partielles est suivi d'une
  271. phase de résolution du résultat partiel et produit le modèle cible.
  272. \subsubsection{Chapitre~\ref{ch:traceability} -- Spécification et traçabilité des transformations}
  273. Dans ce chapitre, nous exprimons la traçabilité d'une transformation de modèle
  274. exigée par le processus de qualification. Elle consiste à lier les sources aux
  275. cibles de la transformation en fonction de la spécification.
  276. \subsubsection{Chapitre~\ref{ch:outils} -- Outils pour exprimer une transformation de modèles en Tom}
  277. Dans ce chapitre, nous détaillons les outils développés durant cette thèse pour
  278. la mise en œuvre des mécanismes expliqués dans les chapitres 4 et 5. Nous
  279. expliquons donc comment nous opérons le changement d'espace technologique, en
  280. quoi consiste le nouvel îlot formel du langage {\tom} pour exprimer une
  281. transformation de modèles. Nous décrivons l'implémentation au sein du projet
  282. {\tom}.
  283. \subsubsection{Chapitre~\ref{ch:usecase} -- Études de cas : illustration et utilisation du langage}
  284. Dans ce chapitre, nous illustrons l'utilisation de nos outils sur deux études
  285. de cas : \emph{SimplePDLToPetriNet} et l'aplatissement d'une hiérarchie de
  286. classe. La première étude permet de détailler le processus complet d'écriture.
  287. L'étude de la seconde transformation a pour but de montrer les points
  288. d'amélioration de nos outils et d'ouvrir des perspectives de recherche et de
  289. développement suite à ce travail.
  290. \subsubsection{Chapitre~\ref{ch:evaluation} -- Résultats expérimentaux}
  291. Ce chapitre est composé de résultats expérimentaux pour donner une première
  292. évaluation de nos outils. Nous les avons testés sur des modèles de tailles
  293. importantes afin de les pousser à leurs limites en termes de performances et de
  294. valider leur potentiel usage dans un cadre industriel. Nous décrivons aussi
  295. l'évolution de nos outils suite aux premières expériences et nous tirons
  296. certaines conclusions.
  297. %test de citation pour voir si les .bib fonctionnent :
  298. %\begin{itemize}
  299. %\item dans bach.bib : ~\cite{Bach2012}
  300. %\item dans ref.bib : ~\cite{emf09}
  301. %\end{itemize}
  302. % vim:spell spelllang=fr