Soutenance mémoire
Télécharger le fichier pdf d’un mémoire de fin d’études
L’utilisateur au centre de la boucle
Dans ce contexte d’intelligence artificielle, le partage des responsabilités décisionnelles entre OCE et l’utilisateur est en question. Selon C. Evers et al. et [Faure et al., ], dans les environnements ambiants, l’utilisateur doit se placer au centre où il est l’acteur principal qui contrôle les applications.
Avec notre approche, en l’absence de besoins préalablement explicités, il est nécessaire non seulement de l’informer des applications qui émergent dans son environnement, mais aussi de lui laisser le contrôle sur ces dernières. Ainsi, il doit pouvoir accepter ou rejeter les applications proposées par le moteur. Éventuellement, l’utilisateur doit pouvoir éditer et modifier les assemblages proposés pour construire des applications qui répondent à ses besoins. Il pourrait aussi avoir la possibilité de construire lui-même des applications sans l’aide du moteur. Enfin, après l’acceptation de l’application par l’utilisateur, cette dernière doit être déployée dans son environnement pour qu’il puisse bénéficier des services qui lui sont offerts.
La figure 2.1 détaille la relation entre l’environnement, le moteur et l’utilisateur. Elle synthétise les problèmes principaux de cette thèse (indiqués en mauve dans le schéma) : la présentation de l’application émergente à l’utilisateur – le positionnement de l’utilisateur, son rôle et ses interventions – le feedback de l’utilisateur.
Reprenons le cas d’utilisation présenté dans la section précédente. Après avoir construit une application composée d’un curseur, d’un convertisseur et d’une lampe (en réalité, le système construit un modèle de configuration et non pas l’application proprement dite), le système doit présenter cette dernière à l’utilisateur à travers un outil dédié. L’utilisateur, à son tour, doit pouvoir intervenir sur l’application avant de décider de l’accepter pour la déployer ou de la rejeter. Par exemple, si cette application lui convient, l’utilisateur doit pouvoir indiquer qu’il l’accepte pour être déployée dans son environnement. Cependant, il peut arriver que l’application proposée par le moteur ne convienne pas au besoin actuel de l’utilisateur. Ce dernier doit donc aussi posséder le privilège de la modifier pour l’ajuster à ses besoins. En outre, s’il ne souhaite pas ou ne veut pas la modifier, il peut la rejeter.
Présentation et description de l’application émergente
En l’absence de spécification préalable, les applications émergentes sont a priori incon-nues. Elles résultent du travail du moteur intelligent qui propose des compositions de com-posants, qui n’ont pas obligatoirement été développés pour être composés ensemble, parce que l’environnement courant le permet. La composition repose sur des préférences et des habitudes apprises des utilisateurs et sur la correspondance entre les interfaces des compo-sants.
Au centre du système, l’utilisateur doit être informé de l’émergence d’une application, de ses fonctionnalités et de la manière de l’utiliser. Ceci va lui permettre de comprendre l’application et de pouvoir considérer si elle répond à ses besoins pour l’accepter ou la reje-ter. Par conséquent, les applications émergentes doivent être décrites de manière intelligible à l’utilisateur, qui peut être un utilisateur non familier avec les langages de programma-tion en particulier, ou avec le domaine de l’informatique en général. L’utilisateur peut, par exemple,être l’habitant d’une maison intelligente ou un voyageur utilisant les transports publics d’une ville intelligente.
Pour assister l’utilisateur, la description de l’application doit couvrir deux notions :
1. L’application doit être présentée à l’utilisateur d’une façon compréhensible. Ainsi, sa description doit être adaptée à son profil et composée de différentes descriptions fonc-tionnelles et structurelles.
2. L’application doit être modifiable par l’utilisateur pour ainsi lui laisser le contrôle sur ce qu’il veut utiliser.
Représentation au moyen de plusieurs vues
Comme mentionné dans la section précédente, l’utilisateur n’est pas toujours expert dans le domaine de l’informatique, donc il ne sera pas capable de comprendre comment l’application a été conçue si cette dernière est présentée d’une façon complexe. Par consé-quent, l’application devrait être présentée sous la forme appropriée, en fonction du profil de l’utilisateur.
Voici les questions de recherche associées à ce problème :
1. Comment adapter la présentation d’une application à des utilisateurs aux profils et compétences différents ?
2. Comment présenter une application à un utilisateur d’une façon plus riche, détaillée et compréhensible ?
Description fonctionnelle de l’application
Pour illustrer ce problème, considérons le cas d’utilisation présenté dans la section 2.1. Lorsque l’application d’éclairage va être présentée à l’habitant d’une façon adaptée à ses compétences, il va pouvoir comprendre sa structure en termes de composants et services utilisés pour réaliser l’assemblage. Cependant, il peut ne pas savoir, avec cette seule repré-sentation structurelle, le service offert par cette application ni comment l’utiliser.
Par conséquent, le problème ici réside dans la construction d’une description sémantique compréhensible à partir des composants participants qui, en complément de la représen-tation structurelle, aide l’utilisateur à mieux connaître son application. Plus précisément, il s’agit de savoir comment utiliser une application et quel service elle offre. Par exemple, l’uti-lisateur doit obtenir une description comme “Si tu déplaces le curseur du Slider, la lampe sera en état On ou Off ».
Un autre question se pose alors, elle est liée aux descriptions des composants et de leurs services, qui seront utilisées lors de la construction de la description de l’application. Autre-ment dit, comment passer de descriptions unitaires à une description globale.
Dans cette thèse, les questions de recherche liées à ces deux problèmes sont les suivantes :
1. Quel est le langage à utiliser pour décrire efficacement les composants et leurs services ?
2. Comment construire une description d’une application émergente à partir des descrip-tions unitaires des composants et services ?
Feedback de l’utilisateur
Dans notre architecture, le moteur propose des applications qui doivent correspondre aux besoins de l’utilisateur. Pour proposer des applications pertinentes, le moteur OCE a be-soin d’enrichir sa connaissance en apprenant le besoin de l’utilisateur [Younes et al., 2019b]. Ainsi, OCE a besoin d’un retour sur les applications qu’il propose tout en ne surchargeant pas son utilisateur en lui demandant une contribution explicite. Le feedback doit donc être capturé le plus automatiquement possible, en minimisant la sollicitation de l’utilisateur. Pour cela, il peut être construit en se basant sur les modifications que l’utilisateur a fait sur l’application proposée et sur le fait qu’il l’a acceptée ou l’a rejetée.
Les questions de recherche associées à ce problème sont :
1. Comment capturer les préférences de l’utilisateur pour alimenter l’apprentissage d’OCE ?
2. Comment intégrer le moteur avec l’éditeur pour permettre l’échange de données ?
Pour répondre aux problèmes posés dans les sections précédentes, nous avons explicité plusieurs exigences listées ci-dessous. D’une manière générale, l’utilisateur doit être informé de l’émergence de nouvelles applications qui sont poussées par OCE. Il doit pouvoir contrô-ler ces applications grâce à des privilèges qui lui permettent d’éditer, d’accepter ou de reje-ter une application. En outre, l’utilisateur doit comprendre ce que l’application lui présente comme service et comment il peut l’utiliser. Enfin, pour améliorer ses décisions, OCE doit apprendre les préférences de l’utilisateur à travers les interventions de ce dernier.
Les exigences sont réparties en 5 catégories : la présentation de l’application, sa com-préhensibilité, sa génération automatique, le rôle et les privilèges de l’utilisateur et enfin, le retour d’information de ce dernier.
Présentation
Le moteur de composition, selon la disponibilité de composants dans l’environnement à un instant t, propose des assemblages à partir de ces derniers et fait ainsi émerger des ap-plications. Comme ces applications peuvent être inconnues ou inattendues par l’utilisateur, celui-ci doit être informé à la fois de leurs fonctionnalités et de la manière de les utiliser. Pour solliciter a minima l’utilisateur, la présentation doit être automatique.
[R1.1] Description fonctionnelle. La fonction de l’application doit être présentée à l’utili-sateur. Par exemple, “L’application permet d’allumer la lampe”.
[R1.2] Instructions d’utilisation. Les instructions relatives à l’utilisation de l’application doivent être présentées à l’utilisateur. Par exemple, “Cliquer sur le bouton de l’interrupteur pour allumer ou éteindre la lumière”.
Compréhensibilité
La présentation de l’application peut être plus ou moins efficace selon le profil de l’utili-sateur et ses compétences. Ce dernier peut être un expert en informatique ou un utilisateur moyen qui n’est pas nécessairement familier avec la programmation. Cependant, une bonne compréhension par l’utilisateur des applications présentées est essentielle pour leur accepta-tion et leur utilisation, et pour la pertinence et la qualité du retour de l’utilisateur. Une autre question est liée à la complexité de l’assemblage en nombre de composants et de services.
[R2.1] Intelligibilité de la description. La description de l’application doit être compré-hensible par un utilisateur moyen, sans compétence dans le domaine de la programmation (comme le CBSE par exemple).
[R2.2] Extensibilité de la description. La description doit être utile, compréhensible et intelligible même lorsque l’application comporte plusieurs composants (par exemple, une dizaine de composants).
Génération automatique
Le problème réside dans la construction de la description d’une application qui a été construite par une autre entité. Cette construction doit s’effectuer sans intervention ou sou-tien humain.
[R3] Automatisation et composabilité. La description de l’application doit être construite et présentée automatiquement, en combinant les descriptions unitaires des composants qui la composent et de leurs services.
Rôles et privilèges de l’utilisateur
Toutes les applications émergentes, proposées par le moteur, doivent rester sous le contrôle des utilisateurs. C’est à lui de décider de déployer ou de refuser ces dernières. De plus, un utilisateur doit avoir la possibilité de personnaliser lui-même les applications et l’environnement ambiant, en fonction de ses besoins et de ses préférences de configuration. Durant cette tâche, il doit être orienté et guidé pour arriver à des applications pertinentes.
[R4.1] Interventions de l’utilisateur. L’utilisateur doit être capable d’accepter les applica-tions émergentes [R4.1.1] pour être déployées ou les rejeter [R4.1.2]. En fonction de son profil et de ses compétences, l’utilisateur doit être capable d’éditer et modifier le modèle de l’application [R4.1.3], c’est-à-dire créer, changer ou supprimer une connexion entre les services des composants qui constituent l’application.
[R4.2] Assistance à l’utilisateur. Durant la phase d’édition, l’utilisateur doit être assisté pour garantir la construction d’applications correctes.
Retour d’information de l’utilisateur
La pertinence des applications construites par OCE dépend de sa connaissance du be-soin de l’utilisateur. Pour apprendre le besoin de l’utilisateur et être capable de lui fournir les bonnes applications, OCE a besoin de son retour sur les applications proposées. Mais, cette étape doit être faite sans déranger l’utilisateur ni le surcharger par des actions supplé-mentaires à réaliser [Younes et al., 2019b].
[R5.1] Génération du retour d’informations. Un retour d’information doit être produit pour OCE à partir des interventions de l’utilisateur sur les applications émergentes.
[R5.2] Discrétion de la génération du retour d’informations. L’utilisateur ne doit pas être surchargé par des actions dédiées à la génération du retour d’informations.
Ces exigences ainsi formalisées (sous la forme de 10 énoncés Ri.j) nous ont été utiles pour guider les réflexions et les propositions de solution. De même, les travaux présentés dans l’état de l’art sont analysés à travers le prisme de ces exigences.
L’utilisateur au centre de la boucle
Designing the Human in the Loop of Self-Adaptive Systems [Gil et al., 2016] Dans cet article, les auteurs expliquent comment les systèmes auto-adaptatifs, mettant en œuvre le modèle MAPE-K, peuvent se comporter de manière inattendue et possèdent un caractère dynamique et instable. L’auto-adaptation est une exigence clé des systèmes logiciels émer-gents qui doivent devenir capables d’adapter continuellement leur comportement en cours d’exécution à leur contexte : changement du besoin de l’utilisateur, changement de la dispo-nibilité des ressources et, plus généralement, instabilité de l’environnement.
Ce travail définit les facteurs clés pour favoriser la participation humaine dans les boucles de contrôle en introduisant un cadre pour conserver leur participation : la trans-parence, l’intelligibilité, la contrôlabilité et la gestion de l’attention des utilisateurs forment ces exigences majeures. Il s’intéresse également à la dynamique entre les différents types de participations humaines en fonction des différentes limitations du système et de la situation actuelle de l’utilisateur.
Les auteurs montrent d’après leurs expérimentations comment l’utilisateur doit être im-pliqué dans le processus d’adaptation : il peut aider le système à mieux s’adapter aux besoins et demandes à travers un apprentissage dynamique de son intervention et de son feedback.
L’analyse de ce papier et celles des suivants sont présentées à la fin de chapitre (cf. section 3.5). The user in the loop : Enabling user participation for self-adaptive applications [Evers et al., 2014] Les auteurs montrent que les systèmes informatiques doivent s’adapter de manière autonome aux situations et aux besoins de l’utilisateur (sans le surcharger ou lui demander explicitement). Cependant, le comportement auto-adaptatif n’est pas satisfaisant s’il ne correspond pas aux intentions d’interaction de l’utilisateur.
Les auteurs proposent une solution pour intégrer l’utilisateur dans la boucle, sachant que la convivialité et la modélisation des préférences sont les principales exigences. L’uti-lisateur sera en mesure d’influencer le comportement d’adaptation au moment de l’exé-cution et à plus long terme en définissant des préférences individuelles. Pour réussir cette tâche, le système repose sur des modèles de variabilité construits au moment de la conception et des préférences définies par l’utilisateur. Ces processus sont réalisés à travers un outil que les auteurs ont développé dans le cadre de leur projet : MUSIC [Geihs et al., 2009, Floch et al., 2013]. MUSIC n’est pas conçu pour avoir des connexions avec l’application adaptative une fois qu’elle est instanciée et démarrée. Pour la modifier et la re-configurer, l’application doit être arrêtée puis redéployée.
En outre, pour des raisons d’acceptabilité, les composants « centrés sur l’utilisateur » (c’est-à-dire les composants qui sont dans le champ d’action réel de l’utilisateur, par op-position aux composants « en arrière-plan ») sont exclus de l’adaptation dynamique.
Finalement, la contribution de l’utilisateur peut être plus ou moins explicite : il peut sélectionner et ajuster une application, accepter ou rejeter une application, changer ses pré-férences, ou même repousser le comportement d’adaptation.
L’utilisateur au centre de la boucle
Opportunistic Composition of Human-Computer Interactions in Ambient Spaces [Degas et al., 2016] Les auteurs montrent que les utilisateurs doivent être maintenus dans la boucle pour interagir avec leurs applications conçues à partir des composants disponibles dans leur environnement ambiant. Ces derniers consistent en un ensemble de dispositifs qui peuvent apparaître et disparaître pour des raisons multiples : mauvais fonctionnement, changement des besoins, déplacement de l’utilisateur dans son environnement. . . Pour s’adapter à l’instabilité de l’environnement, les applications doivent être conçues d’une ma-nière intelligente en se basant sur l’opportunité d’assembler les composants existants. Ceci mène à un système d’interaction homme/machine (IHM) dynamique.
Pour réussir à maintenir la continuité et le dynamisme des systèmes d’IHM, les auteurs ont développé un système multi-agent qui se base sur l’opportunité de la disponibilité de composants pour assembler des applications. Pour réaliser ces assemblages, chaque compo-sant est géré par un agent qui communique avec d’autres disponibles dans l’environnement pour décider s’ils sont compatibles pour créer une connexion entre eux. Les auteurs ont pro-posé d’utiliser une « Meta-UI » [Coutaz, 2007] pour présenter les applications émergentes à l’utilisateur et lui permettre de voir les composants utilisés et d’observer l’exécution des ap-plications dans l’environnement. Cependant, l’utilisateur n’a pas un contrôle total sur son environnement et sur ses applications.
User in the Loop : Adaptive Smart Homes Exploiting User Feedback—State of the Art and Future Directions [Karami et al., 2016] Dans cet article, les auteurs présentent seulement une architecture générale qui est chargée d’adapter l’automatisation aux différents utilisa-teurs de leur maison intelligente. L’article se focalise sur la reconnaissance des activités des utilisateurs, leurs feedbacks et l’apprentissage du système. Les auteurs soutiennent que les préférences et le profil de l’utilisateur peuvent être appris (par des algorithmes d’apprentis-sage de renforcement semi-supervisés), associés à une reconnaissance d’activité qui trans-forme les données brutes en informations précises sur la situation de l’utilisateur. Ainsi, le feedback de l’utilisateur est un élément important qui aide le système à prendre une déci-sion personnalisée aux besoins de ce dernier dans son environnement et lui proposer des services plus pertinents.
An adaptive social statistics agent [Isbell et al., 2006] de chat Cobot qui se concentre sur le comportement multi-utilisateurs en utilisant l’apprentissage par renforcement.
Cependant, comme les auteurs le montrent, le problème de l’apprentissage à partir des feedbacks de plusieurs utilisateurs (et non d’experts) doit être traité d’une certaine ma-nière.Les utilisateurs ont des caractères différents et selon leurs besoins actuels, ils ont ten-dance à soit accepter le service offert à eux ou soit le rejeter. Alors, chaque utilisateur doit posséder une certaine partie du système dédié à son profil qui, à partir de ses préférences et feedbacks, lui propose des services qui répondent à ses besoins.
Développement et programmation par un utilisateur final
Experience with End-User Development for Smart Homes [Coutaz and Crowley, 2016]
Les auteurs proposent un système qui permet aux utilisateurs finaux de configurer et de contrôler leur maison intelligente à travers une interface. Les habitants de la maison uti-lisent des langages visuels et pseudo-naturels pour programmer leur environnement am-biant et ajouter ou supprimer des appareils à la volée, sachant que le système les aide par la proposition d’options possibles et les empêche de faire des erreurs.
En conclusion, les auteurs déclarent qu’il est possible de coupler l’EUD avec l’apprentis-sage. De plus, le service offert aux utilisateurs doit être toujours compris et adaptable à leurs situations. Ontology-driven service composition for end-users [Xiao et al., 2011] Dans cet article les auteurs déclarent qu’il n’existe pas de travaux qui donnent la possibilité aux utilisateurs finaux, ne disposant pas de compétences suffisantes en matière de composition de services, de composer leurs propres services.
Ainsi, les auteurs ont proposé de créer un outil qui assiste les utilisateurs dans la com-position du service via un éditeur qui leur permet de préciser leurs objectifs et besoins. Pour créer des applications, le système se base sur des mots-clés introduits par les utilisateurs durant la phase de conception, et en utilisant les descriptions des services et des ontologies disponibles, pour sélectionner les services et les assembler.
Le processus de génération de services possède une architecture ad hoc qui permet aux utilisateurs de personnaliser leurs applications en choisissant des modèles pré-configurés avant de les accepter et de les déployer.
Description de services
End User Development : Survey of an Emerging Field for Empowering People [Paternò, 2013] Dans cet article, les auteurs présentent plusieurs motivations qui favo-risent l’EUD. Diverses approches sont examinées et classées en fonction de leurs principales caractéristiques et des technologies et plates-formes pour lesquelles elles ont été dévelop-pées.
Plusieurs dimensions peuvent être utilisées pour comparer les différentes approches de l’EUD pour les applications.
La première est le caractère générique de l’approche, où il faut vérifier si elle est spéci-fique à un domaine d’application ou si elle peut être exploitée dans plusieurs domaines en même temps. Par exemple, il existe des approches qui ont ciblé des experts de domaines spécifiques, tels que par exemple des soignants [Carmien and Fischer, 2008], des biologistes [Letondal and Mackay, 2004], des conservateurs de musée [Ghiani et al., 2009]. Dans ces ap-proches des outils permettent aux utilisateurs sans expérience en programmation (mais ex-perts dans leur domaine) de personnaliser les fonctionnalités et l’interface de leurs applica-tions. Cependant, il existe des approches qui ne dépendent pas du domaine d’application et qui ont été utilisées pour divers types d’applications, tel que “App Inventor” [MIT, 2020]. Ce dernier est un environnement qui permet à tous les utilisateurs (experts ou non) de créer des applications entièrement fonctionnelles pour les smartphones.
La deuxième dimension est la couverture des principaux aspects des applications inter-actives : certaines approches se concentrent uniquement sur le développement de la partie interactive, comme “Denim tools” [Newman et al., 2003], et d’autres visent à couvrir égale-ment les parties fonctionnelles, par exemple “ServFace Builder” [Nestler et al., 2010].
Description de services
Pour qui et pourquoi les services sont décrits
Web services composition : A decade’s overview. [Sheng et al., 2014] Les auteurs pré-sentent une vue d’ensemble sur les langages de description de services et les approches de composition automatique de services web. De plus, les auteurs montrent l’utilité de la description des services durant la composition et comment ils sont utilisés.
La composition des services web se déroule sur plusieurs étapes [Zeng et al., 2003] afin de répondre à la demande de l’utilisateur. Tout d’abord l’utilisateur indique son besoin explicitement, puis la phase de recherche et de sélection de services se déclenche. Cette phase est basée sur la correspondance entre une requête (représentant le besoin de l’utilisateur) et les descriptions des services web disponibles. Il existe deux façons de mettre en œuvre la découverte de services : la correspondance syntaxique et la correspondance sémantique. La première n’offre que des possibilités de recherche basées sur les noms et les identifiants des services. En revanche, dans les méthodes basées sur la sémantique, les services web sont fournis avec des descriptions sémantiques de nombreux aspects (par exemple, les opéra-tions, les entrées, les sorties et même les capacités et le comportement), pour augmenter la précision pour trouver des services web [Wang and Vassileva, 2007, Zeng et al., 2004].
Enfin, après avoir sélectionné les services, le système commence à les assembler pour créer le service composite répondant aux besoins de l’utilisateur [Zeng et al., 2003, Liangzhao Zeng et al., 2004, Sheng et al., 2014].
En conclusion, les descriptions de services sont utilisées par le système pour sélectionner et composer des services qui répondent aux demandes des utilisateurs.
Ontology-driven service composition for end-users [Xiao et al., 2011] Les auteurs pro-posent une plateforme de composition de services centrée sur l’utilisateur, plus précisément sur les utilisateurs finaux sans compétences en ingénierie, pour configurer leurs services. Les utilisateurs finaux définissent d’abord leurs objectifs en utilisant quelques mots-clés. Puis, le système analyse leur demande, cherche et trouve des services pour les assembler afin de créer un ou plusieurs services qui répondent aux besoins des utilisateurs. Ensuite, un éditeur présente les services proposés et suggère des processus possibles et modifiables.
Semantics Based Service Orchestration in IoT [Chindenga et al., 2017] Les auteurs pré-sentent une plateforme sémantique de l’internet des objets pour soutenir l’orchestration dy-namique des services. Ces derniers peuvent être de plusieurs types et viennent de plusieurs sources hétérogènes.
L’objectif de cette plateforme est d’être capable de proposer à l’utilisateur le service qu’il demande. En outre, la plateforme est basée sur les ontologies pour représenter la séman-tique, permettant un format d’échange d’informations cohérent. Ceci rend la phase d’orches-tration de services plus pertinente et rend le système capable de sélectionner les meilleurs services répondant à la requête de l’utilisateur. En combinant des ontologies spécifiques à un domaine, les composants et les services seront décrits d’une manière abstraite, ce qui facilite l’analyse de l’orchestration de services dans des environnements hétérogènes.
Semantic description of services : issues and examples [Hurault et al., 2009] Cet article se focalise sur les langages de description de services et montre leur importance dans la com-position de services web. Les auteurs présentent plusieurs langages différents dont l’utilisa-tion dépend du contexte du projet. D’une autre manière, il n’existe aucun langage meilleur qu’un autre, mais il faut choisir le langage qui réponde le mieux au problème en question.
Les deux familles de langages présentés par les auteurs sont SOA.
[Lawler and Howell-Barber, 2007, Newcomer and Lomow, 2005] et OWL.
[Antoniou and Van Harmelen, 2004, McGuinness et al., 2004].
La première famille décrit les services en se focalisant sur leur signature : types d’en-trée et de sortie des données du service, par exemple Java RMI [Oracle, 2020] et WSDL [W3C, 2007]. L’avantage de cette famille de description est la facilité d’accès et de manipu-lation durant la construction d’un service composite. En revanche, elle n’est pas suffisante pour une composition plus complexe.
La deuxième famille étend les métadonnées du langage et se base complètement sur des ontologies. L’avantage d’utiliser des ontologies est la possibilité d’avoir une description plus formelle et elle permet d’associer plusieurs entités ensemble en se basant sur la des-cription. Ceci permet une sélection de services plus pertinente et plus précise. Cependant, la définition d’une ontologie pour résoudre un problème particulier est difficile à réaliser.
A Semantically-enhanced Component-based Architecture for Software Composition [Gomez et al., 2006] L’article présente une architecture pour la composition de compo-sants logiciels en utilisant une description sémantique. Ceci est réalisable à travers l’utili-sation d’une ontologie qui définit explicitement la structure conceptuelle des terminologies utilisées dans la spécification des composants. L’objectif de cette architecture est de rendre la composition plus précise et de favoriser la re-utilisabilité des composants dans l’environ-nement.
Comment les services sont décrits
An overview and classification of service description approaches in automated service composition research [Fanjiang et al., 2017] Dans cet article, les auteurs présentent et classent les approches de description de services utilisées dans la recherche automatisée sur la composition des services.
En général, tous les langages de description industriels utilisés dans la composition au-tomatisée de services doivent comprendre à la fois des informations fonctionnelles et non fonctionnelles pour décrire un certain élément. Les informations fonctionnelles représentent les signatures d’un service qui consistent en des entrées et des sorties, éventuellement com-plétées par des conditions [Bartalos and Bieliková, 2012].
Cependant, pour améliorer la description et éventuellement permettre une sélection et une composition de services, la description fonctionnelle est complétée par la description extra-fonctionnelle qui consiste en des caractères d’optimisation et de qualité de service.
Cependant, les langages les plus utilisés dans la recherche sur la composition de ser-vices suivent un paradigme conceptuellement simplifié, basé sur des tuples. Ces langages se situent principalement au niveau conceptuel, ce qui signifie qu’ils sont dépourvus de spécifications complexes et ne présentent que les informations requises par l’approche cor-respondante mise au point par les concepteurs du système.
Semantic Web Service Description [Klusch, 2008] Cet article donne une vue d’ensemble sur plusieurs langages de descriptions de services et sur leurs caractéristiques. Une notion intéressante présentée dans cet article est que la description sémantique d’un service peut être seulement fonctionnelle dans la majorité des approches.
En général, la fonctionnalité d’un service peut être décrite à partir de ce qu’il fait et comment il fonctionne réellement. Les deux aspects de sa sémantique fonctionnelle sont saisis par un profil de service et par son modèle de processus.
Le profil décrit la signature du service constituée des paramètres d’entrée et de sortie et de conditions, des effets qui sont censés se produire avant ou après l’exécution du service, ainsi que de certaines informations supplémentaires sur la provenance telles que le nom du service, son domaine d’activité et son fournisseur. Le modèle de processus d’un service décrit comment il fonctionne en termes d’interaction entre les données et de flux de contrôle, sur la base d’un ensemble commun de flux de travail et sur la communication avec les autres services disponibles. La sémantique des services non fonctionnels est généralement décrite par rapport à un modèle de qualité de service (QoS) comprenant des contraintes de livraison, un modèle de coût avec des règles de tarification, de répudiation, de disponibilité et de politique de confidentialité. Ces éléments sont définis par les concepteurs et fournisseurs de services.
Semantic description of services : issues and examples [Hurault et al., 2009] Dans cet article les auteurs présentent des problèmes dans la description des services et proposent des solutions pour les résoudre. Dans le domaine de composition de services, il existe plusieurs langages qui peuvent être utilisés pour décrire les services de façon à être utilisables durant les phases de composition. Cette dernière consiste en trois étapes majeures : connaissance du besoin de l’utilisateur, recherche et sélection de services et finalement composition.
Cependant, d’après leur état de l’art, les auteurs montrent qu’il n’existe pas de langage idéal. Le premier problème, selon les auteurs, est que c’est difficile de trouver une descrip-tion suffisamment précise pour pouvoir dire qu’il s’agit d’une description complète d’un service. Deuxièmement, les auteurs soulignent la difficulté de développer des outils qui aident à trouver automatiquement les meilleurs services qui répondent à un certain besoin et les combiner pour créer le service composite.
Par exemple, dans la plupart des architectures orientées service [Newcomer and Lomow, 2005], la composition de services utilise des descriptions qui se basent seulement sur la signature des services (les entrées et les sorties), p. ex., CORBA [OMG, 2020a] et RMI [Oracle, 2020]. Ces types de langages ont l’avantage d’être facilement accessibles et utilisables durant la composition. Cependant, la signature ne suffit pas car, d’une part différentes fonctions peuvent avoir la même signature et, d’autre part deux services rendant la même fonction peuvent différer fondamentalement dans leurs performances. Par conséquent, la description du service peut inclure des propriétés extra-fonctionnelles, c’est-à-dire des propriétés liées à la qualité de service.
Ainsi, il n’existe pas de solution unique qui puisse convenir à tous les cas, mais, la des-cription doit être adaptée à plusieurs niveaux nécessaires pour répondre aux exigences po-sées par le contexte : la précision de la description, la rapidité de l’algorithme de correspon dance et la gestion de la combinaison.
Composing web services on the semantic web [Medjahed et al., 2003] Dans cet article les auteurs proposent un processus de composition de services web qui se base sur la descrip-tion de services et les ontologies. Les auteurs montrent aussi les différentes techniques pour créer des descriptions de services à partir d’autres qui existent déjà dans l’état de l’art.
Pour créer des langages de description, les auteurs mentionnent que le DAML-S [Ankolekar et al., 2002] est utilisé comme référence de base. Ce langage a introduit les no-tions de préconditions et de conséquences des services web pour répondre à la composition automatique. Cependant, la façon dont les services composites sont générés à l’aide des spé-cifications DAML-S n’est pas claire. Le DAML-S ne définit pas la notion de composabilité des services et ne tient pas compte des propriétés sémantiques telles que l’objectif, l’unité de paramètre et le rôle commercial du service. Actuellement, un langage qui se base sur le DAML-S a été proposé et il est connu sous le nom de OWL-S [Fanjiang et al., 2017, W3C, 2004]. Ce dernier est une ontologie pour la description des services du web sémantique qui permet leur découverte, composition et uti-lisation automatisées. La description des services basée sur l’ontologie s’est montrée efficace pour la sélection et la composition de services [Xiao et al., 2011].
Une des conclusions des auteurs montre que le choix du langage dépend du contexte de son utilisation. Alors pour une simple composition, un langage basique peut être uti-lisé. Il est également possible de modifier un langage existant pour répondre à l’exigence du système. Au contraire, si la composition est plus complexe et la qualité de service est importante, les langages qui se basent sur des ontologies sont recommandés.
IDM et systèmes ambiants
Runtime model based approach to IoT application development [Chen et al., 2015] Dans cet article les auteurs proposent d’utiliser les technologies de l’IDM pour modéliser les ap-plications Internet des Objets, en anglais “Internet of Things (IoT)”, développées dans le but de les configurer avec plus de pertinence. Pour réaliser cette tâche, les auteurs se basent sur une approche divisée en deux parties.
Tout d’abord, pour gérer les dispositifs existant dans l’environnement, les auteurs proposent des créer un métamodèle (avec caractère abstrait) qui représente ces derniers en mo-dèles d’exécution qui sont automatiquement connectés aux systèmes d’exécution corres-pondants, c’est-à-dire, associer chaque entité différente dans le métamodèle à son système correspondant.
Ensuite, pour être capable de simuler un cas d’utilisation particulier et tester le système, les auteurs proposent de construire un modèle personnalisé correspondant à ce dernier en le synchronisant avec le modèle d’exécution (le métamodèle) défini en avance. Ainsi, l’exécution du modèle sera garantie conforme au scénario personnalisé grâce à l’implé-mentation de nombreuses méthodes et mécanismes d’analyse ou de planifications centrées sur le modèle et offertes par l’IDM, tels que les vérificateurs de modèles [Rushby, 1995, Combemale et al., 2016]. Ces derniers garantissent que le modèle créé est construit correcte-ment selon le métamodèle, ce qui va permettre d’éviter les erreurs d’exécution.
D’après les expérimentations réalisées, les auteurs montrent l’avantage de l’utilisation d’une telle approche dans le domaine de l’IoT. Premièrement, l’IDM permet une modélisa-tion rapide et à la volée des applications IoT en garantissant la pertinence de cette dernière et en évitant les erreurs de déploiement. Ceci est permis grâce à la définition d’un méta-modèle et à la création de modèles personnalisés qui se basent sur ce métamodèle. Deuxiè-mement, utiliser l’IDM réduit considérablement la charge de travail du codage manuel, car l’ensemble de l’approche ne nécessite que la définition d’un groupe de métamodèles (un par contexte ou domaine d’application) pour manipuler des modèles d’application (initiali-sés par ces derniers) et générer automatiquement leurs codes.
MDE4IoT : Supporting the Internet of Things with Model-Driven Engineering [Ciccozzi and Spalazzese, 2016] Les objectifs pour utiliser les technologies MDE dans les applications IoT sont : (i) permettre de modéliser de façon abstraite les applications pour diminuer la complexité, et (ii) permettre d’automatiser la manipulation des modèles dans la phase d’adaptation à l’exécution. Les avantages sont : 1. MDE facilite la modélisation des applications dans le domaine de l’IoT. 2. C’est plus facile de manipuler et modifier des applications en utilisant les technologies MDE au lieu des technologies génériques. 3. Sou-tenir les développeurs durant la phase de conception d’une application tout en assurant la cohérence des modèles créés et durant la phase de déploiement grâce à la génération du code par transformation de modèle. 4. MDE permet de faire une adaptation automatique au changement en temps réel.
Les limites sont : 1. Un système dédié au développeur où l’utilisateur final n’est pas mis dans la boucle, ce qui ne lui permet pas de modifier ses applications pour satisfaire ses be-soins. 2. Ils n’ont pas parlé de model-checking dans leur approche. Il n’est pas sûr que les ap-plications modélisées soient pertinentes. Ceci est dû au fait de ne pas utiliser un métamodèle spécifique au domaine d’utilisation que souhaite l’utilisateur. En revanche, un métamodèle générique du langage UML est utilisé.
Analyse et positionnement
Le tableau 3.1 (p. 50) présente l’analyse des travaux de l’état de l’art en montrant com-ment chacun d’eux peut répondre aux exigences que nous avons définies. Le taux de ré-ponse à une exigence varie entre zéro et quatre “+”. Dans ce tableau, lorsqu’une exigence n’est pas couverte, cela signifie qu’elle est notée 0. De plus, les articles qui ne possèdent au-cune réponse à (au moins) une exigence sont des articles de synthèse de plusieurs travaux de composition ou sur des langages de description existants.
D’après cette analyse, aucun travail existant ne répond explicitement aux exigences [R1.1], [R1.2] et [R2.2]. Dans la majorité des travaux, les descriptions de services sont uti-lisées comme documentation, qui détaillent leur intention et leur utilisation. Une fois que l’utilisateur a défini son besoin, les concepteurs du système ou les processus automatisés de composition, en utilisant une approche “Top-down”, sélectionnent les meilleurs services pour créer l’application [Chindenga et al., 2017, Gomez et al., 2006, Fanjiang et al., 2017, Klusch, 2008]. La sélection des services se base sur leur description pour choisir les ser-vices qui répondent au mieux au besoin de l’utilisateur. Dans certains travaux, comme [Chen et al., 2015, Ciccozzi and Spalazzese, 2016], les applications créées sont présentées par les concepteurs à l’utilisateur en lui montrant ses fonctionnalités. Ceci n’est pas possible dans notre projet puisque la conception des applications est réalisée par une entité logicielle, le moteur de composition.
Traditionnellement, les services composites demandés sont spécifiés au début de manière à répondre à un besoin défini explicitement [Gil et al., 2016, Evers et al., 2014, Xiao et al., 2011], de sorte qu’il est inutile de produire des descriptions par la suite, puisque la fonctionnalité du service proposé est connu. Ce n’est pas le cas dans la composition opportuniste qui n’est pas guidée par un besoin explicite. Dans cette dernière, le moteur de composition ne se base pas sur la description des services pour choisir les meilleurs et pro-duire des applications, mais il se base sur les préférences de l’utilisateur qui sont apprises au fur et à mesure de l’exécution du système. Nous n’avons pas trouvé de travaux qui s’inté-ressent à la génération d’une description d’une application émergente. Ainsi, il n’existe pas de solutions utilisables pour répondre à tous les critères de [R1.1], [R1.2] et [R2.2].
Pour ce qui concerne les exigences [R2.1], [R4.1] et [R4.2], il existe des travaux qui ont cherché à y répondre en proposant des systèmes dédiés aux profils de leurs utilisa-teurs. En créant des éditeurs ad hoc, les auteurs ont réussi à présenter à l’utilisateur le résultat sous forme d’une représentation compréhensible et à lui permettre, d’une cer-taine manière, de faire des modifications possibles avant de déployer l’application. Dans [Coutaz and Crowley, 2016] les auteurs ont proposé un éditeur ad hoc qui permet aux utili-sateurs de différents profils (mais possédant un certain niveau en programmation) de pro-grammer leur environnement. Par exemple, les habitants de la maison utilisent des lan-gages visuels et pseudo-naturels pour personnaliser leur environnement ambiant. En outre, [Evers et al., 2014] proposent un éditeur qui présente à l’utilisateur plusieurs applications potentielles : il peut sélectionner et ajuster une application en changeant quelques éléments, accepter ou rejeter une application, voir même changer ses préférences.De la même manière, dans [Xiao et al., 2011] les auteurs proposent un éditeur dédié aux utilisateurs moyens pour les assister pendant la phase de conception de leurs applications. En précisant son besoin, l’utilisateur obtient une application avec une liste de modifications possibles pour lui per-mettre d’éventuellement changer la conception de cette dernière.
Cependant, dans les travaux qui répondent à ces exigences, certaines compétences sont requises par l’utilisateur, qui ne peut donc pas être novice. L’utilisateur ne possède pas un contrôle total sur la conception et il est limité à certaines modifications possibles sur son ap-plication qui n’est conçue qu’après avoir explicitement formulé les besoins. Ainsi, il y a peu ou pas d’intelligence (et pas d’émergence) dans les solutions EUD existantes, qui n’offrent que très peu de flexibilité et de personnalisation des application contrairement à la solution souhaitée dans cette thèse.
|
Table des matières
I Contexte et problématique
1 Contexte
1.1 Ingénierie logicielle à base de composants
1.2 Composition opportuniste
1.2.1 Principes et objectifs
1.2.2 Cas d’utilisation
1.2.3 Vue d’ensemble du système de composition
1.3 Développement et programmation par l’utilisateur final
1.4 Ingénierie dirigée par les modèles
1.4.1 Introduction
1.4.1.1 Métamodélisation
1.4.1.2 Langage spécifique à un domaine
1.4.1.3 Transformation de modèle
1.4.1.4 Éditeur
1.4.2 Outillage
1.4.2.1 GEMOC
1.4.2.2 Ecore
1.4.2.3 Sirius
1.4.2.4 Acceleo
2 Problématique et exigences
2.1 Problématique
2.1.1 L’utilisateur au centre de la boucle
2.1.2 Présentation et description de l’application émergente
2.1.2.1 Représentation au moyen de plusieurs vues
2.1.2.2 Description fonctionnelle de l’application
2.1.3 Feedback de l’utilisateur
2.2 Exigences
2.2.1 Présentation
2.2.2 Compréhensibilité
2.2.3 Génération automatique
2.2.4 Rôles et privilèges de l’utilisateur
2.2.5 Retour d’information de l’utilisateur
3 État de l’art
3.1 L’utilisateur au centre de la boucle
3.2 Développement et programmation par un utilisateur final
3.3 Description de services
3.3.1 Pour qui et pourquoi les services sont décrits
3.3.2 Comment les services sont décrits
3.4 IDM et systèmes ambiants
3.5 Analyse et positionnement
II Description automatisée centrée utilisateur des applications composites émergentes
4 Approche basée sur l’IDM pour assister l’utilisateur dans son environnement
4.1 L’environnement de contrôle interactif ICE
4.2 Architecture “Utilisateur au centre de la boucle”
4.3 Retour d’information sur l’utilisateur
4.4 Motivations pour utiliser l’IDM
5 Présentation structurelle de l’application émergente
5.1 Métamodèle d’un assemblage de composants
5.2 DSL pour une représentation sous forme d’un diagramme de composants
5.3 Transformation du modèle OCE en modèle ICE
5.4 Analyse de la proposition
6 Description multivue de l’application émergente
6.1 Introduction
6.2 DSL à base de pictogrammes
6.3 Transformation du modèle ICE en diagramme de séquence
6.4 Transformation du modèle ICE en modèle de description
6.4.1 Description à base de règles
6.4.2 Le métamodèle complet
6.4.3 Caractéristiques du langage
6.4.4 Principe de la combinaison et de la génération des règles
6.4.5 Retour de données
6.5 Conclusion
7 Rôle de l’utilisateur et feedback
7.1 Interventions de l’utilisateur
7.2 Feedback
7.3 Conclusion
III Développement, expérimentation et analyse
8 Développement d’ICE
8.1 Introduction
8.2 Étapes de développement
8.2.1 Définition du métamodèle
8.2.2 Définition de l’éditeur et des différents DSL
8.2.3 Descriptions multivues de l’application
8.2.3.1 Représentation à base de pictogrammes
8.2.3.2 Représentation sous forme d’un diagramme de séquence
8.2.3.3 Description à base de règles
8.2.4 Génération du feedback
8.3 Conclusion
9 Intégration avec OCE
9.1 Introduction
9.2 M[OI]CE : Exigences et principe
9.2.1 Exigences
9.2.1.1 Exigences ICE
9.2.1.2 Exigences OCE
9.2.2 Principe de la solution
9.3 M[OI]CE : Implémentation
9.3.1 Transformation du modèle OCE en modèle ICE
9.3.2 Calcul du feedback
9.4 Conclusion
10 Expérimentation
10.1 Introduction
10.2 Transition d’OCE vers ICE
10.3 Interventions de l’utilisateur
10.3.1 Assistance à l’utilisateur
10.3.2 Prise en compte du feedback
10.4 Description de plusieurs formes d’architecture
10.4.1 Architecture de type Filtres et Tubes
10.4.2 Architecture parallèle
10.4.3 Architecture non linéaire et séquentielle
10.4.4 Retour de données
11 Analyse de la contribution
11.1 Couverture des exigences
11.2 Apport et flexibilité de l’approche IDM
11.3 L’IDM pour présenter les applications à l’utilisateur final
Conclusion et perspectives
Bibliographie
Télécharger le rapport complet
