Décision et apprentissage

Dans un contexte de dynamique et de variabilité de l’environnement ambiant et des besoins de l’utilisateur, le moteur de composition opportuniste doit construire automatiquement des applications et les proposer à l’utilisateur, ce dernier devant être sollicitéa minima. Pour construire les bonnes applications au bon moment, le moteur doit prendre des décisions.

[DA1]- Décision : Dans le cas général, de par la présence de différents composants et ser-vices dans l’environnement ambiant, différentes connexions entre serser-vices sont pos-sibles donc différentes applications peuvent être construites. Par conséquent, le moteur doit faire des choix : il doit décider des connexions à réaliser et donc des applications à faire émerger.

[DA2]- Pertinence des applications : L’utilisateur doit bénéficier d’applications perti-nentes : dans le contexte courant de l’utilisateur, les applications doivent être utiles c’est-à-dire répondre à un besoin, en accord avec ses préférences et ses habitudes.

[DA3]- Connaissance : Pour prendre de bonnes décisions et faire émerger des applications pertinentes, le moteur doit disposer de connaissances.

[DA4]- Traitement de la nouveauté : Pour un composant nouveau (non encore rencontré) qui apparaît dans l’environnement ambiant, aucune connaissance n’existe. Un compo-sant nouveau doit néanmoins être considéré dans les choix de composition et pouvoir participer à une application émergente.

Pour prendre les bonnes décisions, le moteur ne dispose pas de plans d’assemblage pré-définis qu’il pourrait “instancier” à la volée avec les composants disponibles, ni de besoins ou de préférences explicitésa prioripar l’utilisateur et qui guideraient ses choix. Il doit donc lui-même construire les connaissances dont il a besoin.

[DA5]- Apprentissage : Le moteur doit construire lui-même les connaissances dont il a besoin pour prendre ses décisions. Ainsi, pour prendre les décisions à l’instant t, le moteur exploitera les connaissances apprises auparavant.

Quelles connaissances le moteur peut-il et doit-il acquérir pour prendre de bonnes dé-cisions ? À partir de quoi peut-il acquérir ces connaissances ? Comment va-t-il les procéder pour les construire ? Dans ce qui suit, nous allons analyser les deux premières questions.

Nous reviendrons à la troisième question dans le chapitre5.

[DA6]- Apprentissage des préférences de l’utilisateur : Le moteur doit construire des connaissances nécessaires pour que les applications qu’il propose à l’utilisateur soient pertinentes. Il doit apprendre les composants qu’il a l’habitude d’utiliser et les applica-tions qu’il préfère quand certains composants et leurs services sont présents dans l’en-vironnement ambiant. D’une certaine manière, il doit apprendre son besoin en fonction de l’environnement dans lequel il est plongé.

[DA7]- Sources d’apprentissage : Pour construire ses connaissances, le moteur pourrait exploiter différentes sources :

[DA7.1]- Observation des actions de l’utilisateur : Le moteur devrait exploiter les ac-tions de contrôle et d’édition effectuées par l’utilisateur. Les acac-tions d’acceptation, de refus ou de modification traduisent ses préférences en fonction de l’état de l’en-vironnement ambiant. Elles peuvent être enregistrées et transmises au moteur sous forme de feedback pour servir de base à des futures prises de décisions dans des situations similaires. Dans ce cas, le feedback de l’utilisateur est implicite et la fourniture du feedback n’entraîne pas de surcharge pour l’utilisateur.

Des observations plus fines (par exemple, temps de réaction de l’utilisateur, ac-tions sur une interface graphique d’édition. . .) pourraient donner des informaac-tions supplémentaires.

[DA7.2]- Expression de connaissances par l’utilisateur : Au prix d’un effort supplé-mentaire, l’utilisateur pourrait explicitement donner un feedback plus riche sur l’assemblage proposé, avant son déploiement ou après son utilisation.

[DA7.3]- Surveillance des applications : Le moteur pourrait aussi observer les appli-cations déployées (utilisation des composants participants, des services ou des connexions. . .) afin d’en extraire automatiquement une appréciation qualitative de leur utilisation.

[DA8]- Généricité de la décision et de l’apprentissage : La décision et l’apprentissage doivent opérer indépendamment des composants et des services concernés, de leur nature, et du domaine d’application. Le moteur OCE doit opérer sans connaissance préalable.

2.3 Conclusion

Nous avons présenté dans ce chapitre une analyse de la problématique et nous avons extrait un certains nombre d’exigences : les exigences architecturales (cf. section2.1) et les exigences d’apprentissage (cf. section2.2).

Les exigences architecturales qui concernent l’appropriation par l’utilisateur [AR6], le contrôle et l’édition par l’utilisateur[AR7][AR8][AR9]sont hors périmètre de ce travail de thèse. Elles sont au coeur de la problématique traitée dans le cadre de la thèse de M. Kous-saifi [KousKous-saifi, 2020].

Par ailleurs, l’exigence architecturale et celles d’apprentissage qui concernent l’explica-bilité des décisions du moteur[AR11]et la surveillance des applications déployées[DA7.3] ne seront pas traitées dans ce travail de thèse. Elles pourront faire l’objet de futurs travaux.

La fourniture explicite de connaissances par l’utilisateur[DA7.2]ne respecte pas l’exi-gence de discrétion [AR10], donc nous avons choisi de ne pas la traiter dans ce travail de thèse.

Il faut noter par ailleurs que, dans ce travail, nous faisons quelques hypothèses simpli-ficatrices. Nous supposons qu’il existe un réseau de communication qui supporte l’accès à des composants distribués, leur connexion et leurs interactions distantes. Nous faisons également abstraction des problèmes de sûreté de fonctionnement et de sécurité. Nous ne considérons pas le cas d’utilisateurs malintentionnés ni de composants ou de services mal-veillants. Ainsi, les applications construites par le moteur ne sont pas destinées à des sys-tèmes critiques.

D’autre part, nous ne traitons pas le problème de la sélection des services sur la base de leur sémantique et ne nous considérons pas les propriétés de qualité de service. Cette problématique complexe fait l’objet de nombreux tra-vaux de recherche [Moghaddam and Davis, 2014, Sun et al., 2014, Bouzary et al., 2018, Masdari and Khezri, 2020]. Nous n’apportons pas de contribution à ce sujet, et pour sim-plifier, notre solution met en œuvre une unification seulement syntaxique.

Dans le chapitre suivant, nous analysons l’état de l’art au regard de notre problématique et des exigences que nous avons formulées.