Dans InterViews, le terme « modèle de composant » était employé pour appeler la représentation symbolique et dynamique écrite en VDL. Dans le cadre de Daft, le modèle était employé pour référer le concept de modèle médiateur qui était la description en VDL d’un composant lui-même écrit en Java. Toutefois la notion de modèle n’a pas été définie précisément : il s’agissait en fait d’une Vue. La problématique ayant été recentrée sur la notion de modèle, il est nécessaire de définir plus précisément quel sens aura le terme Modèle dans les développements ultérieurs de Daft.
Pour cette raison, nous allons tout d’abord étudier quelles sont les acceptions de ce terme dans le monde de l’informatique. Puis, comme le concept de modèle s’utilise aussi bien dans le cadre de nos projets que dans celui du développement logiciel, nous étudierons la question de savoir si ces modèles préexistants conviennent dans une architecture d’assistance. Cela nous permettra de conclure sur les principes généraux d’un modèle pour l’assistance.
3.4.1 Définition de la notion de modèle
Un large consensus s'est développé autour de la notion de modèle. Le premier consensus consistant à dire qu'il n'existe pas de définition universelle d'un modèle. Les modèles utilisés par les physiciens partagent peu de choses avec les modèles employés par un peintre. Ces modèles partagent néanmoins certaines caractéristiques.
La notion de modèle amène à affirmer l'existence d'un système étudié. L'exemple le plus fameux de la littérature pour illustrer les concepts de modélisation se rapporte à la cartographie : la carte d'un pays est vue comme une représentation de l'entité physique observable. Le modèle est vu comme une explicitation des caractéristiques que l'on veut faire ressortir à propos du système étudié. Ainsi, une carte politique et une carte hydrographique seront deux représentations différentes d'un même système étudié. L'informatique va restreindre ce cadre en proposant une contrainte exprimée dans la définition proposée par (Bézivin & Gerbé 2001), dans le cadre de l'UML:
« A model is a simplification of a system built with an intended goal in mind. The model should be able to answer questions in place of the actual system ».
Plus précisément, on peut encore restreindre cette définition en prenant celle de (Kleppe
et al. 2003) :
« A model is a description of (part of) a system written in a well-defined language ». Cette définition de modèle correspond parfaitement à notre propre utilisation du modèle : la représentation d'un système (l'application) dans un langage bien défini (langage DAFT) afin que celui-ci soit exploitable par la chaîne d'assistance.
3.4 - Les modèles en génie logiciel.
Par ailleurs, cette notion de modèle est utilisée par bien d'autres approches et techniques : programmation orientée objet, UML (Unified Modeling Language), Merise (Kettani et al. 1998) en sont de bons exemples. Chacune de ces méthodes s'applique à un problème particulier ou est une technique de codage particulière ; l'utilisation de la notion de modèle est par conséquent très hétérogène. La pression industrielle et la nécessité d’une plus grande interopérabilité a poussé industriels et chercheurs à mettre en place une approche intégrative identifiée sous la dénomination Ingénierie Dirigée par les Modèles (IDM) (Favre et al. 2006).
3.4.2 Ingénierie Dirigée par les Modèles - Introduction
L'IDM est la tendance actuelle en ingénierie d’une volonté commune, issue de plusieurs horizons, d'unifier des techniques de développement pour en stabiliser les outils de production, de déploiement et de communication interprocessus. C'est le résultat d'investigations poussées dans le domaine du développement logiciel, initiées par les industriels soucieux d'assurer une homogénéité dans la variété des standards utilisés. De par sa jeunesse, l'IDM est un secteur en plein développement dont les acteurs sont aussi bien des industriels que des laboratoires de recherche. Un consensus s'est toutefois développé autour des points suivants, considérés comme centraux par l'ensemble des acteurs :
- Favoriser un génie logiciel permettant une appréhension des applications selon différents points de vues (modèles) ;
- L’IDM doit avoir la capacité de composition et de cohérence entre ces points de vue ;
- Il y a une nécessité d’automatisation des outils permettant de valider ou composer des modèles et de générer du code.
Ainsi, de ce point de vue, l'UML apparaît comme un outil au service de l'IDM, existant parmi d'autres outils. La problématique majeure est justement d'assurer la cohérence entre tous ces outils afin de valider, d'exporter ou d'importer des modèles issus de ceux-ci en garantissant le respect des spéceux-cifications originales.
C'est l'OMG (Object Management Group) qui a proposé l'approche MDA (Model Driven Architecture) exprimant le plus clairement ces différents concepts dans l'objectif de réaliser les trois points précédemment cités. Néanmoins, si l'IDM et le MDA partagent de nombreux points communs, le MDA de l'OMG est une proposition technique subsumée par les concepts plus généraux de l'IDM.
Aussi, on va trouver dans le monde de l'industrie, différentes plates-formes MDA/IDM utilisées par les acteurs majeurs – à charge pour les chercheurs et les industriels d'en assurer l'interopérabilité. Les plus avancées sont issues de Microsoft avec Visual Studio et ses langages de domaines (DSL, Dynamic System Languages) et IBM grâce à Eclipse et son EMF (Eclipse Modeling Framework) et bien sûr, l'OMG avec sa technologie de transformation de modèles fondée sur UML appelée MOF/QVT (Meta-Object Facilities / Query View Transformation).
3.4.3 Principes généraux de l'IDM.
L'IDM se fonde sur la définition du terme « modèle » tel que donné en introduction de ce chapitre ; c'est-à-dire mettre en relation un modèle avec un Système étudié. Les concepts fondamentaux de l'ingénierie dirigée par les modèles tournent autour de deux relations importantes : ReprésentationDe (Atkinson & Kühne 2003) et EstConformeÀ (Favre 2004).
La première de ces relations – ReprésentationDe – est une relation bien connue en modélisation, elle est liée au concept de modèle, tel que défini au point précédent. ReprésentationDe sera donc le lien existant entre le système modélisé et la représentation de celui-ci.
L'IDM ne s'intéressera qu'aux modèles qu'on peut définir dans un langage bien formé. Le langage décrivant le modèle sera le Métamodèle. La notion de modèle et de métamodèle fait intervenir logiquement la deuxième relation : EstConformeA ; indiquant par celle-ci qu'un modèle est correctement défini et donc, qu'on peut lui appliquer des transformations.
Les modèles et métamodèles vont établir une pyramide hiérarchique de descriptions successives allant du métamodèle jusqu'à la production du code. Un exemple de cette organisation nous est donné par l'OMG avec son architecture MOF Figure 12).
Outre ces relations, l'IDM, via le MDA introduit la notion d'espace technique. Il s'agit de « l'ensemble des outils et techniques issus d'une pyramide de métamodèles dont le sommet est occupé par une famille de métamodèles similaires. » Par exemple, on pourra trouver la famille des modelware, ou bien des grammaware).
Figure 12 : architecture MOF à quatre niveaux, d’après l’OMG (Object Management Group (OMG)
3.4 - Les modèles en génie logiciel.
3.4.4 Les modèles pour l'assistance dans une perspective IDM.
Les modèles pour l’assistance peuvent s’insérer assez facilement dans cet univers de modélisation. Reprenons les différents éléments qui constituent notre domaine :
- Nous avons plusieurs systèmes observés (les acteurs : l'application, l'usager ainsi que les requêtes de l'usager) dont nous voulons fournir un modèle (section 3.1). - Afin de garantir la généricité, nous avons défini un langage (VDL) qui peut se
spécialiser par la suite pour modéliser un langage de requête (VQL) ou bien un langage de représentation d'application ou d'usager (définition d’une Vue dans VDL ou écriture d’un modèle de composant dans Daft).
Ces modèles obtenus, doivent être déployés vers les applications afin de garantir la synchronisation, impliquant donc un mécanisme de transformation ; de la même façon que des modèles d'assistance peuvent être obtenus par transformation de l'application existante.
On identifie de cette façon une hiérarchie de langages et de métalangages dont le sommet est VDL. On peut donc qualifier cet environnement de modélisation d’assistance d’espace technique que nous nommerons assistware (Figure 13).
Figure 13 : représentation de l’espace technique de l’assistance (assistware) à l’aide des langages décrits
dans le cadre des projets InterViews et Daft. Dans cette figure, les vues VDL sont à cheval sur les deux niveaux les plus bas car elles sont à la fois le modèle du composant et le composant lui-même (voir chapitre 2.2).