Architecture proposée par Firas Bacha

42

II.2.3. Architecture proposée par Firas Bacha

Des chercheurs ont essayé de trouver des stratégies et des approches pour générer de manière automatique une IHM. Indépendamment de l’application à produire, des travaux ont proposé des démarches centrées sur l’architecture MDA. L’informatique étant de plus en plus nomade, la prise en compte du contexte dans les applications interactives est devenue indispensable pour pouvoir fournir la bonne information au bon moment (Brossard, Abed, & Kolski, 2009). Dans ce contexte, (Bacha, 2013) a proposé une architecture s’appuyant sur l’approche MDA pour une application interactive. Cette démarche a été créée dans le but de l’intégration de la personnalisation du contenu dans la conception et la génération des applications interactives. Cette thèse se focalise sur la modélisation des IHM du point de vue de la personnalisation. Dans le domaine des IHM, la pertinence des informations fournies et leur adaptation aux préférences et aux exigences des utilisateurs sont des facteurs clés de la réussite ou de l’échec d’une IHM.

II.2.3.1. Architecture générale de l’approche proposée par Firas Bacha

La stratégie de l’approche proposée par Firas Bacha est d’inclure la personnalisation du contenu dès la phase de la conception de l’IHM jusqu’à l’obtention d’une application interactive de manière automatique. Pour atteindre les objectifs fixés, cette démarche identifie les exigences selon la mise en œuvre de la personnalisation du contenu, la prise en compte de la personnalisation des premières phases de conception de l’IHM et la génération de l’IHM finale de manière semi-automatique. L’approche de Firas Bacha possède des caractéristiques techniques afin de pouvoir mettre en œuvre la personnalisation du contenu. Il est alors nécessaire de prendre en compte l’ensemble de informations et les sources de données sur le domaine d’application dans lequel l’application a été conçue et modélisée. Il faut également considérer le contexte pour pouvoir fournir à l’utilisateur des informations pertinentes et personnalisées. Le contexte comprend le triplet utilisateur (ceux qui interagissent avec l’application interactive, ils définissent leurs besoins dès le début de la modélisation conceptuelle), plateforme (que l’application a déployée) et l’environnement (les alentours de l’application, exemple : localité avec ou sans lumière, avec ou sans bruit, etc.).

En bref, cette approche a pour objectif d’inclure la personnalisation du contenu dès la phase de conception de l’IHM et de générer d’une manière semi-automatique une IHM finale. Elle respecte également l’architecture de type MDA proposée par l’OMG en permettant la

---

43

génération automatique des IHM à contenu personnalisé. Dans l’architecture proposée par Firas Bacha, il existe trois niveaux de modèle :

➢ Computational Independent Interaction Model (CIIM), comportant le modèle des tâches, pour décrire les interactions Homme-Machine dans un haut niveau d’abstraction, c’est l’équivalent du CIM en MDA ;

➢ Platform Independent Interaction Model (PIIM), pour spécifier l’IHM ainsi que l’ensemble d’interactions en utilisant un langage de description d’interface utilisateur, c’est l’équivalent du PIM en MDA ;

➢ Platform Specific Interaction Model (PSIM), pour projeter l’interface sur une plateforme spécifique, c’est l’équivalent du CIM en MDA.

La figure 14 représente l’architecture de type MDA de l’approche proposée.

---

44

Le concepteur a utilisé le modèle « Business Process Model » (BPM) pour modéliser au niveau CIM de l’approche MDA tandis que le PIM et le PSM sont nommés respectivement Platform Independent Interaction Model (PIIM) et Platform Specific Interaction Model (PSIM).

PIIM est l’équivalent de PIM dans l’architecture proposée par l’OMG et PSIM et l’équivalent du PSM en ajoutant le « I » qui signifie Interaction. Cette approche est alors intéressante pour une application interactive. La transformation du modèle du niveau PIM en modèle du niveau PSM est mise en œuvre via l’inclusion ou la modification des caractéristiques spécifiques à la plateforme cible.

II.2.3.2. Processus de génération de l’IHM

Il existe différentes étapes à suivre pour le processus de génération de l’IHM à contenu personnalisé. Ce processus consiste une série d’étapes partant d’un ensemble de modèles abstraits ou modèles conceptuels vers le code source décrivant l’application finale. Le premier modèle appelé aussi modèle de tâche décrit une notation abstraite et conceptuelle des IHM, il est alors utilisé dans n’importe quel domaine et plateforme. Pour avoir une IHM spécifique et dépendante de plateformes, le processus de génération se déroule en 4 étapes selon l’architecture générale de l’atelier logiciel proposée par Firas Bacha (Bacha, 2013):

Etape 1 : Création du « Business Process Model and Notation » (BPMN) annoté et réalisé à

l’aide d’Eclipse Modeling Framework (EMF). Il consiste à identifier le point d’entrée pour le moteur de transformation appelé ATLAS Transformation Language (ATL) ;

Etape 2 : Exécution des règles de transformation. Production d’un fichier appelé « User Interface Markup Language » (UIML) contenant uniquement les parties « structure » et

« behavior » ainsi que la partie style spécifique au contenu ;

Etape 3 : Recherche en vue de l’obtention du code UML complet. Pour ce faire, le concepteur

doit intervenir pour enrichir le code UIML généré, à l’aide d’EMF, pour y intégrer les parties manquantes spécifiques à la plateforme, à savoir présentation, logique et le reste de la partie style. Le fichier obtenu est toujours un fichier “.uiml”, mais qui contient la totalité des balises constituant un document UIML ;

Etape 4 : Traduction du code UIML obtenu via l’outil LiquidApps en code source d’une

plateforme spécifique. Ce code peut aussi subir une intervention de la part du développeur afin d’être modifié ou complété.

---

45

Dans le cadre de la génération automatique des IHM à contenu personnalisé, le concepteur doit en premier annoter les modèles de tâche par les modèles de personnalisation suivant différentes manières. En deuxième lieu, lorsque la préparation du modèle des tâches annotées est valide, le développeur peut transformer ce modèle en code UIML (User Interface Modeling Language) générique indépendant de la plateforme cible.

Le modèle généré décrit la personnalisation du contenu. Il comprend principalement trois parties : structure, behaviour ou comportement et style de UIML spécifique pour le contenu. Sachant que le code généré n’est pas complet, il faut lui rajouter les parties manquantes permettant de lier les éléments génériques à ceux spécifiques à une plateforme cible. Le passage du code UIML générique en spécifique s’appelle transition. Après, le développeur va personnaliser des parties du code UIML afin d’enrichir et mettre à jour ce modèle en intégrant davantage des propriétés requises. Cette étape s’appelle adaptation par rapport à des plateformes cibles. On peut finalement générer des codes sources de l’IHM finale après avoir obtenu un code UIML complet dont le style et le contenu à personnaliser conviennent aux critères des utilisateurs. Firas Bacha a résumé en six étapes majeures le processus de génération des IHM à contenus personnalisés :

1. Elaboration du modèle des tâches ;

2. Annotation du modèle des tâches par l’ensemble de modèles de personnalisation ;

3. Transformation du modèle des tâches annoté en code UIML générique ;

4. Transition du code UIML générique en code UIML spécifique avec une plateforme ;

5. Adaptation du style (présentation) des éléments de l’IHM en fonction de la plateforme cible ; 6. Génération du code source de l’IHM finale.

Le processus de génération de l’IHM à contenu personnalisé est présenté sur la figure 15 avec l’architecture générale de l’atelier logiciel.

---

46

Figure 15: Architecture générale de l’atelier logiciel et du processus de génération des IHM à contenu personnalisé (Bacha, 2013)

Sur le côté droit de cette figure 15, il y a l’Eclipse Modeling Framework (EMF) qui représente un support de modélisation et de validation de la conception. L’ATL sert à traduire le modèle BPMN annoté en un langage UIML. L’outil appelé LiquidApps permet d’interpréter le code UIML et de générer un code source en une plateforme spécifique. Sur le côté droit de cette figure 15, il y a une série d’étapes partant d’un ensemble de modèle abstrait en code source décrivant l’IHM finale. La conception commence avec l’élaboration du modèle BPMN. Le concepteur doit annoter le modèle, le développeur transforme ce modèle en code UIML générique indépendant de toute plateforme. Le développeur peut intervenir au niveau des parties UIML ajoutées pour les modifier et les enrichir en fonction de la plateforme cible. Le troisième état de l’art consiste à idendifier les approches pour la spécification et la composition semi-automatique des IHM.

II.3. Approche pour la spécification et la composition