Elena Kornyshova

Local

HDR Elena Kornyshova

12/158 HDR cours de finalisation. Nous travaillons également sur une approche de fouille d'intentions basée sur les ontologies qui a pour but de fournir des recommandations contextuelles [Elali, 2021] [Elali, 2020].

Résumé en Français

Ma recherche est principalement orientée sur le développement des aspects méthodologiques et se concentre sur la configuration basée sur le contexte et sur les intentions pour aider les utilisateurs à prendre leurs décisions. Le but de la configuration est de personnaliser les méthodes, les processus, le comportement, et ainsi de suite et de les adapter au contexte donné. J'ai mené ce travail dans le contexte de l'ingénierie des méthodes et, au cours des sept dernières années, je me suis positionnée dans le contexte de la digitalisation afin de contribuer à la définition de la « Vie intelligente » (« Smart Life »).

Après une introduction des concepts principaux, je présente dans ce document l'évolution des mes thèmes de recherche avec un accent sur mes contributions à la contextualisation, la configuration et la Vie intelligente, je détaille mon expérience dans la direction et l'organisation de la recherche et je définis les futurs axes de ma recherche.

Contexte scientifique

Le cadre scientifique de ma recherche est organisé autour de : (i) la configuration basée sur le contexte et les intentions qui fait partie de l'ingénierie des méthodes situationnelles (IMS) et (ii) la digitalisation et la révolution de l'industrie 4.0 qui constituent le contexte technologique.

La configuration contextuelle provient du domaine de l'ingénierie des méthodes (IM) et, plus particulièrement, de l'ingénierie des méthodes situationnelles (IMS). L'IMS favorise l'idée de récupérer, de sélectionner et d'adapter les composants de méthodes à des situations concrètes, plutôt que d'utiliser les méthodologies initiales souvent mal adaptées au contexte [Rolland et al., 2001b]. Afin de réussir à créer des méthodologies qui conviennent au mieux à des situations données, l'identification des composants (les éléments structurants de base des méthodologies), leurs modélisation et stockage sont des activités très importantes. La configuration se fait en fonction du contexte et également dans certaines approches en fonction des intentions des utilisateurs. [Dey et al., 2001] définit la notion de contexte par l'information qui pourrait être utilisée pour caractériser la situation d'une entité (personne, objet ou ordinateur), et, plus généralement, par tout élément qui peut influencer le comportement du système d'information (SI). Une intention est un but qui peut être atteint par l'exécution d'une activité.

Mes travaux depuis sept ans s'inscrivent dans le cadre de la digitalisation qui, selon ma position, doit rendre la vie plus intelligente, c'est-à-dire les technologies d'information et de communication (TIC) doivent être mieux adaptées aux besoins des utilisateurs. Les applications et les appareils prévus pour faciliter la vie sont appelés, de façon générale, « intelligents » (« Smart »). Un très grand nombre d'applications intelligentes se développent en ce moment : Smart home, Smart city, Smart factory, etc. Ces applications ont une caractéristique commune qui est l'adaptation autonome du comportement des objets en fonction des données reçues de l'environnement, ce qui constitue en soi la configuration en fonction du contexte. Au sens plus large, cette tendance fait partie de la digitalisation. Selon [START_REF] Bockshecker | Systematization: digital transformation and phenomena[END_REF], le terme de digitalisation ou de transformation numérique désigne le processus de passage des ressources en numérique. L'Industrie 4.0 (ou I4.0) est l'une des récentes tendances de digitalisation dans le monde de la production. Le principe fondamental de l'industrie 4.0 est de rendre la fabrication « intelligente » en interconnectant les machines et l'équipement qui peuvent se contrôler mutuellement, c.-à-d. les systèmes cyber-physiques (CPS), pour la production de masse [START_REF] Xu | [END_REF]. L'Industrie 5.0 est conçu pour exploiter la créativité unique des experts humains pour collaborer avec des machines puissantes, intelligentes et précises. Il se concentre principalement sur la personnalisation et la personnalisation de masse, où les humains guident les robots [START_REF] Maddikunta | Industry 5.0: A survey on enabling technologies and potential application[END_REF], et sur l'amélioration de la satisfaction des clients. Les clients peuvent ainsi préférer des produits personnalisés adaptés à leurs goûts et besoins. Afin d'assurer une meilleure prise en compte des besoins des utilisateurs ainsi que la configuration en fonction du contexte et de leur besoin, une notion importante à prendre en compte est l'expérience utilisateur. Selon la norme ISO 9241-210, « L'expérience utilisateur est la perception et les réponses d'une personne qui découlent de l'utilisation réelle ou prévue d'un produit, d'un système ou d'un service » (définition tirée de [START_REF] Bongard-Blanchy | Dimensions of User Experience -from the Product Design Perspective: Journal d'Interaction Personne-Système[END_REF]). Nous croyons que les approches d'expériences utilisateurs doivent être conçues en prenant en compte toutes les dimensions du contexte utilisateur afin de fournir une expérience utilisateur personnalisée.

1.2 Évolution des thèmes de recherche J'ai commencé mon travail de recherche avec mon doctorat en économie et gestion dans le domaine de la gestion des processus métiers, soutenu en 2007 [Kornyshova, 2007c]. Le but était de développer une approche systémique de gestion des processus métiers (PM) dans les entreprises. Dans cette thèse, j'ai détaillé la classification des PM, proposé un modèle de cycle de vie des PM, développé une approche de gestion des PM en prenant en compte les éléments du contexte interne et externe de l'organisation. J'ai appliqué les résultats dans une entreprise du secteur électronique. J'ai publié les résultats obtenus dans les articles suivants [Kornyshova, 2007b] [ Kornyshova et al., 2007d] [ Kornyshova, 2006a] [Kornyshova, 2006b] [Kornyshova, 2006c] [Kornyshova, 2006d] [Kornyshova, 2005a] [Kornyshova, 2005b] [Kornyshova, 2005c].

La prochaine grande étape a été de contribuer au développement des aspects méthodologiques dans le cadre de l'ingénierie des méthodes situationnelles (IMS). J'ai travaillé sur la configuration des méthodes en fonction du contexte et des intentions des utilisateurs en utilisant principalement les méthodes de prise de décision multicritères. Lors de mon doctorat en informatique [Kornyshova, 2011], soutenu en 2011, j'ai développé l'approche MADISE, proposé une ontologie de prise de décision et une approche de contextualisation des méthodes. J'ai publié 23 articles durant ma thèse [Deneckère et al., 2011a] [Deneckère et al., 2011b] [Deneckère et al., 2011c] [Deneckère et al., 2010a] [Deneckère et al., 2010b] [Deneckère et al., 2009] [Deneckère et al., 2008] [Kornyshova et al., 2011a] [Kornyshova et al., 2011b] [Kornyshova et al., 2011c] [Kornyshova et al., 2010a] [Kornyshova et al., 2010b] [ [START_REF] Kornyshova | Which Method to Support Multicriteria Decision Making Systematically in IS Engineering[END_REF]] [Kornyshova et al., 2008a] [Kornyshova et al., 2008b] [Kornyshova et al., 2008c] [ Kornyshova et al., 2008d] [Kornyshova et al., 2008e] [Kornyshova, 2007a] [Kornyshova et al., 2007a] [ Kornyshova et al., 2007b] [ Kornyshova et al., 2007c] [Salinesi et al., 2006].

Depuis je continue à travailler sur les thématiques liées à l'ingénierie situationnelle. Avec le développement des applications intelligentes et de la digitalisation, la nature des données changent, les méthodes se sont multipliées, et on souhaite avoir le résultat rapidement, voire en temps réel. Les besoins en méthodes de configuration personnalisée se sont multipliés et accentués. Tous les principes de l'IMS de base sont impactés : la modularité, la réutilisation, la flexibilité et l'adaptation au contexte. Les méthodes de configuration doivent être remises en question pour prendre en compte ce nouveau contexte. Depuis sept ans, je me suis concentrée sur la question Comment la configuration contextuelle et basée sur les intentions peut aider les utilisateurs à prendre leurs décisions dans le cadre de la digitalisation ?

Dans le domaine de l'ingénierie situationnelle, mes travaux de recherche peuvent être séparés en deux grandes rubriques : la contextualisation (la définition et la formalisation du contexte) et la configuration (développement des modèles et des méthodes de prise de décision pouvant guider les utilisateurs dans la configuration). En plus, depuis quelques années, je m'intéresse aux problématiques d'amélioration des interactions des utilisateurs avec des technologies d'information et de communication (TIC). J'envisage ce sujet à travers la thématique de la Vie intelligente (Smart Life) qui réunit les diverses applications et les appareils qui ont pour but de faciliter et d'enrichir la vie des gens tant du point de vue personnel que professionnel.

Contextualisation

La première direction de recherche concerne l'amélioration de la méthodologie de contextualisation. Au sens large, la notion du contexte inclut toutes les caractéristiques pouvant impacter les méthodes, les processus, les interactions y compris les intentions des utilisateurs. Dans mes travaux ces deux notions (de contexte et d'intention) sont étroitement liées.

Dans le cadre de contextualisation, j'étudie trois aspects : la modélisation du contexte, la découverte du contexte et la découverte des intentions. Premièrement, j'ai travaillé sur la modélisation du contexte. Avec mes collègues, nous avons analysé la nature orientée objectif (téléologique) des processus d'ingénierie [Deneckère et al., 2010a] [ Deneckère et al., 2011a] afin de construire le modèle du contexte incluant la notion de décision. Nous avons développé un modèle générique du contexte incluant une typologie des caractéristiques du contexte et reliant le contexte aux composants des méthodes [Kornyshova et al., 2011b] [Kornyshova et al., 2010b] [Deneckère et al., 2014]. Actuellement, nous travaillons sur un modèle conceptuel de l'expérience utilisateur (User eXperience) qui permet de structurer les informations du contexte d'utilisation autours des profils des utilisateurs ou bien des personas (utilisateurs types dans un domaine) [Kornyshova et al., 2022b].

En ce qui concerne la découverte du contexte, j'ai contribué au développement de l'approche de définition du contexte [Kornyshova et al., 2011b] [ Kornyshova et al., 2010b]. Je contribue également aux travaux sur l'extraction du contexte à partir des logs de capteurs à l'aide d'ontologies [Elali et al., 2022b]. Nous avons proposé une approche pour combiner les données des capteurs et les logs d'événements à l'aide d'une ontologie de domaine que nous avons validé sur une étude de cas de maison intelligente. Nous avons proposé un modèle de processus contextuel enrichi par des informations en provenance des capteurs de la maison intelligente [Elali et al., 2023b] [Elali et al., 2022a].

Concernant la découverte des intentions, je travaille sur la fouille d'intentions qui a pour but de découvrir les intentions des utilisateurs en manipulant de grands volumes de données. Dans [START_REF] Deneckère | A Framework for Comparative Analysis of Intention Mining Approaches[END_REF][START_REF] Deneckère | [END_REF], nous avons développé un cadre de classification des travaux sur la fouille d'intentions. Nous avons validé ce cadre sur cinq travaux estimés les plus pertinents dans ce domaine. Un état de l'art détaillé sur les approches de fouille d'intentions est en Les méthodes de l'IMS peuvent être réutilisées dans d'autres contextes et la digitalisation et le développement des applications intelligentes créent beaucoup d'opportunités pour effectuer la configuration personnalisée : premièrement, afin d'adapter l'utilisation des composants digitaux à de différents contextes et, deuxièmement, pour adapter le fonctionnement des entités organisationnelles (organisations, individus, etc.) en utilisant l'apprentissage automatique, tous les deux en fonction des caractéristiques du contexte et des intentions des utilisateurs.

Pour la configuration des composants digitaux, je m'intéresse à la configuration des composants I4.0 en fonction des intentions des utilisateurs et des objectifs des organisations [Sadouki, 2022a] [Sadouki, 2022b]. Nous préparons en ce moment un état de l'art sur les approches orientées intentions dans l'industrie. La prochaine étape consiste à adapter/enrichir la description des composants de l'industrie 4.0 tels qu'ils sont définis dans le cadre RAMI4.0 [RAMI4.0, 2020]. Au niveau organisationnel, j'étudie comment les composants de l'industrie 4.0 s'intègrent dans l'architecture d'entreprise (AE) [Kornyshova et al., 2021b] [ Kornyshova et al., 2020] [ [START_REF] Kornyshova | Exploring the Impact produced by the Industry 4.0 on Enterprise Architecture Models[END_REF]. Nous avons établi le modèle et le processus de propagation des impacts I4.0 à travers des modèles d'AE. Nous avons appliqué les deux sur le cadre de référence en AE TOGAF 9.2. Pour compléter cette étude, nous avons établi une approche situationnelle appliquée au cadre de l'AE et l'avons appliqué également au TOGAF 9.2 [Kornyshova et al., 2022c].

Mes travaux sur la configuration des entités comprennent d'abord la configuration des écosystèmes commerciaux numériques (Digital Business Ecosystems -DBE). Nous proposons un système de recommandation de matchmaking [START_REF] Benramdane | Hybrid Machine Learning for Matchmaking in Digital Business Ecosystems[END_REF]] [Benramdane et al., 2021] [Kornyshova et al., 2023b] [Benramdane, 2022], implémenté sur une plateforme numérique, basé sur les algorithmes de machine learning supervisés. Dans notre recherche, nous avons réalisé une revue de littérature sur les techniques de matchmaking [START_REF] Benramdane | Supervised Machine Learning for Matchmaking in Digital Business Ecosystems and Platforms[END_REF]. La collaboration des entités nécessite leur authentification. Dans les écosystèmes où les dispositifs IoT peuvent être compromis, chaque entité doit s'assurer que les informations reçues des dispositifs IoT et échangées avec d'autres entités sont dignes de confiance. Nous explorons une approche décentralisée en utilisant un système d'identité auto-souverain (self-sovereign identity -SSI) qui s'appuie sur des algorithmes de consensus Blockchain, des identificateurs décentralisés (DID) et la preuve zéro-connaissance pour construire une relation de confiance entre les entités [Ouaili et al., 2022a] [Ouaili et al., 2022b]. En ce moment, nous travaillons sur un état de l'art sur l'identité auto-souveraine et sur l'intégration des SSI dans l'Internet des Objets.

Autres références récentes sur cette thématique sont : des rapports techniques [Kornyshova, 2022TRa] [ Kornyshova, 2022TRb] [ Kornyshova et al., 2022TRa] [ Kornyshova et al., 2022TRb] [ Kornyshova, 2021TR]; une communication scientifique [Kornyshova, 2016SCa]; l'encadrement d'un rapport d'ingénieur de recherche [Amine, 2022] et des mémoires d'étudiants [Benni, 2022] [Mezani, 2022] [Ouaili, 2021] [Yahiaoui, 2021].

Vie Intelligente

En plus de ces deux orientations, je m'intéresse également à l'amélioration des relations entre les utilisateurs et les TIC. Dans la littérature, les applications et les appareils conçus pour améliorer les différents aspects de la vie sont appelés « intelligents » (« Smart » : maison intelligente, ville intelligente etc.). Cependant, une définition partagée de ce terme n'existe pas. Nous nous sommes intéressés à la définition de « Smart » et nous avons défini la vie intelligente (Smart Life) [Kornyshova et al., 2022d] [ Kornyshova et al., 2023c] en utilisant l'approche systémique, avons introduit trois degrés de smartness : smart, intelligent et sentient. Nous avons établi une taxonomie et évolution des applications intelligentes [Kornyshova et al., 2022a] et nous avons analysé l'évolution de ces domaines dans le temps. Nous avons proposé un agenda de recherche dans ce domaine [Kornyshova et al., 2022d].

Une des premières étapes dans la conception et le développement des applications est l'ingénierie des exigences. De mon point de vue, les applications intelligentes impliquent un nouveau type d'exigences qui concernent le bien-être des personnes qui les utilisent. Pour cela, nous avons proposé un nouveau type d'exigences que nous avons appelées « sentientes » [Kornyshova et al., 2021a]. Le mot sentient signifie « une capacité d'évaluer les actions des autres en relation avec soi et les tierces parties, se rappeler de certaines de ses propres actions et de leurs conséquences, d'évaluer les risques, d'avoir les sentiments et un certain degré de sensibilité » [Broom, 2006]. Nous avons appliqué les exigences sentientes au cas d'un jeu de rôle de visite dans un musée basé sur notre expérience avec les musées et la littérature existante.

Les autres contributions sur cette thématique sont : [Kornyshova et al., 2023a] constitue un livre édité en préparation intitulé « Smart Life and Smart Life Engineering: Current State and Future Vision » ; [Friggiati et al., 2022TR] est un rapport technique réalisé pour l'IRSN ; [Kornyshova, 2022SCb] [ Kornyshova, 2022SCa] [Kornyshova, 2020SC] sont des communications scientifiques ; [Alhodar, 2019] [ [START_REF] Costa | Détection des risques liés à la santé avec les capteurs et IoT[END_REF][START_REF] Haouaji | [END_REF] [Joti, 2023] [Machouche, 2021] sont des mémoires de master encadrés.

J'ai également certaines contributions qui sortent des cadres de ces trois thématiques principales : les activités éditoriales [START_REF] Becker | Proceedings of the 21st IEEE Conference on Business Informatics (CBI 2019)[END_REF], [Kornyshova et al., 2017b], [Kornyshova, 2022], [Kornyshova et al., 2016a], [Kornyshova et al., 2016b], [START_REF] Silberztein | Proceedings of the 23rd International Conference on Applications of Natural Language to Information Systems (NLDB 2018)[END_REF]; quelques publications [Kornyshova et al., 2021c], [Elali et al., 2023a], [START_REF] Silberztein | [END_REF], [Kornyshova et al., 2018], [Khodabandelou Elena Kornyshova 14/ 158 HDR et al., 2013], [Kornyshova, 2005a]; et deux communications scientifiques [Kornyshova, 2016SCb] [Kornyshova, 2018SC].

Direction et organisation de la recherche

J'ai quatre doctorants en cours et j'ai dirigé de nombreux projets de master recherche. Les doctorants sont :

Ramona Elali (40%). Ramona a commencé son doctorat en 2020 sur l'exploration d'intentions pour découvrir des modèles de processus contextuels (le titre de sa thèse est « Fouille d'intentions : Génération des modèles intentionnels de processus pour recommandations »). Son premier objectif est d'identifier les stratégies et les intentions, leur sémantique, leur niveau d'abstraction pour construire les modèles de processus intentionnels en utilisant les informations contextuelles extraites de l'environnement et des capteurs. Un autre objectif est de proposer des techniques de recommandation pour guider les utilisateurs tout en mettant en oeuvre un processus basé sur le modèle de processus intentionnel découvert, sur leurs traces actuelles et leur contexte. Les articles publiés sont : [Elali et al., 2023a] [Elali et al., 2023b] [Elali et al., 2022a] [Elali et al., 2022b] [Elali, 2021] [Elali, 2022].

Kaoutar Sadouki (60%). Le sujet de thèse est « Configuration de composants d'information et de communication basée sur les intentions pour les applications de type Industrie 4.0 ». Le projet de thèse de Kaoutar vise à développer une approche de configuration contextuelle et basée sur les intentions des composants de l'industrie 4.0 (par exemple IoT, CPS, réseaux 5G, etc.). L'approche de Kaoutar vise à améliorer les cadres existants tels que le cadre RAMI4.0 (Reference Architectural Model Industrie 4.0), proposé par le Conseil de normalisation Industrie 4.0 (SCI4.0) en incorporant la dimension intentionnelle pour assurer une meilleure harmonisation avec les objectifs des utilisateurs. Les articles publiés sont : [Kornyshova et al., 2022a] [Sadouki, 2022a] [Sadouki, 2022b].

Mustapha Kamal Benramdane (40%). Le projet de thèse de Mustapha aborde le problème de la configuration d'un ensemble d'entités organisées en écosystèmes digitaux (Digital Business Ecosystems -DBE) en fonction du contexte et les intentions des entités. Le sujet de sa thèse est « Orchestration contextuelle basée sur les intentions au sein des écosystèmes et des plateformes d'affaires numériques ». Les travaux de recherche sur les DBE se sont multipliés ces dernières années en raison de la propagation des plateformes numériques dans de nombreux secteurs. Dans cet environnement, il est obligatoire de prendre en compte les objectifs des utilisateurs et/ou des entreprises à différents niveaux ainsi que les différentes caractéristiques du contexte impactant l'orchestration. L'approche proposée combine des méthodes statiques et basées sur l'apprentissage automatique pour fournir des recommandations aux différents acteurs avec une liste de partenaires, consommateurs et fournisseurs potentiels. Les articles publiés sont : [START_REF] Benramdane | Supervised Machine Learning for Matchmaking in Digital Business Ecosystems and Platforms[END_REF] [ [START_REF] Benramdane | Hybrid Machine Learning for Matchmaking in Digital Business Ecosystems[END_REF]] [Benramdane et al., 2021] [ Kornyshova et al., 2023b] [Benramdane, 2022].

Lydia Ouaili (30%). La recherche de Lydia étudie l'intégration de l'identité auto-souveraine (SSI) dans l'IoT. Son sujet de thèse est « Système de gestion d'identité auto-souveraine pour l'Internet des Objets industriel en utilisant des algorithmes d'apprentissage par renforcement et d'apprentissage fédéré ».

Dans les DBE ou plateformes, les entités (humains, organisations, appareils) partagent des données et l'un des principaux défis concerne les systèmes de gestion de l'identité (IdMSs). Ce travail de doctorat vise à faciliter les interactions entre les organisations et les humains en fournissant l'accès aux services sur le Web d'une manière sécurisée, privée et plus efficace par l'utilisation d'algorithmes d'apprentissage automatique. Les articles publiés sont : [Ouaili et al., 2022a] [Ouaili et al., 2022b], ainsi qu'un mémoire de recherche a été réalisé par Lydia [Ouaili, 2021].

Une sélection de mémoires de master correspondant à mes principaux thèmes de recherche est : Mohamed Amine El [START_REF] Afrit | [END_REF][START_REF] Afrit | [END_REF] ; Shurooq Alhodar, 2019 [Alhodar, 2019] ; Eva Friggiati Chateignon, 2021 [START_REF] Friggiati | [END_REF] ; Kahina Machouche, 2021 [Machouche, 2021] ; Anis Yahiaoui, 2021 [Yahiaoui, 2021] ; Ilyes Benni, 2022 [Benni, 2022]; Lilia Meziani, 2022 [Mezani, 2022] ; Anxhela Joti, 2023 [Joti, 2023] ; Hiba El [START_REF] Haouaji | [END_REF][START_REF] Haouaji | [END_REF] et Léa Da [START_REF] Costa | Détection des risques liés à la santé avec les capteurs et IoT[END_REF][START_REF] Costa | Détection des risques liés à la santé avec les capteurs et IoT[END_REF].

J'ai initié et finalisé plusieurs projets. Les projets les plus importants sont les projets avec l'IRSN, Airbus et le projet sur Smart Life.

IRSN (Institut de Radioprotection et de Sûreté Nucléaire), Service de soutien aux plateformes scientifiques et techniques pour la valorisation et optimisation). J'ai initié ce projet. J'accompagne l'équipe de l'IRSN sur les aspects méthodologiques de construction de la cartographie immersive étendue pour les plateformes scientifiques et technologiques et, à partir de 2021, sur l'encadrement scientifique. Une convention du partenariat entre le CNAM et l'IRSN a été signée en novembre 2021 avec un flux financier de 78k€ vers le CNAM. L'encadrement scientifique inclut un stage de recherche de Master 2 déjà réalisé en 2020-2021 (Eva Friggiati Chateignon) [START_REF] Friggiati | [END_REF] et un ingénieur de recherche à partir du mois d'avril 2023 pour une durée de 12 mois. Le premier livrable sur ce projet a été rendu en novembre 2022 sur l'état de l'art du domaine UX, la synthèse du questionnaire réalisé et les bases pour l'idéation à venir [Friggiati et al., 2022TR].

Airbus, équipe DDMS (Digital Design, Manufacturing & Services). Le travail est mené autour de l'étude des processus de conception des avions et la synchronisation des processus de conception et de fabrication des avions. La principale contribution de la recherche est l'analyse de la variabilité des processus et l'exploration sémantique des processus. Une prestation de recherche a été finalisée pour un montant de 32k€ pour la période 2021-2022. Une collaboration de recherche a été signée en 2022 pour la période 2022-2023 pour un montant de 25k€ supplémentaires. J'ai fait dix présentations dans le cadre de cette collaboration auprès d'Airbus. Cinq livrables ont été rendus dans le cadre de ce projet [Kornyshova, 2022TRa] [Kornyshova, 2022TRb] [ Kornyshova et al., 2022TRa] [ Kornyshova et al., 2022TRb] [Kornyshova, 2021TR]. Je suis prestataire de recherche principal sur ce projet. Un ingénieur de recherche (Yara Amine) a été embauché pour cette prestation pour une durée de six mois en 2022. Elle a contribué aux deux livrables suivants [Kornyshova et al., 2022TRa] [ Kornyshova et al., 2022TRb] et a rédigé un rapport de recherche [Amine, 2022].

Smart Life et Smart Life Engineering. Motivés par le développement durable, humain et sentient des applications intelligentes, nous observons l'émergence d'un nouveau domaine scientifique que nous appelons la vie intelligente (Smart Life). Ce domaine vise à systématiser les connaissances existantes et à formuler des principes communs, des méthodes de conception et de développement, avec les technologies associées pour des applications améliorant la vie des humains. L'objectif est triple : (i) établir le domaine scientifique de Smart Life Engineering ; (ii) développer une communauté scientifique autour de Smart Life Engineering, et (iii) organiser des événements scientifiques et diriger des initiatives de publication. Je suis l'initiatrice et coordinatrice principale de ce projet. Je suis coauteur de sept publications sur ce sujet [Kornyshova et al., 2023c] [ Kornyshova et al., 2022a] [ Kornyshova et al., 2022d] [ Kornyshova et al., 2021a] [Elali et al., 2023b] [Elali et al., 2022a] [Elali et al., 2022b]. Avec mes collègues, nous avons initié un groupe de travail sur Smart Life Engineering au sein de l'IFIP WG8.1, accepté en juin 2022. Rébecca Deneckère et moi-même sommes les présidentes de ce groupe de travail. Nous avons lancé un livre intitulé « Smart Life and Smart Life Engineering : Current State and Future Vision » [Kornyshova et al., 2023a] J'exerce de multiples responsabilités dans l'organisation d'événements scientifiques. Plus précisément, j'ai participé à 15 manifestations avec des responsabilités scientifiques et à 17 manifestations scientifiques avec des responsabilités administratives.

Perspectives de recherche

Mes perspectives de recherche suivent les trois axes définis et permettent de progresser sur la définition et la formalisation du contexte et des intentions, sur l'amélioration de la méthodologie de configuration dans le contexte de la digitalisation et sur la définition et l'ingénierie des applications de la Vie intelligente.

Définition et formalisation du contexte et des intentions. En ce qui concerne cette orientation de recherche, mes principaux objectifs à court terme sont, premièrement, de finaliser l'approche permettant d'améliorer les modèles de processus intentionnels avec des données sur le contexte recueillies à partir de capteurs et autres appareils digitaux. Le principal défi ici est de trouver un moyen d'associer les données contextuelles aux logs d'événements. Deuxièmement, l'idée est de lier les approches d'exploration des intentions au concept d'expérience utilisateur. Je prévois d'explorer la piste d'utilisation des logs des événements afin d'améliorer l'expérience. A long terme, je prévois de développer une approche holistique permettant de préparer les données pour l'exploration des intentions et des processus afin d'améliorer et de personnaliser l'expérience utilisateur.

Amélioration de la méthodologie de configuration dans le contexte de digitalisation. Cet axe de recherche est principalement orienté sur l'intégration des techniques de Machine Learning pour réaliser la configuration. Les appareils digitaux produisent une quantité considérable de données très hétérogènes. A court terme, les techniques de Machine Learning seront intégrées dans les approches de configuration des écosystèmes digitaux et de définition de l'identification sécurisée dans les objets connectés. Parallèlement à l'utilisation des techniques d'apprentissage automatique, la méthodologie de configuration correspondante devrait également être adaptée pour tenir compte des flux de données.

Vie intelligente et l'ingénierie de la vie intelligente. La principale orientation de recherche ici est de développer la notion de vie intelligente. A court terme, je prévois d'approfondir la définition du phénomène « Smart ». A long terme, mon projet de recherche est de contribuer à la mise en place du domaine Smart Life Engineering qui viserait à développer les méthodes génériques, les approches et les outils pour une utilisation optimisée des ressources, en se basant sur les principes de modularité, flexibilité et réutilisation. Plus particulièrement, j'envisage d'appliquer les principes et les approches de la configuration contextuelle basée sur les intentions dans ce domaine. Enfin, je m'intéresse au développement des aspects éthiques du mot « intelligent ». Il y a une grande question éthique liée à la définition de l'intelligence de ces objets tels que les armes intelligentes. Je travaille actuellement avec mes collègues du groupe de travail Smart Life sur un chapitre de définition de Smart.

Conclusion

Dans ce document, j'ai résumé mes contributions à la recherche. Mes publications ont commencé en 2005 et les dernières sont en 2023. Mes principaux sujets de recherche portent sur la configuration contextuelle des méthodes et des processus basée sur les intentions, et récemment, je me suis également concentrée sur l'analyse des applications intelligentes comme un moyen d'améliorer les interactions entre les humains et les TIC.

Introduction

My main research topic deals with the development of methodological aspects and focuses on contextand intention-based configuration to help users make decisions. The purpose of the configuration is to personalise approaches, methods, processes, behaviour, and so on, to adapt them to a given context or a concrete person. I worked on the configuration in the context of method engineering and, during the last seven years, in the context of digitalisation to contribute to the development of Smart Life.

After an introduction to the main concepts, I present in this document the evolution of my research topics with particular attention to the contributions to the contextualisation, configuration, and Smart Life; I detail my experience in research direction and organisation, and, finally, I define the future directions of my research.

In this section, I will introduce the theoretical background of my research (Section 2.1.), present the evolution of my research activities (Section 2.2.), and detail my experience in research direction and organisation (Section 2.3.).

Background

The background of my research presented in this work is organised around two domains: (i) contextand intention-based configuration as a part of situational method engineering (SME) and (ii) digitalisation and the Industry 4.0 revolution.

Context-and Intention-based Configuration

Context-based configuration comes from the field of Method Engineering (ME) and, more particularly, Situational Method Engineering (SME). Method Engineering is the discipline to design, construct, and adapt methods, techniques, and tools for the development of IS [Brinkkemper, 1996].

The origin of the word method is the Greek word "methodos" (pursuit of knowledge), from "meta" (expressing development) and "hodos" (way). Among all the definitions of a method proposed in [Olle et al., 91] [Brinkkemper, 1990] [Lyytinen et al., 1989[START_REF] Kronkof | [END_REF]] [Prakash, 1994] [Prakash, 1999] [Seligmann et al., 1989] [Harmsen et al., 1994], we retain the fact that most of them converge on the following statement:

A method is based on one or several product models (systems of concepts) and consists of one or more process models (steps executed in a given order) [Kornyshova, 2011].

Initially, method engineering aims to bring effective solutions to the construction, improvement, and modification of methods used to develop information and software systems. One of the goals of ME is to improve the use of methods. ME proposes an adaptation framework where the methods are created to match specific organisational situations. This is often done at two levels. At a global level, it determines the contingency factors of the project [Van Slooten et al., 1996], helping to select the correct method to use. At a finer level, it manages the construction process for the current situation [Deneckère, 2001].

Method engineering has seen the development of a new group of methods called situational methods that allow building and adapting a method to a specific context. The situational approach finds its justification in the practical field analysis, which shows that a method is never followed literally [Ralyté, 2001] [Mirbel et al., 2002]. The discipline of Situational Method Engineering (SME) promotes the idea of retrieving, adapting and tailoring components, rather than complete methodologies, to specific situations [Rolland et al., 2001b].

There are several SME approaches: method fragment-based method [Brinkkemper, 1996] [Brinkkemper et al., 2001] [Harmsen et al., 1994] [Harmsen, 1997] [Wistrand et al., 2004], assemblybased approach [Ralyté, 2001] [Rolland et al., 1998] [Ralyté et al., 2003], method configuration approach [START_REF] Karlsson | Method configuration: adapting to situational characteristics while creating reusable assets[END_REF]] [Wistrand et al., 2004] [Agerfalk, 2003] [Karlsson, 2005], Method services developed by two approaches: SO2M [START_REF] Guzélian | SO2M: Towards a Service-Oriented Approach for Method Engineering[END_REF] and MaaS [Rolland, 2009] [Iacovelli et al., 2008], Method Extension approach [Deneckère, 2001], etc.

The notion of method component is central to SME as it encapsulates the knowledge in a given SME approach. There are various representations of modular parts: fragments [Brinkkemper, 1996] [Harmsen et al., 1994], chunks [START_REF] Rolland | Specifying the reuse context of scenario method chunks[END_REF], components [START_REF] Wistrand | Method components: Rationale revealed[END_REF], OPF fragments [Henderson-Sellers, 2002], method services [Rolland, 2009] [Guzélian et al., 2007] [Iacovelli et al., 2008], and method patterns [Deneckère, 2001] [Deneckère et al., 2001]. Our vision of the method component is close to the method chunk concept [START_REF] Rolland | Specifying the reuse context of scenario method chunks[END_REF]] [Ralité et al., 2003]. A chunk is described as a way to capture more of the situational aspects in ME and appropriately support the retrieval process. It concentrates on the intention of the method component and on the situation in which it may be applied (the interface). Contrary to the other representations, a chunk embeds a product and a process part at the same time.

All existing SME approaches consider the situation of a project at hand called context. In addition, a part of them takes into account the intentions that users have in the application of the methods. [START_REF] Bouquet | Theories and uses of context in knowledge representation and reasoning[END_REF] state that the study of the context was started in the 70's. Since then, many different domains in relation to information systems have used the notion of context and given various interpretations of it. Context models are multidisciplinary and have been proposed in several areas [START_REF] Bradley | Toward a multidisciplinary model of context to support context-aware computing[END_REF]. For instance, [START_REF] Dey | A conceptual framework and toolkit for supporting the rapid prototyping of context-aware applications[END_REF] define the notion of context as the information that could be used for characterizing the situation of an entity (person, object or computer), and, more generally, by any element that can influence the IS behaviour. [START_REF] Rey | Le Contexteur : une abstraction logicielle pour la réalisation de systèmes interactifs sensibles au contexte[END_REF] foresees the context from four points of view: as defined in terms of an object, as the captured data serving a purpose, as an information space shared by multiple actors (users and systems), and as infinite and varying through time.

Context Definition

20/158 HDR

Related to the Information technologies field, the context is represented as a model or ontology. For instance, [START_REF] Gu | An Ontology-based Context Model in Intelligent Environments[END_REF] suggest a more detailed context vision. It describes a formal context model based on ontology for intelligent environments. This context ontology defines a vocabulary for representing knowledge about the context in this field. It includes two levels: upper ontology (capturing general context knowledge) and domain-specific ontologies (detailing basic concepts in application to a given domain). [START_REF] Gu | An Ontology-based Context Model in Intelligent Environments[END_REF]] also specifies a way for modelling context classification, dependency between context elements, and quality of context.

Another term closely related to context one is context-awareness. The context-awareness term originates from pervasive or ubiquitous computing [START_REF] Schilit | Context-aware computing applications[END_REF]. These systems link changes in the environment with computer systems, which are otherwise static. Although it is a computer science term, it has also been applied to business theory in relation to business process management issues [START_REF] Rosemann | Context-aware process design: exploring the extrinsic drivers for process flexibility[END_REF]] [Bessai et al., 2008], to computer science [START_REF] Bradley | Toward a multidisciplinary model of context to support context-aware computing[END_REF], and to service selection [Kirsch Pinheiro et al., 2008]. In these works, the context is mainly used to solve the lack of flexibility and adaptability within processes.

Intention Definition

The intention is central to several SME approaches based on the MAP formalism [Rolland et al., 2001]. An Intention is a goal that can be achieved by the performance of an activity. [Prat, 1997] suggests a model to describe the intention in detail. This model has already been applied to the method engineering field to represent the method chunks' intention [Ralyté, 2001]. Following this model, the intention is expressed in natural language and is composed of a verb and at least one parameter. Each parameter has a particular role with regard to the verb. The intention model is given in Figure 2.1.

(from [Ralyté, 2001]). An example is the Identify Decision-making Requirements intention. A detailed description of the intention elements can be found in [Rolland, 2011] [Ralyté, 2001].

Intentional Model MAP

In the SME field, the intention-based configuration approach is associated with the MAP formalism [Rolland et al., 2001]. The Map model enables to represent the non-deterministic flexible ordering of intentions. It is expressed through the combination of different intentions and strategies for achieving them.

Intention

Elena Kornyshova

21/158 HDR

A map allows organising method components. A Map is graphically presented as a directed diagram, where intentions are nodes and strategies are edges, and each section corresponds to two nodes related to each other by an edge (See Figure 2.2.). The key concept of a Map is the notion of the section, which is an aggregation of two specific intentions, the source intention and the target intention, linked together with a strategy. It embeds the knowledge corresponding to a particular method component to achieve an intention (the target intention) from a specific situation (the source intention) following a particular technique (the strategy). The directed nature of this diagram shows the precedence links between intentions. An edge enters a node if its associated strategy can be used to achieve the target intention (the given node).

Digitalisation and Industry 4.0 Revolution

According to [START_REF] Bockshecker | Systematization: digital transformation and phenomena[END_REF], the term of digitalisation or digital transformation is defined as a process of transforming resources into digital. The digitalisation process implies converting main organisational resources from manual or physical to digital (virtual or abstract); consequently, it prompts enforced modifications on the organisational structure, business, and manufacturing processes. This means that any change in the way of working, any inclusion of new objects and resources or the updates of them, any enhancement of the collaboration between machines (virtual or physical) and humans, modifying their roles and responsibilities, is a transformation that distresses the internal and external environment of the enterprise.

As a part of the digitalisation phenomenon, Smart applications appeared. These are applications and devices aimed at improving life (like Smart home, Smart windows, Smart city, etc.). Smart applications have a common characteristic, which is the autonomous adaptation of the behaviour of the object according to the data received from the environment, which constitutes in itself the configuration according to the context. Industry 4.0 (or I4.0) is one of the recent digitalisation trends in the production world. The I4.0 initiative aims to transform the way industries and business organisations generate value, products and services by combining many new technologies, especially artificial intelligence features. The main concept of Industry 4.0 is the emergence of Smart factories, which are connected to the cyber-physical systems of production sites called CPS (Cyber-Physical Systems) [Steiner et al., 2019]. It includes automation and data exchange between its nine founding technologies -autonomous robots, Internet objects (IoT), big data, simulation, horizontal and vertical integration of systems, cloud computing, cybersecurity, additive manufacturing, and augmented reality [START_REF] Benešová | Determination of changes in process management within industry 4.0[END_REF].

The peculiarity of I4.0 is that, instead of traditional hierarchical and centralised structures, it presents patterns in which autonomous agents interact in decentralised architectures. These agents are connected to each other and decision centres. The most relevant technologies in I4.0 are Cloud Computing, IoT and Big Data [START_REF] Rossit | Industry 4.0: smart scheduling[END_REF]. However, the post-I4.0 phase arrives and evolves.

Industry 5.0 differs from Industry 4.0 but is not associated with a new industrial revolution. Instead, it is a complement to its previous phase. It takes the next step, highlighting the interaction between powerful and precise machines and the unique creative potential of the human being. The fundamental principle of Industry 4.0 is to make manufacturing "Smart" by interconnecting machines and equipment that can control each other, i.e., cyber-physical systems (CPS), for mass production [START_REF] Xu | [END_REF]. Industry 5.0 focuses primarily on mass customisation and personalisation, where humans guide robots [START_REF] Maddikunta | Industry 5.0: A survey on enabling technologies and potential application[END_REF], and on improving customer satisfaction. Customers can thus prefer personalised products adapted to their tastes and needs.

Often, digitalisation consists of setting up a digital platform that will be the intermediary between customers and the company [START_REF] Afrit | [END_REF]. A digital business ecosystem is then initiated. This ecosystem puts the customer at the centre. Indeed, it allows managing the relationship with the customer to collect data to understand better his needs and behaviours to offer him exactly the offer that corresponds to him. As this customer demands everything he wants immediately, the computerisation of processes makes it possible to streamline the production of goods and services to respond quickly to needs.

The customer is, therefore, looking for something other than the product in itself but especially for a service behind the product. The innovation of the business model to adapt to the digital age could, therefore, go through a process of improving the "service" and "user experience" [START_REF] Afrit | [END_REF]. The study by [Westerman et al., 2014] showed that digital masters put the transformation of the customer experience at the heart of their digital transformation. This customer experience is designed from the outside to the inside (outside-in). That is to say, we listen and analyse first what customers want, then we do our business model and organise internally to create value for these customers. For this, digital masters use several digital channels to expand the market and consider data analytics tools as the backbone of the digital war to continuously innovate their customers' experience. Thus, the user experience becomes a central concept of digitalisation.

23/158 HDR

Evolution of Research Activities

In this section, I present the overview of my research activities (Section 2.2.1.) and a summary of my main research topics (Section 2.2.2.).

Overview of My Research Activities

I started my research work with my PhD in Economics and Management in the field of business process management, defended in 2007 [Kornyshova, 2007c]. The thesis research aimed to develop theoretical and methodical foundations of system analysis and management of business processes in companies.

To achieve this goal, I have analysed the role of business process management, established a detailed taxonomy of business processes, and introduced the concepts of business process network and business process lifecycle. Based on the application of the system approach, I developed a flexible model of the business process network, including the internal and external environment and the associated approach to improve business process management in organisations. The proposed approach was validated by applying it to a company producing electronic components. I published the contributions in the following papers [Kornyshova, 2007b] [Kornyshova et al., 2007d] [Kornyshova, 2006a] [Kornyshova, 2006b] [Kornyshova, 2006c] [Kornyshova, 2006d] [Kornyshova, 2005a] [Kornyshova, 2005b] [Kornyshova, 2005c].

The next important step was to work on methodological aspects related to the configuration of methods in the field of Information Systems Engineering. During my PhD in Informatics [Kornyshova, 2011], I developed the MADISE approach defended in 2011. The MADISE approach includes four following elements: the DM ontology, the DM method family, the MADISE configuration process, and the MADISE methodological repository. The results were validated in various fields: Information Systems Engineering, decision-making methods, agile methods, processes, and others. I published 23 related to this topic papers [Kornyshova et al., 2011a] [Kornyshova et al., 2011b] [Kornyshova et al., 2011c] [Kornyshova et al., 2010a] [Kornyshova et al., 2010b] [Kornyshova et al., 2009] [Kornyshova et al., 2008a] [Kornyshova et al., 2008b] [Kornyshova et al., 2008c] [Kornyshova et al., 2008d] [Kornyshova et al., 2008e] [Kornyshova, 2007a] [Kornyshova et al., 2007a] [Kornyshova et al., 2007b] [Kornyshova et al., 2007c] [Deneckère et al., 2011a] [Deneckère et al., 2011b] [Deneckère et al., 2011c] [Deneckère et al., 2010a] [Deneckère et al., 2010b] [Deneckère et al., 2009] [Deneckère et al., 2008] [Salinesi et al., 2006] [Bucher et al., 2008].

Since my thesis, I continue to work on contextual and intention-based configuration. I have been interested in the new context characterised by developing digital technologies and Smart applications.

Currently, this development implies several evolutions: the nature of data is changing, tools and methods have become numerous, and users want to have results very quickly, even in real-time. Needs for personalised configuration are growing. From the other side, the SME principles (modularity, reuse, flexibility, context-awareness) should be updated to consider this new context. For instance, decisionmaking would be mainly based on machine learning techniques. During the last seven years, my research has focused on the question "How contextual and intention-based configuration can help users make their decisions in the era of digitalisation?"

In the field of contextual and intentions-based configuration, my research contributions could be separated into two main topics: contextualisation (definition and formalisation of the context) and configuration (development of DM models and approaches to guide users in configuring their methods and processes). In addition, I have been interested in improving interactions between users and information and communication technologies (ICT) for several years. I foresee this topic as a field of 3 5 7 7 2 4 7 2 2 1 1 7 3 3 2 3

Activity 2 1 1 1 1 1 International Journal 2 1 1 1 1 National Journal 2 1 1 1 2 1 Book Chapter 1 1 International Conference 1 3 1 2 2 2 1 1 1 1 4 6 1 26 National Conference 3 4 1 2 1 1 2 2 16 International Workshop 2 1 1 1 National Workshop 1 Technical Report 6 Scientific Communication 2 1 1 2 Poster 1 1 1 Working Paper 1 PhD Students' Doctoral Consortium 1 4

Total by year

Focus on Main Research Topics

My research contributions in context and intention-based configuration could be summed up in two main categories: contextualisation and configuration. In addition, I work on an emerging topic, "Smart Life", as a way to improve the interactions of Humans with ICT. The overview of the main research contributions and their links is given in Figure 2.5.

Figure 2.6. gives indications on how the main contributions are organised in Chapters of this document.

Contextualisation

My first research direction deals with the enhancement of contextualisation methodologies. The notion of context comprises all internal and external environment characteristics impacting methods, processes, and interactions, including users' intentions. In my research, both concepts (of context and intention) are tightly related.

I work with my colleagues on extracting and formalising data about the context and users' intentions.

My research work could be unified into three categories:

1. Context Modelling 2. Context Discovery 3. Intention Discovery Firstly, I work on context modelling. We analysed the teleological nature of engineering processes [Deneckère et al., 2010a] [Deneckère et al., 2011a] to construct a context model related to the notion of decision. Based on the analysis of the existing definitions of context in SME, we developed a generic context model, including a context meta-model, a detailed typology of context characteristics, and a proposal for the enrichment of the intentional model MAP by context [Kornyshova et al., 2011b] [Kornyshova et al., 2010b] [Deneckère et al., 2014]. Recently, I was interested in modelling user experience [Kornyshova et al., 2022b] as a way to structure data about the context of the use, users' and personas' (user type) profiles. With regard to the context discovery, I contributed to the context definition approach. In [Kornyshova et al., 2011b] [Kornyshova et al., 2010b], we defined a process to define the context. I contribute to works on extracting the context elements from sensor logs and combining sensor and event logs to construct contextual process models using domain ontologies [Elali et al., 2022b]. We tested the possibility of joining the sensor-and event-related data to enrich the context identification. Based on that, we proposed a process model enriched by data from the sensor logs [Elali et al., 2023b] [Elali et al., 2022a].

Finally, I work on intention discovery to identify users' intentions. We work on detailed state-of-theart on intention mining approaches. In [START_REF] Deneckère | A Framework for Comparative Analysis of Intention Mining Approaches[END_REF][START_REF] Deneckère | [END_REF], we developed a classification framework for intention mining approaches. We validated this framework with the five most relevant research works in this field. I contribute to elaborating the ontology-based Intention Mining approach for contextual recommendations [Elali, 2021] [Elali, 2022].

Other references on this topic are [Kornyshova et al., 2021b] [Fathy et al., 2016] [Kornyshova et al., 2017c] (research papers) and [START_REF] Afrit | [END_REF][START_REF] Friggiati | [END_REF] (students' reports).

Configuration

Within the configuration axis, I work on three sub-topics:

1. Context-and Intention-based Configuration of Methods, 2. Configuration of Digital Components, 3. Organisational Entities Configuration using Machine Learning.

For the purpose of context-and intention-based configuration of methods, we developed a new SME approach based on the variability theory, called method family and taking into account the context and users' intentions to provide a personalised method line [Kornyshova et al., 2011a] [Kornyshova et al., 2011c] [Kornyshova et al., 2012b] [Kornyshova et al., 2013] [Kornyshova et al., 2017a] [Deneckère et al., 2011c] [Deneckère et al., 2015] [Deneckère et al., 2016a]. This approach is supported by the decision-making ontology [Kornyshova et al., 2010a] [Kornyshova et al., 2012a], allowing to adapt decision method to each case. To facilitate the application of method families in practice, we proposed a configuration approach using multicriteria decision-making methods and the graph theory [Kornyshova, 2011] [Kornyshova et al., 2008b] [Kornyshova, 2007a] [Kornyshova et al., 2007c] [Kornyshova et al., 2008e] [Deneckère et al., 2009] [Deneckère et al., 2010b].

During the last seven years, I worked on the application of situational method engineering fundamentals to new emerging contexts related to digitalisation. These topics are organised into two groups: the configuration of digital components and the configuration of organisational entities using machine learning.

For the configuration of digital components, I'm interested in the configuration of I4.0 components based on users' intentions in the industry. We are working on the state-of-the-art on intentionoriented approaches in this context and on elaborating the configuration approach [Sadouki, 2022a] [Sadouki, 2022b]. The next step will be the formalisation of intentions. At the organisational level, I study how Industry 4.0 components could be integrated into an existing enterprise architecture (EA).

We developed an approach of I4.0 impact propagation on EA models [Kornyshova et al., 2021b] [ Kornyshova et al., 2020] [Kornyshova et al., 2019]. We established a propagation model and the associated process to help enterprise architects. To complete this study, we established a situational approach applied to the Enterprise Architecture framework TOGAF [Kornyshova et al., 2022c].

With regard to the configuration of entities using Machine Learning, I contribute to the configuration of digital business ecosystems (DBE). The quick evolution of DBE accentuates the difficulties of finding the best partners, products, data, and services. Machine Learning techniques should be used to help in this search, which we call configuration. We foresee this configuration as depending on the context and users' intentions. In our research, we prepared a literature review on matchmaking [START_REF] Benramdane | Supervised Machine Learning for Matchmaking in Digital Business Ecosystems and Platforms[END_REF] between entities inside DBEs. We proposed an approach to provide recommendations [START_REF] Benramdane | Hybrid Machine Learning for Matchmaking in Digital Business Ecosystems[END_REF]] [Benramdane et al., 2021] [Kornyshova et al., 2023b] [Benramdane, 2022].

The collaboration of entities requires their authentication. In DBEs, where IoT devices are often included, each entity should be sure that data obtained from IoT and exchanged with other entities are trustworthy. We are exploring identity protection using a self-sovereign identity in IoT based on blockchain consensus algorithms and distributed identifiers to build a trust relationship between entities and IoT devices [Ouaili et al., 2022a] [Ouaili et al., 2022b]. The current work includes a literature review on the topic.

Other recent references on this topic are technical reports [Kornyshova, 2022TRa] [Kornyshova, 2022TRb] [Kornyshova et al., 2022TRa] [Kornyshova et al., 2022TRb] [Kornyshova, 2021TR]; a scientific communication [Kornyshova, 2016SCa]; a research engineer report [Amine, 2022]; and students' works [Benni, 2022] [Mezani, 2022] [Ouaili, 2021] [Yahiaoui, 2021].

Smart Life

In addition to the two first directions, I am interested in improving interactions between users and ICT.

During the literature review, we discovered that the most widespread expressions representing the applications, tools, and devices oriented on the better interaction of humans with ICT follow the word "Smart" as Smart city, Smart home, Smart health, and so on. We studied the existing literature to understand this term better and established that a shared definition of "Smart" does not exist. Thus, we defined the term of "Smart" with three degrees of smartness and specified the notions of Smart artefact, Smart application, and Smart Life using the systemic approach [Kornyshova et al., 2022d] [Kornyshova et al., 2023c]. We established a detailed taxonomy of Smart applications and analysed their evolutions [Kornyshova et al., 2022a]. We established a research agenda for this field [Kornyshova et al., 2022d].

To ensure the well-being of ICT users, we defined a new kind of requirement we called "sentient" [Kornyshova et al., 2021a]. Based on the literature review, we established the list of sentient requirements. We illustrated the application of these requirements with a visiting game in a museum.

To show the role of sentient requirements, we suggested a pyramid to represent the hierarchy of requirements.

Other contributions to this topic are an edited book, "Smart Life and Smart Life Engineering: Current State and Future Vision" under the preparation [Kornyshova et al., 2023a], a technical report for IRSN [Friggiati et al., 2022TR], scientific communications [Kornyshova, 2022SCb] [Kornyshova, 2022SCa] [Kornyshova, 2020SC], and direction of students' works [Alhodar, 2019[START_REF] Costa | Détection des risques liés à la santé avec les capteurs et IoT[END_REF][START_REF] Haouaji | [END_REF]] [Joti, 2023] [Machouche, 2021].

The evolution of the publications depending on the main topic is given in Figure 2.7. Other contributions include mainly editorial activities [START_REF] Becker | Proceedings of the 21st IEEE Conference on Business Informatics (CBI 2019)[END_REF], [Kornyshova et al., 2017b], [Kornyshova, 2022], [Kornyshova et al., 2016a], [Kornyshova et al., 2016b], [START_REF] Silberztein | Proceedings of the 23rd International Conference on Applications of Natural Language to Information Systems (NLDB 2018)[END_REF]; several publications [Kornyshova et al., 2021c], [Elali et al., 2023a], [START_REF] Silberztein | [END_REF], [Kornyshova et al., 2018], [Khodabandelou et al., 2013], [Kornyshova, 2005a]; and two scientific communications [Kornyshova, 2016SCb] [Kornyshova, 2018SC].

Research Direction and Organisation

In this section, I detail the co-direction of my PhD students, the direction of other students, the research project direction, and the different activities of the research organisation.

PhD Students' Co-Direction

I have four PhD students that I co-direct with other researchers:

Ramona Elali (40%). Ramona started her PhD in 2020 on intention mining to discover contextual process models. The thesis topic is "Intention Mining: Intentional Process Model Generation for Recommendation". Her first goal is to identify strategies and intentions, their semantics, level of abstraction to construct the intentional process models using the contextual information captured from the environment (mainly from sensors). Another objective is to propose recommendation techniques to guide users of systems while enacting a process based on the discovered intentional process model, on their current traces, and context. Since the intentional models are close to human ways of reasoning, this kind of intentional process model can provide effective recommendations to users, specifically if these models were built using the contextual environment. Ramona has published the following papers [Elali et al., 2023a] [Elali et al., 2023b] [Elali et al., 2022a] [Elali et al., 2022b] [Elali, 2021] [Elali, 2022].

Kaoutar Sadouki (60%). The PhD project of Kaoutar is entitled "Intention-based Configuration of Information and Communication Components for Industry 4.0 Applications". This doctoral research combines the configuration of Information and Communication Technologies (ICT) (e.g., Smart IoT devices, Cyber-Physical Systems (or CPS), network slices) with a business delivery orientation. The notion of intention is very crucial regarding business requirements, as it allows all devices and the network under consideration to be connected to business intentions and other requirements. The approach of Kaoutar aims at improving the existing frameworks, such as the RAMI4.0 (Reference Architectural Model Industrie 4.0) framework, by incorporating the intentional dimension to better align with business goals. The published papers are [Kornyshova et al., 2022a] [Sadouki, 2022a] [Sadouki, 2022b].

Mustapha Kamal Benramdane (40%). The PHD project of Mustapha addresses the configuration problem for a set of entities organised into Digital Business Ecosystems (DBE) (his topic is "Intentionbased Contextual Orchestration inside Digital Business Ecosystems and Platforms"). Research works on DBE have increased during the last several years due to the propagation of digital platforms in numerous sectors. [START_REF] Senyo | Digital business ecosystem: Literature review and a framework for future research[END_REF] define DBE as a "socio-technical environment of individuals, organisations and digital technologies with collaborative and competitive relationships to co-create value through shared digital platforms". In this environment, it is mandatory to consider the goals of users and companies at different levels and also other context characteristics impacting the orchestration. The literature in the DBE field lacks details on identifying and recommending the best partners. In this research, we develop an approach to match different organisations inside digital business ecosystems and platforms corresponding to one or multiple market segments. The proposed approach combines static and machine learning-based methods to provide recommendations to various actors with a list of potential partners, consumers, and suppliers. The results of his research are presented in [START_REF] Benramdane | Supervised Machine Learning for Matchmaking in Digital Business Ecosystems and Platforms[END_REF]] [Benramdane et al., 2022] [Benramdane et al., 2021] [Kornyshova et al., 2023b] [Benramdane, 2022].

Lydia Ouaili (30%). The topic of Lydia's PhD thesis is "Self-Sovereign Identity Management System for Industrial IoT by using Federated and Variants of Reinforcement Learning Algorithms". She investigates the integration of Self-Sovereign Identity (SSI) in IoT. In DBE or platforms, entities (humans, organisations, devices) share data, and one of the main challenges of technological innovation is identity management systems. Today, one of the most common forms of identity management systems is based on federated solutions, which allow entities to share data about a single user and will enable that user to have a single login credential to access multiple services. This somewhat solves the problem of efficiency in accessing services but allows numerous organisations to hold the user's data out of their control due to the centralised architecture. This last point is one of the many issues that Self-Sovereign Identity (SSI) addresses. The current solutions do not consider the IoT environment. Indeed, the use of IoT devices has increased rapidly, entities collaborate to develop intelligent applications, and the use of log-in/password is inadequate. This PhD work aims to facilitate exchanges between organisations and humans to provide or access services on the Web in a secure, private, and more efficient way by using machine learning algorithms. The published works are [Ouaili et al., 2022a] [Ouaili et al., 2022b] [Ouaili, 2021].

Other Research Supervision

In addition to the co-direction of PhD students, I supervised several master students for their research reports and one research engineer. The evolution of this supervision is shown in Figure 2.8. I supervised a research engineer, Yara Amine. She analyser the existing literature on semantic process management and mining [Amine, 2022] and contributed to two technical reports for Airbus [Kornyshova et al., 2022TRa] [Kornyshova et al., 2022TRb].

A selection of master students' research reports matches my main research topics: [START_REF] Friggiati | [END_REF] and a research engineer from April 2023 for 12 months. The first deliverable on this project was produced in November 2022 on the state of the art of the UX domain, the synthesis of the completed questionnaire and the basis for the upcoming ideation [Friggiati et al., 2022TR].

Airbus, DDMS team (Digital Design, Manufacturing & Services).

The work involves studying aircraft design processes and the synchronisation of aircraft design and manufacturing processes. The main research contribution is the analysis of process variability and semantic process mining. A research service has been finalised for €32k for 2021-2022. A research collaboration was signed in 2022 for 2022-2023 for an additional €25k. I made ten presentations as part of this collaboration with Airbus.

Five deliverables have been produced for this project [Kornyshova, 2022TRa] [Kornyshova, 2022TRb] [Kornyshova et al., 2022TRa] [Kornyshova et al., 2022TRb] [Kornyshova, 2021TR]. I am a lead research provider on this project. A research engineer (Yara Amine) was hired for six months in 2022. She contributed to the following two deliverables [Kornyshova et al., 2022TRa] [Kornyshova et al., 2022TRb] and produced a research report [Amine, 2022].

Smart

Research Organisation

I have multiple scientific and administrative responsibilities in organizing research events. Tables 2.3. and 2.4. detail scientific and administrative responsibilities correspondingly.

Contextualisation

The notions of context and intention are studied as factors for a further configuration. I my research, I participate in works on context modelling (Section 3.1.), context discovery (Section 3.2.), and intention discovery (Section 3.3.).

Context Modelling

Our goal is to formalize the context and to suggest a conceptual model to organize the main elements related to the context of method components (Section 3.1.1.). In addition, I present a conceptual model of User eXperience to formalize the context related to user profiles useful for the UX adaptation (Section 3.1.2.).

Generic Context Model

We analysed the goal-oriented (teleological) nature of engineering processes [Deneckère et al., 2010a] [Deneckère et al., 2011a]. Then, based on the review of the context in SME, we developed a generic context model including a context meta-model, a detailed typology of context characteristics, and enrichment of the intentional model MAP with context [Kornyshova et al., 2011b] [Kornyshova et al., 2010b].

Context-Awareness of Teleological Processes

Existing SME approaches consider the notion of context in order to guide the selection of method components from a repository according to a given situation. They also deal with different kinds of context factors characterizing situations of IS development projects and offer various methodologies for using context. The comparison of context approaches highlights that they address several aspects of context and there is no approach that considers all possible characteristics. There is confusion between the context of a project and the context of method components. Moreover, the existing works do not help in the context characteristics specification.

To deal with these drawbacks, we analysed the nature of engineering processes in general. They include situational method engineering processes. Process engineering is considered a key issue [Rolland, 1998] by the software and information systems engineering communities, including method engineering. For instance, [Dowson, 1993] [Armenise et al., 1993] [Jarke et al., 1994] show that an improved development process will lead to improved productivity in the software systems industry and improved systems quality. Traditional development processes have been conceived as a series of phases, each phase dominated by a particular activity organised into different sequences (e.g., "analysis," "design," "coding," "testing" [Royce, 1970] [Boehm, 1988]. Later, the specific activity sequences were replaced by values and practices [Beck, 2005] [Abrahamsson et al., 2002]. [Ralph et al., 2008] highlight the fact that, in practice, the software developer is faced with a myriad of methodical choices as he can choose to execute one activity completely or partially, combine aspects of two or more different activities, or ignore another one. The decisions made through the process execution leads the engineer to enact a process which is unique and suited to the situation at hand.

According to Dowson [Dowson, 1988], process models can be classified into three groups of models called activity-oriented, product-oriented, and decision-oriented. [Rolland, 1998] refines this classification with a fourth group called context-oriented. Decision and context-oriented processes try to take decision-making (DM) into account as they integrate goals and arguments. Decision-oriented models can explain how the process is carried out and why it is performed [Rolland, 1998] [Ralph et al., 2008]. Context-oriented process models strongly couple the context of a decision to the decision itself [START_REF] Grosz | Modelling and Engineering the Requirements Engineering Process: An Overview of the Nature Approach[END_REF]] [Rolland et al., 2000]. It makes the notion of a context (the coupling of a situation and the decision) central to process modelling. These two kinds of processes may be defined as teleological processes.

A teleological process is a process that takes into account the teleological behaviour of a process execution. It describes the intentions (goals, objectives) associated with the result that the designer wants to achieve. [Taylor, 1964] proposes a behaviour classification as either goal-oriented (teleological) or stimulus-response behaviour. [Malcolm, 1967] defines teleological behaviour as whenever the state of a system and its environment is such that a specific behaviour is required for some event goal, then this behaviour occurs. As a matter of fact, it is necessary to consider the possibility for the rules to change during the development process. [Cayla, 2008] emphasizes the link between this possibility to change and Veblen's teleological principles [START_REF] Veblen ; Veblen | Why is Economics not an Evolutionary Science?[END_REF], which integrate the agent's intentions in processes. This work defines a teleological process as a "dynamic equilibrium whose rules are determined endogenously, as a relation between the system's behaviour and its intentions". Such a teleological process may express changes within a process trajectory. For instance, after the engineer has decided on a general route for his move, he will take the opportunity to revise his path during his progress, considering the information and knowledge he has gathered from his real environment.

[ [START_REF] Vandeven | [END_REF] define the teleological processes as describing the behaviour of agents making actions to reach a purpose or a goal (an envisioned end-state). [START_REF] Ralph | A Teleological Process Theory of Software Development[END_REF] highlight that this is consistent with software development as the teleological agents are the software development team and the project manager; the end-state represents the software product; the development team performs actions (coding, testing…) that correspond to the teleological steps, and the project manager monitors performance. The notion of purpose is also essential for any organisation because it meets several objectives. Similarly, the information system is created because there are several organisation goals to be met, and the system's functions and properties are defined by the organisation's goals that the system intends to fulfil [START_REF] Loucopoulos | Enterprise Modelling and the Teleological Approach to Requirements Engineering[END_REF].

From a teleological viewpoint, any engineering process contains steps of two kinds: decision-making and decision-performing steps. These processes, as teleological, contain variation points in which the engineer should decide between at least two alternatives. The engineer faces the problem of decisions to make. However, most known processes lack methods to consider the decision-making inherent to any information system development process. The decision should be made depending on several factors. In our proposal, we select the context characteristics as factors helping to make this choice.

Therefore, engineering processes are context-aware by their nature in addition to being goal-(or intention-) oriented (Figure 3.1.). From this analysis of the teleological nature of engineering processes, we deduced the importance of considering the context and users' intentions in engineering. Our first goal was to integrate it into SME processes. This implies two main interrelated conclusions: to deal with engineering processes, we should apply decision-making methods and we should consider the variability of processes.

Therefore, to deal with context-aware processes DM steps alternate with decision-performing steps.

On the one hand, the teleological reality of processes' existence requires decisions. On the other hand, engineering-related decisions result from the need to satisfy practical constraints such as quality, cost, or performance [Ruhe, 2003] and other context characteristics. Although these aspects are important, the arguments for final decisions are poor. Choices are made in an intuitive and hazardous way [Ruhe, 2003[START_REF] Ngothe | [END_REF]. One could claim that this situation is due to the lack of DM methods or to the fact that the methods defined in the operational research area are not adequate for the kinds of problems faced by process engineering. However, state-of-the-art [Roy, 2005] [Kornyshova et al., 2007] shows numerous DM methods, from very complex to very simple ones. These methods can be used in many different DM situations (for instance, in method engineering) [Boonstra, 2008]. The issue of DM was already explored with respect to requirements engineering [START_REF] Rolland | A Decision Making Pattern for Guiding the Enterprise Knowledge Development Process[END_REF][START_REF] Ngothe | [END_REF], method engineering [Aydin, 2006], and systems engineering [Ruhe, 2003]. Several examples of multicriteria (MC) methods application can also be mentioned: AHP for prioritising requirements [START_REF] Ruhe | Trade-off Analysis for Requirements Selection[END_REF]] [Karlsson et al., 1997]; Saeki uses the weighting method to deal with software metrics [Saeki, 2003].

Variability has proved to be a central concept in different engineering domains, manufacturing, software development, etc., to develop solutions that can be easily adapted to different organisational settings and different sets of customers at a low price. Teleological processes have, by nature, a high level of variability. We believe that integrating "context-awareness" in that process increases their intrinsic variability with specific criteria.

Our proposal uses the context expressiveness to describe the situation in which a component may be applied. It is then based on the semantic type of context. Moreover, our view includes an intentionoriented approach which allows representing the cognitive aspect of the context. The context characteristics are used to make decisions to deal with the intrinsic variability of teleological processes.

Context in Situational Method Engineering

Based on the study of different SME approaches dealing with method components, we have identified five main approaches dealing with context in the method engineering field: reuse frame [START_REF] Mirbel | Mirbel I.: Contributions à la modélisation, la réutilisation et la flexibilité des systèmes d'information[END_REF]; interface [Ralyté et al., 2001]; method service context [START_REF] Guzélian | SO2M: Towards a Service-Oriented Approach for Method Engineering[END_REF]; contingency factors [Van Slooten et al., 1996] [Harmsen, 1997]; development situation [START_REF] Karlsson | Method configuration: adapting to situational characteristics while creating reusable assets[END_REF].

The reuse frame [START_REF] Mirbel | Mirbel I.: Contributions à la modélisation, la réutilisation et la flexibilité des systèmes d'information[END_REF] is a framework representing different factors which affect IS development projects. These factors are called criteria. Reuse frame allows specifying a context of method fragments reuse, searching method fragments and comparing between them in order to find an alternative fragment to a used one. The reuse frame model includes a reuse situation (which is a set of criteria classified into three dimensions: organisational, technique and human) and reuse intention. In [Ralyté et al., 2001], the method fragment context is defined by its interface which includes a situation and an intention. The situation represents the conditions in which the method fragment can be applied in terms of required inputs product(s). The intention is a goal that the method fragment helps to achieve. Therefore, the interface model includes two elements: the situation and the intention. These two first approaches have been unified in [START_REF] Mirbel | Mirbel I. and Ralyté J.: Situational method engineering: combining assembly-based and roadmap-driven approaches[END_REF]. The method service context [START_REF] Guzélian | SO2M: Towards a Service-Oriented Approach for Method Engineering[END_REF] aims at describing the situation in project development for which the method service is suitable and defining the purpose of the service. Its model includes domain characteristics (project nature, project domain) and human (actor), process and product ontologies. Situations (the context) are described by a set of characteristics called contingency factors [Van Slooten et al., 1996] or project factors [Harmsen, 1997] [Harmsen et al., 1994]. These factors are used to define the project situation by assigning values to them. In [Van Slooten et al., 1996], four categories are given: domain characteristics (describing the content of the system), external factors (laws and norms), technical factors (related to the development platform) and human factors (representing the development expertise of people). [START_REF] Karlsson | Method configuration: adapting to situational characteristics while creating reusable assets[END_REF] defines the development situation as an abstraction of one or more existing/future software development projects with common characteristics. This situation is used to characterize the specific projects and to select configuration packages (method fragments). The development situation model includes a set of characteristics.

These approaches foresee different context elements that are the characteristics of method components. The comparison of these five approaches enables to identify height characteristics groups (context elements) which allow us to compare existing context approaches (See Table 3.1.).

Frame X X X X Interface X X Method service context X X X X Contingency factors X X X X Development situation Not specified
The reviewed SME literature shows several drawbacks in reference to the context definition:

• The context notion is not clarified concerning its relationships to methods and method components. • There is confusion between two aspects of the method context definition: the definition of the context in which a method can be applied, and the definition of the context related to a given project. • Typologies of possible context characteristics are not homogeneous.

• The existing SME literature does not provide means for specifying context characteristics for a given method.

Our approach aims at improving the context definition within the SME field by dealing with these drawbacks.

Our SME approach is called method family (detailed in section 4.1.1.). Once a method family is defined, it is necessary to provide guidelines for using the given family in a specific situation. That implies the context must be defined for the method family and its method components. At the same time, the context is used for specifying the situation of a concrete usage of the method family in order to identify an application method adapted to this situation. Firstly, we propose to consider the context granularity at several levels: the method family and the method component ones (See Figure 3.2.). Each method family is available in a given context. As a method is composed of some components, each of them can be also described by specifying its context. Therefore, the method context is an aggregation of contexts associated to its components.

Figure 3.2. Context Granularity.

In addition, we analyse the relationships between methods and the situation in which methods will be used. Figure 3.3. shows the correspondence between method components context and project context. For both method component and project situation, the context must be specified. The two contexts are specified on the same basis as they inherit from the context (the {complete, overlapping} inheritance relationship). This allows a better matching between the situation and components for the configuration (the matches relationship).

The method component context characterizes all possible situations in which this component may be applied. We associate the description of the context to each method component. The information about the component context is further used for configuring application methods (method lines).

The project context includes all characteristics of the situation at hand, or in other words of the variation point. The characterization of the project context allows configuring a method line from the existing method family. Thereby, the obtained method line matches the situation at hand.

Method Family

Method

Context Meta-Model

In our proposal, we describe the context as a set of characteristics. These characteristics describe situations of a method application. The detailed context model is presented in Figure 3.4. We distinguish two types of characteristics (and consequently two types of facets): generic and specific. The first ones are common for most IS engineering projects; the latter ones vary from one project to another. To distinguish between them is important because of their different identification approaches. The context characteristics set is defined for a method component. Therefore, each method component is described by the valuations of these characteristics (value). In the following, we describe different context characteristics by facets.

Generic Characteristics

In order to establish the typology of generic characteristics we have used IS development project characteristics [Kornyshova et al., 2007c]. In this work, a project characteristics typology is proposed in order to guide method components retrieval and to prioritize the selected components. The suggested typology of context characteristics covers essential aspects of IS engineering projects. Based on [START_REF] Mirbel | Mirbel I. and Ralyté J.: Situational method engineering: combining assembly-based and roadmap-driven approaches[END_REF], [Van Slooten et al., 1996] and [Kornyshova et al., 2007c], it includes four facets: organizational, human, application domain, and development strategy.

The organizational facet (Table 3.2.) highlights organizational aspects of IS project development. For instance, the Management Commitment characteristic represents the management team involvement in the project. Possible values for this characteristic are Low, Normal and High (i.e., a High value means a high involvement and so on). The human facet (Table 3.3.) describes the qualities of persons involved in IS project development. For example, the User involvement characteristic represents the kind of participation of the users in the project. Its values may be real or virtual. The application domain facet (Table 3.4.) includes indicators characterizing the domain of IS project.

For instance, the Application type characteristic deals with the different kinds of projects according to the organization structure and can have the following values: intra-organization application, interorganization application, organization-customer application. The development strategy facet (Table 3.5.) gathers indicators about different characteristics of development strategy. For instance, the Source system characteristic represents the origin of the reused elements that may be code, functional domain, or interface.

Specific characteristics

The identification of specific characteristics is based on the particular method description or representation. The method engineer defines them by analysing different aspects. Different elements of methods are analysed in order to elicit a set of characteristics allowing distinguishing the specific context of the method application.

For instance, for methods expressed with maps, specific characteristics could be organized into four facets: intentional, satisfaction, decisional and internal, like in [Harmsen, 1997]. The intentional facet concerns the method intentions. The satisfaction facet indicates the satisfaction degree that the engineer has about the method application results. The decisional facet arises from a decision-making process in the method. The internal facet concerns the known criteria associated with the specific project management. For the specific map characteristics see Table 3.6. Table 3.7 shows the correspondence between the proposed typology and the existing context elements (analyzed in the previous section). We can make some remarks to compare them:

• Our typology covers all existing elements.

• We propose to identify more precisely process and product characteristics using our approach instead of using product and process as context characteristics directly. • We add decisional characteristics that are not presented in the existing typologies.

Enrichment of the Intentional Model MAP with Context

The usual navigation on the map is based on a set of arguments which are not always sufficiently detailed, and which do not allow to select the right components in an obvious manner. We suggest describing method components and, therefore, different elements of map with the use of various quantitative and qualitative characteristics. These criteria become a prerequisite to have a better guidance.

Thus, we associate a set of characteristics to each level of method component granularity: from the method family to the simple atomic components. As the method family is expressed with Map, we must also define the corresponding characteristics for the DM map in order to provide means for the further DM method family configuration. The context is composed of a set of characteristics measured with different indicators. Method components are evaluated according to these characteristics in order to define the situations in which their application is suitable.

In the same manner, we attribute characteristics to the map sections instead of the different guidelines proposed by the Map model (See Figure 3.5.). Context characteristics (the set of indicators and the corresponding values for sections) enrich the existing guidelines and make them more formalized in order to provide simpler configuration of the method family.

Figure 3.5. MAP Basic Model (A) and MAP Enhanced Model (B).

An example of the context will be given in Section 3.2.2 together with the approach of the context definition.

Modelling User eXperience

We elaborated a UX conceptual model reflecting the different UX dimensions and used to capture data about the context for the further UX personalisation [Kornyshova et al., 2022b].

User eXperience Conceptual Model

Information and Communication Technologies (ICT) overwhelm everyday life to provide an enhanced form of living. Digital extensions to our common senses flourish based on a more connected world. Connections encompass humans, objects, homes, cars, pets, cities, organisations, industry, and banks to offer a Smarter Life. The key concept of this new era is interaction. As a broad concept, it is fostered through Information systems engineering, Communications, and more and more efficient Technologies to deliver an improved User eXperience (UX).

We believe valuable user experiences must be designed carefully with all dimensions of user context.

Due to the changing nature of the context, UX is necessarily specific and should be dynamically adapted to a given user or group of users. Dynamicity should consider time, space, and the user's profile. We assume that the profile is not uniform, it is a time-dependent concept. It is evolving through time and influenced by all sorts of events. Personalised user experience links with user characteristics, mood, and expectations. It also links with the object under consideration by the UX design process. In addition, multiple supports (devices and/or associated IS) take part in a user experience in almost all cases. This is the case with devices used in museums. We aim to provide the adaptation of these devices to different visitors; for instance, if a child is close to a screen, this one should show images attractive to the child. If he is an adult, the presentation on the same screen could be more serious.

For an older person, the font size could become bigger. The personalisation could be done at an individual level but also for a persona (user type). The same issue is present in organisations when users (employees) connect to different tools in their workplace and can have a personalised representation of available data. To obtain this personalisation, data about users and user experience should be stored and shared between different devices and supported by the IS of the organisation.

We reviewed the existing literature to check if any conceptual model of UX is already proposed. As defined in ISO 9241-210, "User Experience is a person's perceptions and responses that result from the use or anticipated use of a product, system or service" (definition from [START_REF] Bongard-Blanchy | Dimensions of User Experience -from the Product Design Perspective: Journal d'Interaction Personne-Système[END_REF]). All works on UX agree on the complexity and richness of this term [START_REF] Hassenzahl | User experience -a research agenda[END_REF][START_REF] Law | Towards a shared definition of user experience[END_REF]] [Zarour et al., 2017[START_REF] Law | Understanding, scoping and defining user experience: a survey approach[END_REF]. [START_REF] Hassenzahl | User experience -a research agenda[END_REF] defines three facets in UX: "beyond the instrumental", "emotion and affect", and the "experiential" (which means contextawareness and temporality). [START_REF] Law | Towards a shared definition of user experience[END_REF] enumerates different definitions of UX. [START_REF] Zarour | User Experience Framework that Combines Aspects, Dimen-sions, and Measurement Methods[END_REF] shows results of a Systematic Literature Review on aspects and dimensions of UX with the main goal of UX evaluation. The authors have identified five dimensions: values, user needs experience, brand experience, technology experience, and context. [START_REF] Law | Understanding, scoping and defining user experience: a survey approach[END_REF] presents a survey on the UX nature to obtain a shared definition that converges on UX as "dynamic, context-dependent and subjective". They detail different kinds of experience: product, system, service, and object experiences.

The most detailed generic definition of UX is done in [START_REF] Bongard-Blanchy | Dimensions of User Experience -from the Product Design Perspective: Journal d'Interaction Personne-Système[END_REF]. The authors present a product-oriented model of user experience. It includes the following dimensions: human perception (senses, cognition and affects, and responses), product (product sensors and product responses), experience context, and temporality of experience [START_REF] Bongard-Blanchy | Dimensions of User Experience -from the Product Design Perspective: Journal d'Interaction Personne-Système[END_REF].

Considering the UX representations, the authors of [START_REF] Liu | Deriving and Validating User Experience Model for DASH Video Streaming[END_REF] suggest and validate a mathematical model of UX in the case of dynamic adaptive video streaming. The authors of [START_REF] Jetter | [END_REF] develop a simplified model of User Experience to explicitly link UX with usability and Human-Computer Interactions. A temporal model of the UX lifecycle is highlighted in [START_REF] Pohlmeyer | User Experience Lifecycle Model ContinUE[END_REF] with an explanation of different UX phases.

More detailed works on personalized UX are [START_REF] Engl | Contextual influences on mobile player experience -A game user experience model[END_REF] and [START_REF] Han | User experience model for augmented reality applications in urban heritage tourism[END_REF]. [START_REF] Engl | Contextual influences on mobile player experience -A game user experience model[END_REF] presents a three-layers contextual gameplay experience model linking the player (with his experience corresponding to player characteristics and internal influences) to the game system (playability), and external influences (called contextual gameplay experience). External influences include spatial, temporal, social, and cultural influences. In [START_REF] Han | User experience model for augmented reality applications in urban heritage tourism[END_REF], the authors detail a UX model, which includes product features having an apparent product character for each user. The user is subjected to different consequences of the apparent product character depending on the situation. The authors apply their model to augmented reality in the case of urban heritage tourism.

Despite numerous works on UX, we did not find any existing conceptual model allowing to structure the required data. Senses, affects, responses, and context are the basic components that could be considered as input/output to feed the user experience. User experience is related to the corresponding objects (used in a specific experience) and subjects (that we foresee larger than the concept of a simple user).

It is also connected to a device represented by an ICT component used in the experience (in our work, we consider user experience only supported by digital technologies). User experience could be expected (by the user or by designers) and lived during the experience. In the following, we explain all these concepts. User_Experience. UX expresses an experience of a user toward an object. A user experience is unique for a user and for a time slot, but it could be associated with one or with a set of objects. This is the core concept as we consider that users communicate with objects through user experience. The UX concept is composed of four related concepts: sense, affect, response, and context (the four composition links), each of them representing a detailed taxonomy of possible elements. UX is a combination of different possible values of the taxonomy elements. The user experience concerns at least one object but could be associated with many objects. Each object is associated with multiple user experiences. Each user experience is associated with only one UX subject (the has association).

Sense. The typology of senses is taken from [START_REF] Bongard-Blanchy | Dimensions of User Experience -from the Product Design Perspective: Journal d'Interaction Personne-Système[END_REF] which distinguishes the following types: exteroceptive (external to the organism stimuli), proprioceptive ("spatial body orientation"), interoceptive ("stimuli produced within the organism"), and chronoception (sense of time). Different senses are sight, hearing, taste, smell, touch, thermic, pain, and so on. Affect. Affects (lived emotions, values, etc.) as cognitive processes "link external stimuli information with brain… in order to reach an interpretation of the stimuli on their semantic and aesthetic character" (from [START_REF] Bongard-Blanchy | Dimensions of User Experience -from the Product Design Perspective: Journal d'Interaction Personne-Système[END_REF]). Response. Human responses include physiological, motor, and motivational affects [START_REF] Bongard-Blanchy | Dimensions of User Experience -from the Product Design Perspective: Journal d'Interaction Personne-Système[END_REF]: temperature sensation, respiration change, cardiovascular change, posture, gesture, mimic, voice, etc. Context. The context factors are inspired from [Kornyshova et al., 2011b] as better reflecting the context content: external context (like weather, season, time), organisational context, etc.

For each of them, the model allows to identify the Type and to specify a Value or a Description of the given characteristic. For instance, for a cardiovascular change, we can register the corresponding value, or for an emotion or a value (as an affect), we can give a description.

As in [START_REF] Astic | Astic I.: Adaptation dynamique des jeux de visite pour les musées : contribution à l'équilibrage de l'expérience du visiteur joueur[END_REF], we consider two kinds of UX: expected and really experienced (the inheritance associations). The instances of Experienced_UX store data about real UX together with data about this experience: Date, Time, and possibly Result (for instance, a "like") and Comment if they are left by subjects. In addition, a UX subject has expectations concerning his/her future user experience. Thus, an instance of an Expected_UX could be defined.

UX_Subject could be a User of a Community (the inheritance associations). Both could correspond to a concept of Persona mainly used to characterize users in this field. A UX subject has multiple "user experiences".

User. "A user is a human who is targeted to utilize a product" [START_REF] Bongard-Blanchy | Dimensions of User Experience -from the Product Design Perspective: Journal d'Interaction Personne-Système[END_REF]. Users have different parameters describing them: Age_category, Gender, Profession_category, Preferences, Mood, Expectations, and History. Only data authorized by the user could be stored respecting the General Data Protection Regulation (GDPR) rules.

Community.

A community represents a group of users identified within a friendship network and is mainly characterized by a Topic and people participating in it [START_REF] Zhang | User community discovery from multirelational networks[END_REF] expressed with an association class Role. Users can have various roles in different communities (Role_Name).

Persona. The Persona term is related to a type of user often an imaginary one but deduced from data gathered during the exploration of users. [Tomlin, 2018] defines a Person as a "representation of the most common users, based on a shared set of critical tasks." A Persona describes different characteristics, needs, and behaviour of this typical user. This concept is central to the users' representation in UX-related approaches. It includes generally demographic and biographical data: personal, technical, relationship, and opinion information [START_REF] Aquino | User modeling with personas[END_REF]. The authors of [START_REF] Skillen | Ontolog-ical User Profile Modeling for Context-Aware Application Personalization[END_REF] present a detailed ontology-based user characterisation using the concept of Persona to personalize UX applications depending on context. We take the most important characteristics in our model (Name, Age, Habitation, Job, Profile, Motivation, Frustration, and Experience), but this list could be extended if needed by a given case. A persona could be associated with a unique user or with a community.

UX_Object. Each UX is related to at least one UX Object. We use this generic term to group products, services, systems, or objects of experience from [START_REF] Law | Understanding, scoping and defining user experience: a survey approach[END_REF]. Users can experience a whole group of objects, for instance, from a museum room without differentiating concrete objects (the composition link on the UX_Object concept). Different attributes characterize UX Objects. An object is not only the physical object itself but a set of relevant data about it: history of creation and of evolutions, author(s), way of production, uses, civilisation it belongs to, maintenance events, etc. These aspects are revealed using ICT devices, augmented reality for example. It can include variations in colours, texture, sounds, forms, and so on. We define the main attributes: Name, Function, Usage, and History. This list could be extended obviously.

Device. A device supports the user experience itself. The nature of the device could be different from communication devices (smartphones, tablet computers, glasses, VR masks) to sensors used to capture gestures, movements, eye tracking, and so on. At least one device is required to represent a UX Object, but it could be done by multiple devices. [START_REF] Bongard-Blanchy | Dimensions of User Experience -from the Product Design Perspective: Journal d'Interaction Personne-Système[END_REF] enumerates types of sensors that could be associated with a consumer product: physical, logical sensors, sensors capturing external factors (contact, range, vision sensors), internal factors (like heat monitoring), and so on. We characterize devices by two main attributes: Goal and Type. An object requires to have a supporting device, each device could support one or more object(s). A device could contribute to multiple user experiences (the launches association). The user experience should have at least one associated device (for our purpose, we do not consider UX without any technology-based support).

This conceptual model of User Experience aims at highlighting different UX-related dimensions that we can store in IS for further data utilisation to personalize the experience. In this manner, data about UX are centralized and standardized. It also helps to compare the planned and real experience. In addition to these practical needs, the introduced conceptual model contributes to several challenges (based on [Kornyshova et al., 2010a]): to formalize UX knowledge through different concepts and their relationships; to develop a shared representation of UX concepts; to make UX knowledge reusable in different projects and contexts; to support the creation of UX models applied to various fields, and to check and validate the existing UX models or other representations.

To analyse the UX-related concepts, we selected the context of cultural heritage. Museums offer emotional visits, and most of the applications developed for museums could be, by design, obsoletes at the time they are launched. The missing point is evolution. Visitors change, and what they feel too is changing. Artefacts move from one place to another (sometimes to another museum). Temporary events are programmed to underline an artist or a piece of work… This is a very preliminary list of the kind of evolution a museum should face. Any change is a risk for the launched application because it can be unable to reconfigure to take into account changes. Applications for museums should be designed in a different way. The challenge is to provide a model that supports changes over time and that the applications that rely on this model can evolve accordingly to these changes. Museum IS are often database-oriented (collection management systems - [Wu, 2016]). In [Wu, 2016], the author suggests an approach to integrate five museum legacy information systems applied to the case of the National Palace Museum in Taiwan. [START_REF] Chianese | Designing a Smart Museum: When Cultural Heritage Joins IoT: Third International Conference on Technologies and Applications for Smart Cities[END_REF] present an Internet-of-Things architecture to design Smart museums. Except for [START_REF] Kulfik | [END_REF] and [START_REF] Astic | Astic I.: Adaptation dynamique des jeux de visite pour les musées : contribution à l'équilibrage de l'expérience du visiteur joueur[END_REF], we did not identify any other work dealing with a conceptualisation of UX in the context of Man-Museum interactions. [START_REF] Kulfik | [END_REF] present the visitor, site, and visit models. [START_REF] Astic | Astic I.: Adaptation dynamique des jeux de visite pour les musées : contribution à l'équilibrage de l'expérience du visiteur joueur[END_REF] presents a model of the Visitor-Player experience. In this work, the visit game personalisation is thought of as a resolution of puzzle intrigues between external components (playability and context) and players' expectations.

User experience in museums is considered as containing three phases: pre-visit, on-site visit, and postvisit [START_REF] Kulfik | [END_REF]. [START_REF] Astic | Astic I.: Adaptation dynamique des jeux de visite pour les musées : contribution à l'équilibrage de l'expérience du visiteur joueur[END_REF] details the notion of museum visit experience to define "balanceable" visit games. This work also distinguishes between expected and really lived experiences.

The UX components Sense, Affect, Response, and Context are less studied in the museum-related literature. [START_REF] Harada | Museum Experience Design Based on Multi-Sensory Transformation Approach: Proceedings of the DESIGN 2018[END_REF] present a multi-sensory transformation approach to enhance the museum visit experience. [START_REF] Astic | Astic I.: Adaptation dynamique des jeux de visite pour les musées : contribution à l'équilibrage de l'expérience du visiteur joueur[END_REF] defines four groups of contexts: museal, temporal, cultural, and social. UX Subjects in museums are studied through the "Persona" concept. "Personas are detailed descriptions of imaginary people constructed out of well-understood and highly specified data about real people" [START_REF] Pruitt | The persona lifecycle: keeping people in mind throughout product design[END_REF]. Different approaches consider individual visitors [Van Hage et al., 2010] [Noor et al., 2009] [Bohnert et al., 2010] [Damala et al., 2012], groups [START_REF] Kulfik | [END_REF]] [Luyten et al., 2006], or both [START_REF] Ghiani | UbiCicero: A location-aware, multidevice museum guide[END_REF]] [Amato et al., 2013]. Several works detail user characteristics.

The visitor model form [START_REF] Kulfik | [END_REF] includes a visitor profile (demographics and preferences), his/her state, together with the number of visitors in a group. [START_REF] Chou | Semantic web technologies for context-aware museum tour guide applications[END_REF] give an overview of identified user characteristics from literature, such as user profile (age, gender, education, skills, and so on) or user preferences (related or not to the museum context). Several approaches also consider the feedback of the user after visiting the museum. Different museum UX objects are mainly art pieces.

A group of objects can be an exhibition room or a logical group of objects like Lavoisier Lab (https://www.arts-et-metiers.net/musee/visitor-information) representing a set of objects which have a real additional value when presented together. Several works mention object attributes as factors for visit personalisation: available multimedia information (graphical, video, audio, etc.) regarding the artworks [START_REF] Ghiani | UbiCicero: A location-aware, multidevice museum guide[END_REF]; multimedia collection containing digital reproductions of sculptures, educational videos, audio guides, textual and hypermedia documents with a description of authors and sculptures [Al Hudar, 2019]. In addition, several museums and other cultural heritage institutions detail various characteristics about museum information considered during user experience: museum map [Van Hage et al., 2010] [Ghiani et al., 2009], repository of cultural heritage data [START_REF] Noor | Using social data as context for making recommendations: an ontology based approach[END_REF], and exhibitions' locations [START_REF] Bohnert | Personalised pathway prediction[END_REF]. The most detailed typology of devices used in museums is given in [Recouvreur, 2019]. The author enumerates more than 50 devices grouped into 13 categories like handling devices, viewing devices, projection devices, etc. [START_REF] Chou | Semantic web technologies for context-aware museum tour guide applications[END_REF] summarizes devices used in different projects dealing with museum user experience: PDA (personal digital assistant) devices with RFID (Radio Frequency Identification) tags [Chiani et al., 2009[START_REF] Amato | [END_REF], mobile devices [START_REF] Antoniou | Capturing the visitor profile for a personalized mobile museum experience: an indirect approach[END_REF][START_REF] Kulfik | [END_REF]] [Van Hage et al., 2010], glasses [START_REF] Damala | Adap-tive augmented reality for cultural heritage: ARtSENSE project[END_REF], sensors [START_REF] Damala | Adap-tive augmented reality for cultural heritage: ARtSENSE project[END_REF], etc.

Currently, different kinds of organisations have started to apply UX to promote their activities and to improve the relationships with their users: customers, visitors, and clients. For example, it can be refined as customer experience or brand experience [START_REF] Law | Understanding, scoping and defining user experience: a survey approach[END_REF]. We proposed a conceptual model allowing to store data about UX and to share information about how UX could be personalized for a given user. This model will help different organisations to establish an IS for implementing shared data about UX. The proposed conceptual model offers a representation of UX and allows checking the completeness of the UX-related concepts of a real application. In our current work, we are adapting the UX conceptual model to consider the context in the case of enterprise ecosystems in order to improve the employees' experience.

Context Discovery

With regards to the context discovery, the contributions are unified around the following directions: context definition approach (Section 3.2.1.), context extraction from sensors logs (3.2.2.), and process model enrichment with data from sensor logs (Section 3.2.3.).

Context Definition Approach

We defined an approach of the context definition and illustrated it with several examples in [Kornyshova et al., 2011b] [Kornyshova et al., 2010b].

Contextualisation Approach

Existing SME approaches consider the notion of context in order to guide the selection of a method component from a repository according to a given situation. However, the reviewed literature shows that, firstly, there is no approach considering all of the possible characteristics and, secondly, these approaches do not suggest a methodology allowing to define a set of concrete context characteristics for a given method.

In order to define the context for a given method and its components, we propose an approach based on the contextualisation process modeled with the MAP formalism (See Figure 3.7.). This process includes two possible ways to define the context: top-down or bottom-up. By the top-down approach, the engineer defines the method context and then instantiate it for each method component. By the bottom-up approach, the engineer specifies the contexts of all method components and assemblies them into the method context.

Both method and method component contexts can be defined following two strategies: By deduction and By generation. It depends on the characteristic type. The generic characteristics are deduced from the generic context typology and the specific ones are generated from method description. These strategies could be applied as many times as possible characteristics exist. This MAP has two main intentions: Define method context and Define method component context. The achievement of these intentions implies the definition of the context characteristics set for method or for method components respectively. The definition of method components contexts also includes the attribution of values to the defined characteristics. The contextualisation Map includes eight sections, as shown in Table 3.8. The result of this strategy is a sub-set of generic characteristics available for a given project. The corresponding operator is:

• Select Context Characteristic ()
<Start, By deduction, Define method component context>. This section includes the selection of characteristics form generic typology like the previous one and includes furthermore the attribution of values to these characteristics. The result of this strategy is a sub-set of generic characteristics available for a given project with corresponding values. Two following operators are applied consecutively:

• Select Context Characteristic () • Attribute a Value to Context Characteristic ()
<Start, By generation, Define method context>. The specific characteristics generation is based on the method description. The method engineer defines them by analysing different aspects which are organized into four facets: intentional, satisfaction, decisional and internal. This section includes four operators. Each of the following operators is applied depending on the corresponding characteristic's facet:

• Analyse Method Goal () • Measure Method Satisfaction () • Analyse Method Argumentation () • Measure Method Characteristics ()
<Start, By generation, Define method component context>. The definition of specific characteristics for method components context is the same as for method context (the previous section) but also requires the attribution of characteristics values. This section uses the same four operators and adds another one that deals with the attribution of values to the characteristics. This last one is applied after each of the first four operators for defining concrete values of the identified specific characteristics.

• Analyse Method Goal () [for intentional facet] • Measure Method Satisfaction () [for satisfaction facet] • Analyse Method Argumentation () [for decisional facet] • Measure Method Characteristics () [for internal facet] • Attribute a Value to Context Characteristic () [for all facets]

<Define method context, By instantiation, Define method component context>. The context characteristics instantiation is common for both characteristic types and is applied in the top-down approach. This section allows defining a sub-set of generic and specific method characteristics with an associated value for each method component separately. Several functions may be applied (sum, maximum, minimum, average, weighted sum, and so on) for attributing values to the method context. This section contains two operators applied consecutively:

• Retain Context Characteristic () • Attribute a Value to Context Characteristic ()
<Define method component context, By assembly, Define method context>. In the case of the bottom-up approach, the strategy By assembly follows the definition of the method component context By deduction or By generation. The method engineer groups method components characteristics together. As a result, the method context includes all characteristics of its components contexts. The application of this strategy allows also defining characteristics' values for the method context. This section is carried out by the following operator:

• Group Characteristics () • Attribute a Value to Context Characteristic ()
<Define method context, By completeness, Stop> and <Define method component context, By completeness, Stop>. These sections are the same in both top-down and bottom-up approaches and include verification of completeness and coherence of the described context. The associated operator is:

• Verify Context Completeness ()
All these operators are summed up in the Table 3.9.

Table 3.9. Operators' Description.

Operators

Description Select Context Characteristic ()

Helps to select each of the pertinent characteristics of the context.

Attribute a Value to Context Characteristic ()

For each characteristic selected, a value corresponding to the project context has to be defined.

Analyse Method Goal ()

Helps to define the characteristics of the intentional facet which concerns the method intentions (the method goals).

Measure Method Satisfaction ()

Helps to measure the satisfaction degree on the results obtained by the engineer and concerns the satisfaction facet.

Analyse Method Argumentation ()

The decisional facet needs this operator in order to describe a decision-making situation with the definition of the arguments to take into account in the DM process.

Measure Method Characteristics ()

This operator is used to give values to the characteristics associated with the specific project management.

Retain Context Characteristic ()

Helps to define a subset of characteristics (generic or specific characteristics) and to give them values adapted to the project.

Group Characteristics ()

This operator allows to group all the characteristics together in the same set which corresponds to the context.

Verify Context Completeness ()

Helps to study the completeness and the coherency of the context set of characteristics.

Illustration of the Context Definition Approach

The contextulisation approach was applied to three cases [Kornyshova et al., 2011b]: scenario conceptualisation, decision-making, and project portfolio management. Here, I present the case of project portfolio management as an example. The Figure 3.8. shows the IT-PPM (Information Technology-Project Portfolio Management) intentional map which describes the ways to manage a project within a portfolio. This map contains three main intentions: "Identify project", "Evaluate project", and "Prioritize project" and ten associated sections. The related components are saved into a method base which includes their description and methodological guidelines for their application.

The engineer has selected the top-down approach of the contextualisation process. It guides the engineer through the definition of the method characteristics before the definition of method component characteristics. Figure 3.9. shows the path used in the navigation through the contextualisation map in this particular case study. This path contains four sections of the Contextualisation Map that we represent within the three following steps:

1. Definition of the method Context (S 1 and S 3 ), 2. Definition of the method components contexts (S 5 ), and 3. Verification of the process completeness (S 8 ).

First step (S 1 , S 3 : Definition of Method Context

). This step contains the execution of two sections of the Contextualisation Map: S 1 and S 3 . 3.12.

Definition of the generic characteristics (S 1 ). The engineer uses the characteristics presented in

Third step (S8: Verification of the process completeness). The engineer has decided that the identified context characteristics are sufficient to allow a satisfying guidance through the portfolio project management by the operator Verify Context Completeness () application.

Our approach gave a strong definition of a method component context. We have studied the literature to define the criteria that may be used to characterize the situation in which method components may be used. This leads us to define a typology of characteristics which we have structured in different facets (each considering a special view of a project). We then related these characteristics to the method component concepts. In addition, we developed a contextualisation process which will help engineers to define the method components context with ease. We have identified two possible ways to use these characteristics for defining context (the top-down and the bottom-up approaches) in order to propose a contextualisation process that may be adapted to several situations.

Context Extraction from Sensor Logs

Currently, the main source of data comes from sensors and other devices. We developed an approach to combine sensor data with events logs using domain ontologies and validated it with a case of Smart home [Elali et al., 2022b].

Approach to Combine Sensor Data and Event Logs Using Domain Ontology

An enormous amount of events data and sensor data is being recorded daily whilst the propagation of Information and Communication Technologies is taking its rise worldwide across all domains. Data have become available everywhere. Hence, the challenge becomes to turn these data into value to get insight, increase productivity, produce better performance, and save costs [Aalst, 2016]. Event logs are one of the main information inputs for mining techniques [START_REF] Diaz-Rodriguez | Literature Review about Intention Mining in Information Systems[END_REF]. However, these approaches do not usually consider the context aspect behind the recorded user activities.

The challenge is to study how to use data from sensor logs to gather contextual information. We suggest using ontologies to associate this information with events logs. Ontology is an important subject in the domain of IS [START_REF] Woznowski | A Human Activity Recognition Framework for Healthcare Applications: Ontology, Labelling Strategies, and Best Practice[END_REF]. Many researchers use ontology to classify domain knowledge [START_REF] Mansingh | Using ontologies to facilitate post-processing of association rules by domain experts[END_REF], such as concepts, all types of entities, and their existing relationships [Viinikkala, 2004]. Ontology organises information in a natural, logical, and systematic way. Therefore, contextual information can be structured into a domain ontology by describing the relationships between the entities of the domain ontology and the contextual information.

In our view, ontologies can help to combine sensor data and activity logs. Firstly, all the data acquired from the sensors and the events log activities can be semantically interpreted in an ontology specific to the domain. Secondly, all the links between the ontology concepts (especially the links between the sensors and activities elements) must be defined. For instance, a specific value of sensor data can trigger the start or the end of an activity.

To combine sensor data and event logs using domain ontology, we have to proceed in three steps (See Figure 3.10.): (1) create the activity ontology based on the event log, (2) create the sensor ontology based on the sensors data, and (3) refine the domain ontology by creating the links between the two preceding ontologies (white arrow on the second part of Figure 3.10). If the events log and the sensor data are already related to existing ontologies, we can proceed directly to step 3 to identify the links between them. Thus, we focus on step 3 with two main hypotheses: H1: It is possible to identify the ontological links between sensor data and activities using the timestamp on data and events. H2: It is possible to identify the ontological links between sensor data and activities by association rules.

The timestamp is considered the only attribute that can let us find the relationship between the activity event and the sensor. We developed a Python algorithm that takes as input the events log and sensor log. The two logs need to be sorted according to the timestamp field. This algorithm is composed of two main steps. In the first step, the start and completion of each activity should be identified. Then, the timestamp field is used to pivot the events log according to the start and completion of each activity. In the second step, a join was done between the two logs using the timestamp field to create the link between the sensor data and the event data. databases by indicating the frequent associations rules that are composed of antecedent and consequent [START_REF] Zaki | Data Mining and Analysis: Fundamental Concepts and Algorithms[END_REF]. Association rules allow uncovering the hidden relationships between the items that are frequently used together. It is represented by if-then statements (an antecedent itemset and a consequent itemset). Apriori [START_REF] Agrawal | Fast algorithms for mining association rules[END_REF] is one of the top standard algorithms for frequent item set mining and association rule learning. In this work, we used Association Rule mining techniques since we needed to find rules between the sensors and the activities.

Illustration with the Smart Home Case

We illustrate our proposal through a Smart home case study. The rapid evolution of artificial intelligence endorses the existence of Smart homes and makes it crucial to study this domain. Numerous studies have been done on Smart homes [START_REF] Tiwari | Changing World: Smart Homes Review and Future[END_REF]] [Alam et al., 2012] [De Silva et al., 2012] [Alaa et al., 2017]. Hence, our case study will focus on Smart homes since this field is rich in sensors. We need to find the link between the person's activities and the sensors to find later how the context can affect the user's intention. Data preprocessing includes standard activities aiming at enhancing data quality: cleaning, integration, and transformation [START_REF] Tamilselvi | An efficient preprocessing and postprocessing techniques in data mining[END_REF].

Our experiment uses the dataset provided by BP-Meets-IoT 2021 Challenge [START_REF] Koschmider | BP-Meets-IoT 2021 Challenge Dataset[END_REF]. This dataset consists of two people's activity logs and the sensor logs recorded during 21 consecutive days between 16 March 2020 and 6 April 2020. While studying the dataset, we found 53 activities and 16 sensors. Both logs contained noise data, some duplicated records, in addition to some records that didn't represent any activity or sensor. We cleaned the dataset from the noise by removing those tuples, and we obtained 23166 records in the events log and 39304 records in the sensors log. A sample of each of the datasets is shown in Figure 3.11. Each record in the event logs is identified by the Activity Name, while each record in the sensor logs is identified by the Sensor Name and both logs are categorised by the Timestamp and the Resource Id. There was not any defined domain ontology given with the dataset. Moreover, despite previous works already having defined ontologies for daily activity recognition in Smart homes [START_REF] Woznowski | A Human Activity Recognition Framework for Healthcare Applications: Ontology, Labelling Strategies, and Best Practice[END_REF]] [Chen et al., 2012] [Salguero et al., 2018] [Chen et al., 2009] [Bae, 2014], none of them were matching the data of our dataset. Thus, we had to define this domain ontology ourselves. After a deep analysis of the sensors and events log data, we identified the different parts of the domain ontology. To construct our domain ontology -specific to our dataset and case study -we have defined two main ontologies (Smart home activity ontology and Smart home sensor ontology). We define the more complex associations between the concepts in a specific meta-model (cf. Figure 3.12.).

The Activity ontology contains the different types of activities and actions that can happen inside a home. Each activity should be completed by a human inside a fixed location. The Activity ontology is divided into groups of activities: Bathroom Activity, Clean Activity, Work Activity, etc... Each activity group inside the Activity ontology has its own instances. As an example, the Kitchen Activity has a set of real-life activities that happen inside the kitchen. Drink Water, Go Kitchen Shelf, Put Plate to Sink, Wash Dishes, etc. are instances of the Kitchen Activity group.

Smart Home Sensors Ontology includes three parts: Sensor, Position, and Human ontologies. The sensor ontology contains all the information related to the sensors, such as sensor type, value, value range, and location. According to our dataset, we could identify different types of sensors, such as Environment sensors, Kitchen Sensors, etc. The high level of the ontology sensor, where the sensors are divided into different types, and each type contains its related sensors. For each location inside the home, there are a set of sensors related to the location, such as Kitchen sensors, Bedroom Sensors, and Living Room Sensors. Some sensors are common to all the house as the Environment Sensors, Power Sensors, and Water Sensors. We can identify different relationships between the defined ontologies (see Figure 3.12.). Each human does activities. Sensors affect activities and can be positioned at a specific position. Each activity can be followed by one or many activities (that can be done sequentially or not). Each activity can happen at a particular position at home and be affected by sensors. Each position can be related to sensors and activities. Figure 3.13. illustrates an example of the links between the ontologies. When the human's goal is Washing Dishes then the set of activities that are related to this goal will take place inside the kitchen; the inhabitant will go to the kitchen sink, put the plate inside the sink and start to wash dishes. In the meantime, the sensor of Unwashed Dishes will increase its value according to the plates being washed. The Water Use sensor will increase its value and the Position sensor will indicate that the human position is next to the Kitchen Sink.

The established relationships were used to test the established hypotheses (H1) et (H2). To validate H1, an automatic test was done using Python as a programming language. 100836 records were obtained corresponding to 53 different activities and 16 different sensors. The obtained data was cleaned because it contained some noise data, thus, the remaining was 99975 records. We obtained 112 correspondences between activities and sensors. We compared the mapping results with the results we obtained manually while analysing the data and deduced that for each occurred activity there is one or multiple sensors were triggered. An extraction is given in Table 3.13. to illustrate the obtained links between activities and sensors using the timestamp data. In this manner, we were able to validate H1 and identify the link between the activities and the sensors while relying only on the timestamp.

To validate H2, a second test was done using Association Rules by applying the Apriori algorithm [START_REF] Agrawal | Fast algorithms for mining association rules[END_REF] on the dataset selecting only the logs that are relevant to one person. To apply the Apriori algorithm, first of all, we needed to transform the dataset into a transaction log supported by the algorithm. We labelled each log by day date, and then we combined both logs and sorted them according to the day and the timestamp. Then we transformed the combined log into a transaction log which is supported by Apriori. In addition to the transaction log, Apriori needs multiple parameters such as the minimum support and minimum confidence as input. Support indicates how often an itemset is frequent in the transactions. Confidence indicates how often the rule (if → then) statement is found true. After combining the logs, we obtained 410 transaction records. We did three experiments. We set the confidence value to 80% in all the experiments to get strong rules. The minimum support value is set through the process of trial and error. In the first experiment, we set the value of minimum support to 0.15, and we obtained 56 rules. In the second experiment, we set the minimum support value to 0.05 and obtained 8565 rules. And in the third experiment, we set a small value of minimum support equal to 0.03, and we obtained 34623 rules. Three experiments are shown in Table 3.14. We analysed the generated rules manually and found that the result of the second experiment is more realistic due to the value of the minimum support and the confidence. Table 3.15. presents a small extraction of the obtained rules with the corresponding confidence degrees for each rule. Thus, despite the limitation of Apriori to perform well when the itemset is large, we were able to generate rules that associate activities with sensors and validate H2. Overall, this experiment has validated the existing relationship between the sensors and the activities.

We could automatically find the rules we had found before manually while analysing the dataset. For instance, when a person goes to the kitchen next to the shelf, the position sensor will locate his position accordingly, so the next activity will be to get a glass and then move to the sink where the"water use" sensor will directly reflect the water consumption while filling the glass with water. And after drinking water, the "unwashed dishes" sensor will increment its value.

This research suggests an approach to constructing domain ontologies using sensor data and event logs. Sensor, Position, Human, and Activity are the ontologies that were defined. Our main objective in this work was to find relations between sensors and activities. We identified and validated the link between sensor data and activities based on a Smart home case study. This contribution is tightly related to constructing the contextual process model presented in the following section.

Process Models Enrichment with Data from Sensor Logs

We use the results presented in the previous sub-section to elaborate an approach to construct contextual process models and applied it to the case of Smart home activities [Elali et al., 2022a] [Elali et al., 2023b].

Approach for Constructing Contextual Process Models in Case of Smart Home

Process models are widely employed in various fields. The enrichment of process models by additional data had already been handled with semantic process models [START_REF] Lautenbacher | Semantic Business Process Modeling -Benefits and Capability[END_REF]. In this work, the authors discussed the benefits and the capability of semantic process modelling. Several works study how process mining could be enhanced using semantic data organised into ontologies [START_REF] Medeiros | Process Mining towards Semantics[END_REF] [ [START_REF] Kingsley | [END_REF]] [Espen et al., 2021]. However, works about how to integrate data from sensors into semantics in order to improve process definition and management are not numerous. Our goal is to improve process models by semantics issued from sensor data to build a contextual process model.

The method we suggest to construct contextual process models is illustrated in Figure 3.14. It includes data transformation as a first step. Then, the method contains the next three steps (Activity and Sensor Mapping, application of the Apriori Algorithm [START_REF] Agrawal | Fast algorithms for mining association rules[END_REF], and the Process Model Discovery using Disco) which could be applied separately or in parallel. As a final step, we create a contextual process model using the outcome of the previous steps. set 1 (DS1), and in data set 2 (DS2) we obtained 23166 event records. We have transformed both logs from XES to CSV for data manipulation. Then, we added two additional attributes for both logs: the Position attribute and the Day attribute. For the Position attribute, we have annotated each activity record and each sensor event record with a position value that indicates the actual location where the activity has taken place or the location where the sensor should be positioned. For instance, the Position attribute for an activity related to wash_dishes or unwashed_dishes should be the kitchen_sink. As for the Day attribute, we have annotated the records from Day1 to Day21 to group all the events linked to a specific day. For example, all the activity records and the sensor events records that have occurred between 2020-03-16 00:00:00+00:00 and 2020-03-16 23:59:00+00:00 are annotated by Day1.

Activity Mapping with Sensors. We have mapped the sensors and the activities according to the Position and the Timestamp attributes. Hence, we obtained 112 correspondences between the sensors and activities (already explained in the previous sub-section).

Apriori Algorithm Application. We have applied the Association rule mining technique Aprior as in the previous sub-section.

Process Model Discovery using Disco. This part allows us to complete the answer to the first question.

We have used the process mining tool Disco (http://www.fluxicon.com/disco/) to obtain the process models in order to know the difference between the habits of the weekend and weekdays and how likely a resource profile would affect the process model. We mapped the Day attribute in the activity logs to the Case attribute in Disco and applied the process discovery to the activity logs.

Contextual Process Model Creation. We generated a contextual process model based on the previous steps' results. We showed that contextual elements such as time, location, profile, etc., affect user activities directly or indirectly. It would be interesting to annotate the process model with contextual information. This will enrich the process model by providing more accurate information about the activity's current situation, which will help better decision-making and insights. Figure 3.15. shows a process sample extracted from the weekend process model from DS1. The process model was annotated by the information from sensors found previously from the mapping between the sensors & the activities and from the application of Apriori. This contextual information will help to get a clearer vision of the current situation. For instance, when the person's position is on the kitchen sink and the unwashed_dishes sensor value is greater than 1, then the person should be recommended to wash_dishes. On the other hand, the actor (user) profile should be taken into account because it also affects user behaviour, like the contextual environment.

We completed the previous results by an approach used to enrich the process models mined from the activity logs with contextual data. We applied this approach to a case study by exploring a dataset related to Smart home activities. We highlighted the differences between the mined process models whenever contextual information (weekdays Versus weekends) or the user profile (resource 1 Versus resource 2) changes. The multiplicity of the different mined process models, each related to a specific context, suggests the importance of constructing contextual process models. Much other contextual information can provide better knowledge since a person's activities would be different in different circumstances, such as time, location, country, culture, weather, etc. Using contextual process models would allow us to offer better recommendations to the users by contextually recommending the best-suited activity at a specific time and place. Our next step is to include the modelling of intentions in this approach.

Intention Discovery

The intention discovery axis includes the work on a state-of-the-art on intention mining approaches (Section 3.3.1.) and the construction of intentional models based on data from sensors and ontologies (Section 3.3.2.).

State-of-the-Art on Intention Mining

In [START_REF] Deneckère | A Framework for Comparative Analysis of Intention Mining Approaches[END_REF][START_REF] Deneckère | [END_REF], we suggested a comparison framework for Intention Mining (IM) approaches. I present the framework and its validation with five selected IM approaches.

Intention Mining Approaches Comparison Framework

The research domain of Intention Mining (IM) is quite new. It includes various techniques of intention discovery. IM has different meanings according to the communities. The proposed IM techniques and their aims are quite different from one domain to another. Moreover, Intention Mining is not the only term used to designate this activity as it has many synonyms: an "intention" may be an "intent", a "goal", an "objective", etc.; mining may signify "discovery", "analysis", etc. It is then necessary to conduct a literature review on what IM is and how it is defined by the different research communities in the computer science context. There are techniques aiming at discovering intentions behind web

Sequence flow

queries to improve the recommended web pages or services [START_REF] Hu | Understanding user's query intent with wikipedia[END_REF]] [Tang et al., 2012]; others propose techniques to identify intentions in home videos to provide adapted home video services [START_REF] Mei | Modeling and Mining of Users' Capture Intention for Home Videos[END_REF], while others propose to discover intentions hidden behind user activities defined in logs to understand users ways of working [Khodabandelou et al., 2013], etc.

To our knowledge, no proper systematic literature review has been conducted on Intention Mining. [START_REF] Moshfeghi | On Cognition, Emotion, and Interaction Aspects of Search Tasks with Different Search Intentions[END_REF] propose a state-of-the-art of intention recognition, but it is not a systematic literature review. [START_REF] Dai | Detecting online commercial intention (OCI)[END_REF] proposes a review of intention process mining but restricts itself to the discovery of goal-oriented processes. Moreover, these works do not use a structured framework to analyse and compare the existing approaches.

To provide a detailed and structured overview of the IM approaches and to clarify IM elements and categories, we have elaborated a comparison framework composed of four dimensions: object, usage, method and tool. This structure was inspired by [START_REF] Jarke | Requirements Engineering: An Integrated View of Representation, Process and Domain[END_REF]] [Rolland, 1998] [Kornyshova et al., 2007a] [Deneckère et al., 2008]. A detailed comparison framework is useful (i) for our future research, to carry out the SLR to compare the existing literature on IM and to define open issues, (ii) for a user, to be able to quickly compare the existing IM approaches and select the one best fitting its case, and (iii) for a new IM approach, to position it with regards to the existing literature.

As Figure 3.16. shows, we propose a classification framework that emphasises 4 main dimensions of Intention Mining: the object, the usage, the method, and the tool. We define the dimensions as follows:

• The Object dimension raises the question What is intention mining? It refers to the structure of the intentions, their taxonomy and formalism. • The Usage dimension raises the question Why use intention mining? It provides insight into the different types of objectives of intention mining, the domains of application, and the source and target of the existing approaches. • By providing details on intention mining approaches, the Method dimension raises the question How is intention mining achieved? For instance, the method dimension characterises an intention mining approach by indicating the theoretical grounding of the method, whether it exploits classification techniques or ontologies. • The Tool dimension provides details on support offered to enact the method. The question here is By which means is the intention mining method put into practice? Looking at this

• Mathematical Model • Classification Type • Algorithm Name • Ontology Name • Support • Tool Name Object Dimension Usage Dimension Tool Dimension Method Dimension • Structuredness • Intention Taxonomy • Intention Modeling Formalism • Usage Goal • Domain of application • Source Artefact • Target Artefact • Machine Learning Method • Automation Method • Observation Record Type • Mathematical Method • Classification-based • Ontology-based

Intention Mining Comparison Framework

dimension of an intention mining method indicates the algorithms on which it relies and the tools that it uses or implements.

The distinction between methods and tools is not obvious; it can be understood with the cooking metaphor: if methods correspond to recipes, tools are kitchen instruments.

Each dimension is specified as a set of attributes with a name and a domain. For instance, the object dimension has 3 attributes: "structuredness" indicates whether the output is an individual intention or a model, "intention taxonomy" and "intention modelling formalism" indicate how mined intentions are further specified by classification in taxonomy or by using a specific formalism.

The Object Dimension. Table 3.16 details the object dimension of intention mining that has 3 attributes: structuredness defines if the aim is to mine individual intentions (a mining technique can generate collections of individual intentions) or in relationship with other intentions (in which case, the output are intention models); the intention taxonomy attribute characterises the fundamental nature of the mined intentions (several taxonomies can be used in combination, hence the SET OF ENUM type); last the intention modelling formalism attribute indicates which notation is used to formalise individual intentions or collections of intentions. The Usage Dimension. The usage of intention mining approaches can be defined with 4 attributes: the usage goal of IM, the domain of application in which intention mining is used, the source and target type of users (that we called artefacts). The domain of these attributes is further defined in Table 3.17.

Comparison Framework Application

We have pre-selected 5 papers to validate the IM comparison framework.

To select relevant papers, we have used the ongoing work related to a systematic literature review (SLR). Our main research query used the following combination of key words: (user OR actor) AND (goal OR intention OR intent OR objective) AND (discovery OR mining OR analysis). We have identified 238 research papers from the research bases IEEE, Springer, ACM, Science Direct with the following inclusion criteria: papers should be in French or in English, title or abstract should be related to IM.

Then we applied some exclusion criteria (papers should be journal or conference papers, be present in DBLP (except for 2020 papers), and restrictions related to the citation number: if dated before 2010, we excluded papers cited less than 100 times, if dated between 2010 and 2017, we removed papers cited less than 10 times). We have finally obtained 145 papers. We have extracted the citation number from Google Scholar (accessed in January 2021) for each of these papers and selected the three most referenced papers [START_REF] Xiao | Unsupervised semantic intent discovery from call log acoustics[END_REF], [START_REF] Breazeal | Recognition of Affective Communicative Intent in Robot-Directed Speech[END_REF], and [START_REF] Hu | Understanding user's query intent with wikipedia[END_REF] having correspondingly 364, 347, and 306 citations. As these papers were published before 2010, we have also selected one most cited paper for 2010-2015 ( [START_REF] Tang | IntentSearch: Capturing User Intention for One-Click Internet Image Search[END_REF] with 151 citations) and one most cited paper for 2016-2020 ( [START_REF] Xia | Zero-shot User Intent Detection via Capsule Neural Networks[END_REF] with 78 citations) to validate our comparison framework with more recent studies on IM.

[ [START_REF] Xiao | Unsupervised semantic intent discovery from call log acoustics[END_REF] use click graphs to better classify users' query intents by semi-supervised learning. That allows us to avoid enriching feature representation. [START_REF] Breazeal | Recognition of Affective Communicative Intent in Robot-Directed Speech[END_REF] aim at detecting affective intents in a speech in the case of human-robot interaction. Their goal is to teach robots to identify praise, prohibition, comfort, attention, and neutral speech. In [START_REF] Hu | Understanding user's query intent with wikipedia[END_REF], authors present an approach to classify query intents of users by mining the content of Wikipedia. They associate an intent probability to Wikipedia articles and categories to provide a better classification. In the approach described by [Tang et al., 2012], a new way to capture users' intentions is proposed to improve Internet image search engines.

The main idea is to include images in addition to the classic keywords query and to refine search results depending on the clicked image. [START_REF] Xia | Zero-shot User Intent Detection via Capsule Neural Networks[END_REF] introduce Capsule Neural Networks to detect user intents when labelled utterances are not available. The proposed approach allows to avoid to label utterances as intents and thus reduces time and labour consumption. We described the selected IM approaches using the suggested comparison framework (See Table 3.20.). As a result, we were able to check the validity of the comparison framework accordingly to two criteria: applicability and completeness. With the first validation criterion, each approach was characterized with regard to most part of the comparison attributes. According to the second criterion, following the application, we found a new attribute -that we called Support -to add to the Tool dimension. Indeed, it is useful to characterize different IM approaches by different kinds of used supports, like specific devices, for instance. Based on these findings, we consider that the given comparison framework could be used as a scope for further systematic literature review. Its application will allow identifying possible values for the framework attributes; thus, it will be possible to provide hints of guidance through the IM approach selection and to carry out the detailed comparison of the IM approaches based on statistical analysis. In addition, a cross-referenced analysis will allow us to identify open issues for future research on IM.

This research proposed a framework to classify intention mining works. Inspired by other classification frameworks, our proposal examines IM in four different views, answering the four main questions about IM called dimensions: "What is IM?", "Why IM?", "How is done IM?", and "By which means is done IM?". Each dimension corresponds to a set of classification attributes found in the existing literature. We validated our framework by testing it on five existing and good referenced works and concluded that the given framework would be useful for conducting the systematic literature review on IM. The next step is to complete our systematic literature review on IM, characterizing all our selected papers within this framework in order to provide a detailed overview of the existing IM works and to define open issues.

Ontology-based Intention Mining Approach for Contextual Recommendations

We work on an intention extraction using mining techniques and construction of intentional process models. This topic is the PhD project of Ramona Elali1 [Elali, 2021] [Elali, 2022]. The first objective of this PhD project is to propose a new approach to discover strategies and intentions, their semantic, level of abstraction to construct the intentional process models using the contextual information while relying on the Map formalism. The second objective is to use the obtained models to propose recommendation techniques to guide users of systems while enacting a process based on the discovered intentional process model, on their current traces, and context. Using the discovered process model, the current traces of the user ant the context, the techniques should provide adapted recommendations. Since intentional models are close to human ways of reasoning, we believe that intentional models can provide effective recommendations to users; specifically, if these models were built using the contextual environment. The same user in different contexts will choose different strategies or intentions to achieve his goal.

The main approach comprises two main phases as Figure 3.17. depicts.

• In the Preparation Phase, different sources of logs (log traces, sensor logs, etc.) with their contextual information are collected. Then, an IM algorithm constructs an intentional model. This algorithm will discover the intentions and strategies of the intentional model from the log traces, with the help of the domain ontology. The created model will use MAP formalism. • In the Configuration Phase, the intentional process model built in the previous phase and the current user activity logs together with the contextual information is given as input to the recommendation engine. Then, after processing the input parameters, the recommendation engine will provide a suitable recommendation for the user based on his current activity.

The intermediate results for this PhD project include the work with sensor logs and were detailed in sections 3.2.1. and 3.2.2. The current work focuses on the automatic or semi-automatic construction of an intentional process model.

Configuration

The works around configuration include development of approaches and methods to guide users in intention-and context-based configuration for various applications. Firstly, I work on configuration of methods based on the context and intentions (Section 4.1.). Secondly, I contribute to the configuration of digital components (Section 4.2.). Thirdly, I develop approaches for the organizational entities' configuration using Machine Learning (Section 4.3.).

Context-and Intention-based Configuration of Methods

In the field of situational method engineering (SME), I contributed to a development of the method family approach (Section 4.1.1.). This approach uses a decision-making ontology describing the main concepts related to decisions and formalizing the context of decisions made for the configuration (Section 4.1.2.). Finally, we proposed a method for the configuration of method families based on data about the context and users' intentions (Section 4.1.3.).

Method Family SME Approach

Situational Method Engineering (SME) finds its justification in the practical field analysis which shows that a method is never followed literally [START_REF] Ralyté | Towards a Generic Model for Situational Method Engineering[END_REF]] [Mirbel et al., 2002]. It promotes the idea of using combined method parts, instead of complete methodologies, to specific situations [Ralyté et al., 2001]. However, these approaches are not widely spread in the practitioners' world. The components composition is a quite complicated process as there may exist some overlapping between concepts (which is the rationale behind the integration process of the assembly technique) and no SME approach really offers a simple and easily understandable way to construct a situational method. Furthermore, it is nowadays acknowledged that contextual factors change continuously during the project life cycle imposing a continuous change management. This last feature raises the problem of the dynamic adaptation of methods, which has not been considered by the previous SME approaches [Rolland, 2009].

Method Family Concept

We developed an approach we called "Method Family" [Kornyshova et al., 2011a] [Kornyshova et al., 2011c] [Deneckère et al., 2011c]. Our proposal suggests moving away from this construction of methods "on the fly" to the management of a set of similar components as a whole. We organise these components in method families to manage variability and commonalities in order to promote the reuse and the adaptability of method families. The method family is then configured in a given project in order to obtain an appropriate method line. We think that method families do exist today in companies and could beneficially be handled in an easier manner.

A method family is a composition of method components coming from different methods of the same field. However, belonging to the same scientific field does not represent a sufficient criterion to unify several methods into a family, as such field contains multiple methods of different nature. We postulate that different methods may be federated into a family only if they are characterized by a property that we call "teleological unity" [Kornyshova, 2011]. We introduce this notion in order to clarify the possible characteristics allowing to consider a group of methods as a family.

Teleological unity is defined by the similarity of different methods according to their usage (expressed through associated intentions). This implies that only methods having the same usage and created for the same goals could be integrated into a method family. At the same time, the differences between methods relate essentially to various ways of attaining the given goals. In that way, teleological unity is deduced based on the identification of main goals (or main intentions) of methods to be grouped into a method family. The main goal corresponds to the goal of the higher level of abstraction.

We use the modelling formalism called MAP to capture variability across method families in an intentional manner.

The concept of method family is described with the meta-model of Figure 4.1. (using the UML formalism). The method component concept has the same semantic that in the classic SME methods (a building block, subset of a method), which may contain other components.

Method Family

Method Line

Method

73/158 HDR

A method family is a set of several organized method components for a specific domain. In a method family, some components may be considered either as common or variable as each situation may require specific components. These situations, where it is necessary to choose between several components are called variation point. The relationship between the variation point and the component defines the variability dependency, which can be mandatory or optional (and respectively corresponds to the common and variable method components). A set of variable method components represent the alternatives offered to the engineer at a specific variation point, it is a way to realize variability. This representation of variability was inspired from [START_REF] Pohl | Software Product Line Engineering: Foundations, Principles, and Techniques[END_REF] which discusses the variability of software product lines.

The method component context must be specified. It characterises all possible situations in which this component may be applied. The project context includes all characteristics of the situation at hand, which matches some variable method component contexts. These two context concepts are specified on the same basis as they inherit from the context. This allows a better matching between the situation and the components for the configuration.

A variable method component is selected following the situation at hand (i.e. the project context). The set of these selected method components, together with the common method components, represents a project method line.

A method line is either an initial method (a method already known) or a project method line (defined with our process). The project method line includes the mandatory components and those selected for the given project based on the project characteristics. A method family is composed of a set of method lines. This concept allows regrouping several method lines for a specific domain. Each method line or method family may itself be considered as a method component.

A method family is constructed based on the existing methodologies in a given field and for their further usage in different projects. Figure 4.2. gives an overview of method families and their usage.

The first step is to construct the method family from the existing methods. The next step is to configure the method family in order to obtain a method line adapted to the specific conditions of the project at hand. Finally, the obtained method line is applied in this project. On this basis, we define three following processes:

• Method family definition process;

• Method line configuration process;

• Method line application process.

Method family definition process. This process allows constructing method family from existing methods. Existing methods are decomposed into modular components (like in different SME approaches) and are combined into the same model (i.e. a family). The combination of method components follows two main principles:

• Identification of variation points, common and variable components;

• Identification of components having the same goal and the same target product, but different ways of working.

At this step, the variability is taken into account as common and variable parts are shown. Alternative method components are identified and organized as variants in a given variation point. The difference with the usual SME approaches is that we combine all the components of the same domain in order to obtain a more "generic" method (the family). Method line configuration process. A method line is obtained following the configuration of the family according to various criteria. The configuration approach is detailed in Section 4.1.3.

Method line application process. Once the method line has been created, a final configuration can be applied to obtain the method that will be used in a specific case.

The method family usage aims at constructing a method "on the fly", following the project characteristics. However, as usual SME approaches deal with the construction process itself and its difficulties (integration versus association, for instance), method families offer a way to simplify the work of practitioners with a decomposition of the construction process. The method engineer constructs the method family, but the practitioner just has to configure the method family to obtain a specific method adapted to his needs.

As mentioned before, we use the MAP formalism [START_REF] Rolland | A Multi-Model View of Process Modelling[END_REF] for representing method family and for organizing method components within method families. When dealing with method families modeled by maps, each method component is represented by a map section, as shown in Figure 4.3. This kind of organisation provides the mean for ensuring the variability within method families.

Method Family Configured Method Lines

Applied Method Lines

Illustration of the Method Family Approach.

This concept was applied to different fields: Decision-making (DM) methods [Kornyshova et al., 2011a], Scenario elicitation [Deneckère et al., 2011c], Project Portfolio Management [Kornyshova et al., 2011b], Project planning [Kornyshova et al., 2010b], and Agile projects launching [START_REF] Deneckère | Famille de méthodes : la flexibilité au coeur du processus de construction de méthode[END_REF].

I detail here the MADISE method family for decision-making methods. The MADISE DM Method Family describes the generic DM process including the main activities used for DM. As in the previous section, we have selected the Map formalism for representing the family of DM methods. The DM map is a collection of DM method components organized into a family in order to allow its further configuration according to a given situation. The MADISE DM Method Family modelled with MAP is presented in

By predefined list exploring S8

The DM Map contains four main intentions: Define Alternatives, Define Criteria, Evaluate Alternatives, and Make Decision. The engineer starts the MADISE process by reaching the Define Alternatives intention. At this stage, an alternative set (or alternative family) is generated. The Define Criteria intention is not mandatory. The engineer selects it if he wants to arbitrate between alternatives based on multiple factors. At this stage, a set of criteria for alternatives evaluation is defined, in particular only one criterion. The Evaluate Alternatives intention aims at constructing the evaluation matrix (or decision matrix). At the Make Decision stage, a prescription for a decision is made. A more detailed description of the DM method family could be found in [Kornyshova, 2011].

The usage of the DM Family is characterized by data which are required for starting and finishing the corresponding process. This implies the identification of the Input and Output data. Two kinds of information are required before beginning the use of the DM Map: the decision object and the decision problem which are Input data. The Output data is a decision made according to the identified decision problem. The DM output could also have a NULL value if the decision is not made (for different reasons, such as a lack of information, not valid alternatives etc.). We can consider that the concept of method family allows overcoming the drawbacks of the existing SME approaches. This approach is independent of the knowledge representation as the concept of family may be applied to any component type (fragment, chunk, component and so on). A method family organizes components of the same domain in a way which enables their easier usage as it is already a subset of the potential method components. Then, the method family is configured according to a project needs. It allows avoiding the retrieval step (in several method bases) and composition step (as the method family is already composed of the method components). A method family is based on the separation of common and variable components in each variation point. This facilitates the use of SME approaches in practice. The given approach covers all necessary elements for the contextualisation as it handles project characterisation, component characterisation, and matching component with situation.

Decision-Making Ontology

The decision-making ontology (DMO) [Kornyshova et al., 2010a] [Kornyshova et al., 2012b] supports the method family approach. Decision-Making (DM) knowledge is often represented as a set of basic definitions such as alternatives, criteria, decision matrix, and decision itself. However, this domain is much richer, and many other related notions are useful to make right decisions: preferences, weights, thresholds, and so on. This knowledge must be formalized within a model. In addition, the practical needs for DM as well as the number of research works dealing with DM increasingly grow, for instance, in Information System (IS) Engineering [START_REF] Kou | A Bibliography Analysis of Multi-Criteria Decision Making in Computer Science[END_REF]. Even if the number of research works dealing with DM increasingly grows, a complete DM ontology does not exist. DM becomes widespread in IS engineering field, so it is mandatory to build a shared representation of DM concepts and to show how these concepts are related to DM problems in IS engineering. In addition, a link to method components should be established.

Input:

DMObject

DMO Meta-Model

The starting point for analysing the DM ontology is the DM situation. The DM situation is an abstract concept that puts together the main DM elements and describes a set of specific conditions of DM dealing with a given DM object. The DM object is an artifact being the subject of decision-making.

A given DM situation contains a DM problem and a set of alternatives. A decisional problem characterises the result expected from DM [Roy, 2005]. The problem is characterised by a problem type which can be choice, ranking, classification, or description. The alternative set contains alternatives available in a given DM situation. Each alternative is a possible action offered for decisionmaking.

The DM situation can also contain a set of criteria. It is not mandatory as a decision could be made without analysing criteria. A criterion represents any kind of information that enables the evaluation of alternatives and their comparison. Criteria can have different natures. It can be: (i) intrinsic characteristics of alternatives (the characterizes relationship), (ii) future consequences (impacts that an alternative can have whether it is realized following the made decision) of alternatives depending on the future state (the is(3) relationship), (iii) decision-makers' goals (the is(2) relationship), or (iv) decision-makers themselves (in this case, they have a role of stakeholders according to the is(1) relationship).

The criteria could be analysed in order to know their weights, preference rules, and thresholds. A weight represents the relative importance of a criterion. A preference rule allows to know the wishful value of a criterion according to a given need. A threshold gives the acceptable value for alternative values expressed for a given criterion.

All alternatives are evaluated according to the identified criteria in order to obtain the alternative values. An alternative value represents the evaluation of an alternative according to a criterion. The alternative values can be aggregated in order to produce a unique value by alternative (the aggregates (1) relationship). An alternative value could be defined for two alternatives for instance, when an actor carries out pair wise comparisons between alternatives and gives a preference coefficient for each pair of alternatives (like in the Analytic Hierarchy Process (AHP) [Saaty, 1980]). Each alternative value could be compared to different thresholds (the preference, indifference, or veto thresholds).

Decision-makers (actors contributing to the DM process at its different stages) can participate in DM by several ways. They define the DM problem; have goals and preferences with regard to preference rules, weights and thresholds. They can also become criteria as a particular decision-maker typestakeholder. Decision-makers evaluate alternatives, validate decisions and make intuitive decisions.

Each decision maker is characterized by the type which can be individual or collective. An individual decision maker is a human actor which processes one or more DM steps. A collective decision maker is a group of decision-makers having the same goals and preferences and acting as a unique decisionmaker.

A decision is an act of intellectual effort initiated to satisfy a purpose and allow a judgment about the potential actions set to prescribe a final action. A decision can be intuitive or method-based. Intuitive decisions are made "on the fly" without using a DM method. Method-based decisions are made using different DM methods. Both method-based and intuitive decisions are related to the DM situation.

Each DM situation can lead to either none or several decisions.

The DM ontology is shown in Figure 4.6. It is described in detail in [Kornyshova, 2011].

Illustration with the Selection of an ERP tool

We illustrate the DM ontology using a common example, which is the selection of an ERP (Enterprise Resource Planning) tool to purchase. The application of DMO to the ERP case is illustrated at Figure 4.7. This figure represents an expression of the DM ontology adapted to the given case.

The ERP tool is the DM object, which is a product element.

The problem is a choice of a relevant tool.

Retained alternatives are the SAP ERP, Oracle e-Business Suite, and OpenERP. Alternatives are global as they exclude each other and true as they are all valid for comparing. The firstly identified set of potential ERP tools cannot evolve quickly, thus the alternative set is stable.

Two criteria are considered: purchase cost and maintenance cost. The first one is known directly and constitutes a characteristic of a tool. The second one depends on several factors (for instance, the duration of the tool maintenance) and implies the consequences of the ERP implementation in the future. Weights are not present in our case as two criteria are considered as equal (same importance of two criteria); the preference rule is the minimisation of two costs; a threshold could be established in order to indicate the maximal acceptable cost of the ERP purchase and maintenance.

In the ERP tool purchase case, a value matrix (3  2) will be constituted in order to show the alternative values. By aggregating these values, the two ERP costs will be added for each alternative ERP tool. Thus, each ERP tool will have only one value allowing comparing all ERP tools in an easier way. Based on these aggregated values, a method-based decision will be made. The obtained decision is the selection of an alternative.

In our case, a decision-maker participates in the definition of the DM problem, in the establishment of weights, preference rules, and thresholds. He also validates the final decision. The given decisionmaker is an individual stakeholder.

Decision-Making Method Components

Component.

A DM method component is a reusable building bloc of a DM method that can be used separately. Each DM method component may contain several method components, which, in turn, may also be decomposed in other more simple components.

Actor. Actors participating in DM can have three main roles: stakeholder, IS engineer, and DM staff. A Stakeholder defines the decision problem, sets goals, expresses preferences on alternatives and criteria [START_REF] Baker | Ken Sorenson Guidebook to decision-making methods[END_REF] and validates the final decision. An IS engineer evaluates alternatives and makes a proposal for DM to stakeholders. DM staff is responsible for assisting stakeholders and IS engineers in all stages of the DM process [START_REF] Baker | Ken Sorenson Guidebook to decision-making methods[END_REF]. DM staff includes a machine support for DM. In this case, this is a system actor. If actors are human, we call them decision-makers. Decisionmakers have the same roles as actors but have a complementary property, which is their type: individual or collective. A collective decision-maker is a group of decision-makers having the same goals and preferences and acting as a unique actor. Actors contribute to the DM process at different stages.

It is obvious that the same actor can play different roles in a specific DM process. Intention. This concept describes goals that actors have within the DM process. It is represented as a taxonomy. The main intention is to find a solution of a problem having a DM nature. This intention is decomposed into more detailed ones, for instance, define alternatives, define relative importance of criteria, and so on.

Concept. Concepts are objects used in DM, for instance, the DM problem (choice, ranking, classification), alternative, criterion, and so on. The DM concepts and their relationships are complex.

We have organized them into an ontology of DM concepts, which is described is details in the following sub-section.

Activity. The activity concept describes elementary actions used for making decisions. The activity taxonomy contains activities (enumerate alternatives, calculate a weighted sum, calculate an aggregate value etc.) and the possible relationships between them: composition, precedence and parallel execution. to intentions in order to show for which reason they are used in a DM process (is_used_for and aims_at relationships). They are also related to a context in order to indicate the conditions in which they can be used (is_used_in and is_available_in relationships). A combination of intentions, concepts and activities (composition link between component and intention, concept, and activity) represents a component, as each component contains methodological information about its application. Components are related to a context in order to indicate the characteristics of the situation in which they can be applied (is_applied_in relationship). The context is defined by involved actors (defines relationship).

Illustration of DM Components with the REDEPEND Approach

Our goal is to show how existing DM models could be expressed through the DM ontology. We have chosen an existing and well-known DM method dealing with requirements engineering: the REDEPEND approach [START_REF] Maiden | Integrating Decision-Making Techniques into Requirements Engineering[END_REF]. We capture its DM model and express it through DMO, i.e. DMO concepts, attributes and relationships are used in order to represent the REDEPEND approach.

The REDEPEND approach uses requirements for selecting candidate tasks, which represent possible alternatives. It is based on the AHP (Analytic Hierarchy Process) DM method. The AHP, proposed by T.L. Saaty [Saaty, 1980], includes pair-wise comparison between alternatives and/or criteria and aggregation of the comparison results into quantitative indicators (score). The REDEPEND approach integrates the AHP and i*, which is a well-known requirement modelling formalism. The DM situation in this approach is characterized as follows. The DM problem is ranking. The DM object is a task, which can be a scenario (process element) or a goal (product element). Tasks represent alternatives, which are fragmented, i.e. they can be dependent one another. All alternatives are true as the REDEPEND approach does not contain a module for validating them. The alternative set is evolving as it can change through time. One or more decision-makers (individual stakeholders) define goals and soft goals. Goals and soft goals represent requirements and are considered as criteria in the given model. These goals are determinist; their measure scale is nominative; the data type is qualitative; and they are valid.

Decision-makers make pair-wise comparisons of tasks and goals. In this way, they express preferences on weights and alternatives values (concerns relationships). For instance, they compare each pair of alternatives according to a criterion and give a numeric value to it. A value can vary from 1 (equal importance) to 9 (absolute importance) in accordance with the basic AHP method. This constitutes the elementary alternative value. These values for all alternatives are then aggregated in order to rank the alternatives against the given criterion (aggregates relationship). The same analysis is made between alternatives for each criterion and between criteria in order to prioritize them too (class weight and relationship aggregates respectively). The ranked alternatives and criteria are computed for the final alternatives' ranking in order to make decision (is_based_on relationship). The main goal of DMO is to represent concepts of the DM domain, as well as their properties and relations. The DM ontology fulfils the following needs: to clarify and organize DM concepts; to build a shared representation of DM concepts between researchers and practitioners; to show how these concepts are related to DM problems in IS engineering; to make DM knowledge reusable in similar IS engineering situations; to compare existing DM models in order to select an appropriate one; to validate the completeness of existing DM models; and to support the creation of new DM models. Our proposal is original as it is the first attempt to unify the most important DM concepts within a unique model. DMO could be used in different manners. In our approach, the main usage of the DM ontology is twofold: (i) to clarify DM concepts for formalizing DM situations and specifying DM requirements and (ii) to specify DM method components.

Configuration based on Multicriteria DM Methods and Graph Theory

The configuration approach allows to take into account the context and users' intentions to provide a recommendation to constitute a personalised method adapted to a given situation. We use multicriteria decision-making methods and the graph theory [Kornyshova, 2011] [Deneckère et al., 2009] [Deneckère et al., 2010b].

Configuration Process

The method family configuration process is an intention-oriented process that we represent with the Map model. The method family configuration map is given in Figure 4.12. This map shows the main intentions belonging to the process of the method family configuration: Define Method Requirements and Construct an Application Method.

By problem exploring By sub-set selection

Step-by-step strategy

By complete application method selection

Tool-based strategy By expertise

By completeness

By application By integration

Stop

Start

Define Method Requirements

Construct an Application Method

By existing method analysis

By single indicator

By multiple indicators

During the Define Method Requirements stage, a set of requirements for configuring a method family is defined. The requirements to identify must allow selecting the appropriate method components and constructing an application method. Thus, these requirements have to be sufficient to carry out the configuration process realized at the next stage (the Construct an application method intention). A method family is formalized in the intention-oriented manner using the map model. This kind of modelling offers the possibility to identify the intentions and situations associated to all components. Based on the intentions, the engineer can define if a method component is suitable for his goals; and the situation is used for identifying the input of each component. In addition, our vision of the map model enhanced with the notion of indicator allows to access to the context associated to each component. In this manner, at this stage the engineer defines a set of elements which are essential for the further configuration of the method family into an application method. The elements to specify at this stage are the intention, situation, and the values of the context indicators.

Two possible strategies to attain this intention are available: by problem exploring and by existing method analysis.

• By problem exploring. The engineer begins from zero when he does not have any methodological guideline for the given field.

• By existing method analysis. In this case, a method for a given field exists but must be improved. This strategy allows analysing existing methodological elements and to complete them.

Once the method requirements are defined the proper method family configuration could be started.

The Construct an Application Method step is to use the identified requirements for the guidance. Three kinds of configuring method families are combined with the usage of one or multiple indicators during the configuration.

Three kinds of configuration we suggest are:

• Step by step strategy guides each of the engineer steps, one by one, to use a method family.

In this case, the sub-set of method components (available at the given step) is considered. For instance, the engineer must select between two different strategies allowing to attain the same intention. • By sub-set selection strategy uses the indicator(s) to simplify the method family by deleting some components. This kind of configuration allows to select a sub-set of alternatives from A based of the values of criteria in a given project. For instance, it can be a selection of method components requiring a low expertise degree. • By complete application method selection strategy helps to select, right from the start of the navigation, between all the possible application methods (or method lines). The first step is to measure the indicator values for each method line based on values associated to method components which compose this line. Therefore, the alternatives are method lines and criteria are aggregated values. For instance, all method components may be measured according to the duration criteria. First, the duration of all possible method lines is calculated (as a sum of its components duration). Then, a method line having the lowest duration is selected.

Moreover, for each of these three kinds of guidance, there is also two separate ways to proceed which are the use of a single indicator or of multiple indicators, as illustrated at The engineer must identify two elements to choose the right guidance. First, he determines his needs: to choose appropriate components, to find an optimal method line, or to carry out a dynamic choice of components. Second, he looks at the number of available indicators and chooses one or several of them. Depending on these choices, he can then select a guidance type adapted to his project case.

• By Completeness. Once the first configuration is carried out, the obtained application method must be checked according to its completeness (By completeness strategy). The composite component (an application method) issue from the configuration process is compared with the original method family. As this family is represented with a map, the method components, pre-selected during the configuration, are positioned into the map of the method family. For this, the following steps are executed one by one: o Organize the pre-selected method components within an application method; o Identify method components which are missing in the obtained application method and, consequently could be added to the application method in order to complete it; o Identify method components which are concurrent to each other in the obtained application method; o If necessarily, arbitrate between two or more method components using the context characteristics.

Therefore, the usage of the map model allows assembling the selected components, adding other components if it is necessary for completing the application method, or eliminating excessive ones.

This strategy is not applicable when the configuration is made using the step-by-step strategy as this one allows constructing a complete and coherent application method.

The method family configuration process is stopped (the Stop the configuration process phase) from two points: from the Define Method Requirements intention and from the Construct an Application Method intention depending on the manner to use the methodological knowledge for executing a process (or a set of activities) for which the method family is elaborated.

In the first case, the engineer does not realize the configuration of the method family as he knows well the given method field and can attain the main intention by using its expertise or he uses a tool available for this field.

Single Indicator Multiple Indicators

Step • By expertise. The By expertise strategy is applied when an actor does not need an additional methodological assistance and uses his expertise and experience for executing the processes related to the given method family. • Tool-based strategy. This strategy is used when the engineer has a tool allowing to execute the processes of the given methodological field.

In the second case, the engineer uses the configured application method in order to execute the given activities. He can do it by applying the obtained application method or by integrating it with the existing methodologies.

• By application. Using this strategy, the engineer directly applies the obtained method without integrating it with an existing methodology.

• By integration. The By integration strategy is used when the engineer wants to integrate the configured application method with an IS engineering process. For this purpose, he can use one of the SME approaches allowing the method components integration [START_REF] Ralyté | Towards a Generic Model for Situational Method Engineering[END_REF], for instance, the By assembly and By extension techniques.

In the following sub-sections, I give some illustrations of the method configuration. In addition, we applied the same guidance to configure process lines [Deneckère et al., 2010b] (not detailed in this work).

Illustration of the Configuration Process

We use an example from the Requirement Engineering (RE) field dealing with the elicitation of use cases in order to illustrate different possibilities of the method family configuration (Step by step, By sub-set selection, and By complete application method selection strategies).

The example is the Crews-L'écritoire approach described in [Ralyté et al., 1999]. The corresponding map is given in Figure 4.14. The L'Ecritoire method provides guidelines to discover functional system requirements expressed as goals and to conceptualize these requirements as scenarios describing how the system satisfies the achievement of these goals. This map contains three main intentions, namely "Elicit a Goal All components have all the same value for the Expert Role ('Analyst'). Two indicators (Expertise degree and Formality degree) have quantitative values between 1 and 3. For instance, if the value of Expertise degree is 1, it means that the engineer doesn't have to be an expert to use this component (as for in free prose). On the contrary, to use the Goal structure driven strategy will requires a high level of expertise as the goal has to be formalized in detail, so the value is 3. The Relationship degree and Complexity degree indicators have a qualitative value equal either at Low, Medium or High. The Duration values are expressed in minutes and are impacted by the Expertise degree value. For instance, the component S1 will be realized in 15 minutes if the Expertise degree is equal to 1. If this indicator has a bigger value, the length of time used to realize the section will be shorter.

Thus, these values are defined at the contextualisation step. The next step is to use these values for the configuration. In the following sub-sections, we illustrate three main configuration techniques applied to the Crews-L'écritoire method. Each technique is illustrated with one and multiple indicators used for configuration.

Step-by-Step Configuration

The usual way to use a map is to dynamically choose the method components to execute one by one.

Step-by-Step Configuration with Single Indicator. The engineer may use a specific indicator particularly relevant to its project, to help him to make his choice. First step is to select an indicator; the second is to determine the preference rule about it.

For instance, the navigation through the Map leads the engineer to execute the component S3. Five possibilities are offered to the engineer to continue the navigation. He may execute one of the three components which have the same target intention (S2, S3, S4) or he may go further in the Map to the intention Write a Scenario with the execution of the components S5 or S6. If its predefined indicator is the Duration with a preference to a lowest value, he will choose the component S6 which has the lowest value.

Step-by-Step Configuration with Multiple Indicators. The engineer may also use an aggregated value of several indicators (aggregation of the alternatives evaluations into a unique indicator, following a specific MC method). In this guidance, the first step is to select several indicators; the second is to aggregate values; and the third is to determine the preference rule about the results.

Within the preceding example, the navigation has led the engineer to execute the component S3. He can now execute S2, S3, S4, S5 and S6. He chooses three indicators: Duration, Formality degree and Expertise degree with a preference to a lowest final value. The normalized and aggregated values are described in Table 4.2. Between these five components, the one that has the lowest value is the component S6.

By Sub-set Selection

This strategy is applied when the goal is to eliminate components, which are not appropriated for the given indicator values.

Components Sub-set Selection with Single Indicator. It is applied when only one indicator is available.

The engineer has to define the needed value of this indicator in order to select an adapted sub-set of components.

If, for instance, the engineer is a beginner, the Expertise Degree indicator must have a value equal to 1 (low). Using this approach allows to delete all the components which are too difficult for the user. The components sub-set of the CL Map is then composed of the following components: S1, S4, S6, S8, S9, S10, S11, and S12. An engineer with a low level of expertise may execute all these components.

Components Sub-set with Multiple Indicators. This guidance has the same goal as the previous one but uses an aggregated value of several indicators following an MC method. Several functions may be applied (sum, maximum, minimum, average, weighted sum).

For instance, the engineer selects the Expertise degree and the Formality degree as the two more important indicators and he wants to minimize their values. As aggregation rule, the engineer chooses to calculate the average value. The indicators do not have a value for all the components. In order to obtain an aggregated value, we consider that a null value is equal to the lowest value of the indicator (see italic values in Table 4.3.). For instance, if the value of the Expertise Degree is not specified for a component, we assume that any engineer may execute it and we affect the value 1 to this indicator.

Once the aggregated values have been defined, the engineer defines the maximal average value that he could accept (here 1,5). The final components sub-set includes: S1, S4, S6, S7, S9, S10, S11, and S12.

1 3 3 1 3 1 1 3 1 1 1 1 Expertise degree 1 3 2 1 3 1 2 1 1 1 1 1 Aggregated value 1 3 2,5 1 3 1 1,5 2 1 1 1 1
It is interesting to note that the only difference between this sub-set and the sub-set from the previous section is the component S8 replaced by the component S7 between the intentions Write a Scenario and Conceptualize a Scenario. The adjunction of the Formality degree to the Expertise degree has only this little impact.

By Complete Application Method Selection

In order to apply this configuration technique, we suggest using the graph theory. This example is detailed in sub-section 4.1.3.5. after the explanation of the MAP/Graph correspondence (sub-section 4.1.3.3.).

Representing Method Families using the Graph Theory

A method family modelled with map could be represented as a graph [START_REF] Deneckère | Enhancing the Guidance of the Intentional Model MAP: Graph Theory Application[END_REF]. Thus, we can use the graph algorithms for configuring method families. Our aim is to enhance the guidance mechanisms of the map execution by reusing graph algorithms. This will offer a process execution associated to the map with a control of the map navigation.

The Graph theory offers a lot of techniques to be used on graphs. For instance, the shortest path problem is the problem of finding a path between two vertices such that the sum of the weights of its constituent edges is minimized. On a valuated map (that we have introduced before), it may be useful to find a path through the map which will satisfy some requirements of the IS engineer (on time, cost and so on). The execution of the map will then be more flexible as the engineer will have the possibility to change the weight values of the map sections following the project at hand.

In addition, there is confusion between maps and graphs. Of course, the maps are visually constructed as graph but their use is completely different. People who never studied the MAP model don't understand these differences, which are semantically based on the two different levels used: the intentional level of the MAP model and the operational level of the graphs. Consequently, our aim is to propose a possible mapping between maps and graphs in order to use all the graphs techniques already defined in the literature.

Graph theory was born to study problems such as how to visit some places only once on a walk [Euler, 1736]. In mathematics and computer science, graph theory is the study of graphs: mathematical structures used to model pairwise relations between objects from a certain collection. Graphs are represented graphically by drawing a dot for every vertex, and drawing an arc between two vertices if they are connected by an edge. If the graph is directed, the direction is indicated by drawing an arrow, as shown in Figure 4.16.

A graph can be thought of as G=(V,E), where V and E are disjoint finite sets. We call V the vertex set and E the edge set of G [Berge, 1985]. A walk is an alternating sequence of vertices and edges. An example of a walk is given on the preceding figure as this graph offers three different walks to go from the vertex 1 to vertex 4 (either directly or going through vertex 2 or through vertex 3). There is a distinction in graph theory between a path and a walk as a path is a walk with no repeated vertices. A walk begins with an initial vertex and ends with a final vertex. A multigraph or pseudograph is a graph which is permitted to have multiple edges, (also called "parallel edges"), that is, edges that have the same end nodes. Thus, two vertices may be connected by more than one edge. Cycles are allowed in these graphs. A cycle is a path which ends at the vertex where it began. A weighted graph associates a label (weight) with every edge in the graph.

Transformation from map to graph is shown in Figure 4.17.

Each map corresponds to a graph (A). Each section of the map will then be transformed into graph vertices (B) and each identified section sequence will be shown as edges on the graph (C).

Finally, we may identify the correspondence between MAP indicator and graph weight (D). The section weights must then be evaluated in a single indicator that can be applied on the graph edges. The valuations of the graph edges are obtained based on aggregated values of sections: the section weight becomes the same valuation on all entering edges for a given section on the graph. We assume that each section has the same value independently of the previously realized section.

The MAP model allows refining a section with another map. This abstraction level is kept with the graphs as a node may also be refined as another graph.

These correspondences are summed up in Table 4.4. The thread is the possibility to attain a target intention from a source intention with several strategies. In a graph, the representation of this set of sections will be the set of vertices having two specific edges, the one shares the same start-vertex and the other the same end-vertex.

} W 1-4 ={(1,4), (1,2-2,4), (1,3-3,4)} Elena Kornyshova 1,2), (1,3), (1,4), (2,4),(3,4)

91/158 HDR

Bundle Set of adjacent vertices

The thread is the possibility to attain a target intention from a source intention with several strategies but with an exclusive OR which means that only one of these sections may be used in the complete navigation. The representation on the graph is the same than for the thread.

Once a map is expressed through a graph, the algorithms of the graph theory could be applied for configuration.

An example of the map expression with graphs describing the construction process of an O* model is given in [START_REF] Deneckère | Enhancing the Guidance of the Intentional Model MAP: Graph Theory Application[END_REF]. In order to illustrate our proposal, we have chosen a map describing the construction process of an O* model [Rolland, 2005] (Figure 4.18.). There are two different ways to initiate the construction of an O* model. On the one hand, the engineer may identify the classes of the model (by initial identification, by composition, by inheritance, by reference...) with the Class driven strategy (section IAG1). On the other hand, he/she may also choose to construct the model by the identification of events (by initial identification, by top-down or bottom-up strategy...) with the Event driven strategy (section IAG4).

These two sections are refined by the execution of two strategic guidelines which are themselves represented as maps. For instance, the following figure ( When a class has been constructed, the engineer may then expand it, with the Class/event coupling strategy (section IAG2) or by the identification of related events -either the events that trigger operations of this class or a possible internal event (an event which is triggered by a specific modification of a class state). In the same way, the Event/Class coupling strategy (section IAG5) allows the engineer to identify related classes (either the class impacted by the operations triggered by the event or a class from which a state modification has triggered this particular event). These two sections also are refined by two other maps.

The completeness strategy allows the engineer to end the process with a verification of the obtained product model, either after having created a class (section IAG3) or an event (section IAG6). Note that the completeness will be obtained only if there has been a coupling of these concepts. The engineer will then not have the possibility to end the map without coupling the created events to the created indicators this is a sum and for qualitative indicators it can be a given value from the predefined set as [ENUM]).

For instance, the engineer decides to select a path, which minimizes time for executing the CL Map. He applies the graph theory algorithm for searching the Shortest path following the indicator Duration. The Duration values for all components of the map are indicated in Table III.4.3. Recall that in this example, the Expertise degree indicator impacts the Duration (an engineer with a low level of expertise will execute the component in more time than if he was an expert). The Duration values are given in the case when the Expertise degree is low. The possible paths set may be quite big as the Map contains cycles, iterations and back paths. To simplify our example, only the four shortest paths (which do not contain any cycle or iteration) are retained:

• Path 1: {S1, S5, S7, S12} = 15 mn+10 mn +10 mn +5 mn = 40 mn;

• Path 2: {S1, S5, S8, S12} = 15 mn +10 mn +15 mn +5 mn = 45 mn;

• Path 3: {S1, S6, S7, S12} = 15 mn +5 mn +10 mn +5 mn = 35 mn;

• Path 4: {S1, S6, S8, S12} = 15 mn +5 mn +15 mn +5 mn = 40 mn.

The shortest path is the Path 3 as it is the one which will be the quicker to execute.

Graph theory algorithms by Multiple Indicators. The Graph theory algorithms may also be used with multiple indicators. Instead of using only one of them to select the better path, several indicators values are aggregated together in order to obtain a single value for each section. Then, these values are used to select the optimal Map path like in the previous guidance. Several functions may be applied (sum, maximum, minimum, average, weighted sum) for aggregating indicators values.

In our example, the engineer selects three indicators: Duration, Formality degree, and Expertise degree, which are quantitative and have different measure scales. In order to obtain compatible scales for comparing them, normalisation must be applied. In this case, the normalisation is calculated as a percentage of the maximal value for each indicator. For this, the Duration values [5; 20], Formality degree, and Expertise degree values (ENUM:1, 2, 3) are reduced to the same scale [0; 1]. The normalized values are presented in the Table 4.6.

1 3 3 1 3 1 1 3 1 1 1 1 Expertise degree 1 3 2 1 3 1 2 1 1 1 1 1

Normalized values

Duration degree 0,75 0,5 0,75 0,75 0,5 0,25 0,5 0,75 1 1 1 0,25 Formality degree 0,33 1 1 0,33 1 0,33 0,33 1 0,33 0,33 0,33 0,33 Expertise degree 0,33 1 0,67 0,33 1 0,33 0,67 0,33 0,33 0,33 0,33 0,33 Aggregated Value 1,41 2,5 2,42 1,41 2,5 0,91 1,5 2,08 1,66 1,66 1,66 0,91

The engineer wants to minimize Duration, formality, and expertise degrees, so he chooses the shortest path. The function used on the aggregated values is the sum.

• Path 1: {S1, S5, S7, S12} = 1,41 + 2,5 + 1,5 + 0,91 = 6,32

• Path 2: {S1, S5, S8, S12} = 1,41 + 2,5 + 2,08 + 0,91 = 6,90

• Path 3: {S1, S6, S7, S12} = 1,41 + 0,91 + 1,5 + 0,91 = 4,73

• Path 4: {S1, S6, S8, S12} = 1,41 + 0,91 + 2,08 + 0,91 = 5,31

Elena Kornyshova

97/158 HDR

The shortest path taking into account the three selected indicators is the Path 3.

Configuration of Digital Components

This axis includes the configuration of I4.0 components depending on users and organizational intentions (Section 4.2.1.). In addition, I study the impact of Industry 4.0 on Enterprise Architecture (EA) and I contributed to an approach of the integration of I4.0 components into EA models (Section 4.2.2.).

Intention-based Configuration of Industry 4.0 Components

This topic is the PhD project of Kaoutar Sadouki2 . We are working on the elaboration of the intentionoriented approach for I4.0 components configuration [Sadouki, 2022a] [Sadouki, 2022b]. The new industrial revolution, ICT-backed automated and interconnected Industry 4.0, powered by the Industrial Internet of Things (IIoT), Cyber-Physical Systems (CPS), and various sensors, provides interconnected manufacturing systems capable of communicating, analysing, and driving further intelligent production in the physical world. Together with the recent advances in machine learning, and Artificial Intelligence (AI), I4.0 allows new opportunities for business development [START_REF] Kasakow | Realising Digital Connectivity by Using Interdependencies within a Production Process[END_REF]. However, the successful adoption of these emerging technologies is not obvious, as it requires tools and skills to make the vision of I4.0 a reality.

There is a lack of alignment of I4.0 ICTs to business strategies and business intentions. In most cases, intentions are neglected, whereas this is a type of data that can clarify the requirements of business strategies while taking into consideration the internal and external users of I4.0 applications. Therefore, the research goal is to investigate and conceptualise intentions in the industrial area to provide an intention-based approach to facilitate the use and configuration of available ICT components. Organisations would be able to adapt and stick, as quickly as possible, to changing business needs and to the requirements of digital transformation.

The current research contribution in this field includes state-of-the-art on intention-based approaches (IBA) in the industry (an ongoing work).

State-of-the-Art on Intention-based Approaches in the Industry (ongoing)

We use the Systematic Mapping Study (SMS) method [START_REF] Petersen | Systematic mapping studies in software engineering[END_REF] to provide insights on the existing intention-based approaches in the context of Industry 4.0. SMS gives an overview of a research area by setting categories and counting existing works, then classifying the existing works into the founded categories [Kitchenham et al., 2007]. We develop a comparison framework as a classification scheme for our literature review. This framework contains three main IBA dimensions: object dimension (intention definition, levels or sub-intention, intention taxonomy, intention formalisation), technology dimension (algorithm type, used technology, support), and usage dimension (usage goal, sub-domain of I4.0, targeted level of abstraction, activity sector). We characterised the scientific papers included in the SMS according to this classification scheme.

We have chosen three scientific databases, Dimensions, Web of Science, and Scopus because they are large multidisciplinary databases covering published material in the sciences and provide citation analysis of authors and subject areas. We have used criteria to find relevant papers for our project. Based on the state-of-the-art, the next step will be establishing a formalism to describe intentions in the context of the industry so that it can be compatible with the existing Industry 4.0 frameworks. Then we will study how to adapt/enrich the description of Industry 4.0 components as they are defined in the RAMI4.0 framework [RAMI4.0, 2020]. Finally, based on the intention description, we will develop an approach for the intention-based configuration [Sadouki, 2022a] [Sadouki, 2022b] using SMEinspired methods [Kornyshova et al., 2011a].

Integration of Industry 4.0 Components into Enterprise Architecture

At the organisational level, we studied how the I4.0 components could be integrated in the existing Enterprise Architecture (EA). We developed an approach of I4.0 impact propagation on EA models [Kornyshova et al., 2020] [Kornyshova et al., 2019]. We established a propagation model and the associated process to help enterprise architects. To complete this study, we established a situational approach applied to the Enterprise Architecture framework TOGAF [Kornyshova et al., 2022c].

Industry 4.0 Impact Propagation Model

To face the digitalisation challenges, managers should know and control the current and potential capacities of the whole organisation. Correspondingly, to ensure change implementation agility, managers need to have models of the current and potential IT platforms and business processes capacities, along with the degree of organisational flexibility to implement the required changes. In this context, Enterprise Architecture models are valuable management and technical tools because they describe organisations from complementary viewpoints: Business, Information Systems (including software applications and data) and their Technology platform [START_REF] Schwarz | Towards Comparable Business Model Concepts: Resource Description Framework (RDF) Schemas for Semantic Business Model Representations[END_REF], [Wieringa, 2019]. These models represent the main enterprise elements from business goals and strategies to technical production platforms passing through business and production processes, enterprise actors and their roles, information systems and their IT support platform [START_REF] Antunes | Using ontologies for enterprise architecture model alignment[END_REF], [Neto Granjo, 2014]. Our goal is to specify how companies with established enterprise architectures can include components from Industry 4.0 by progressive adaptation of the existing EA.

During the digital transformation, the main challenge is to define how the new I4.0 component could be introduced into the existing architecture based on the knowledge stocked in EA models. In addition, the existing I4.0 models describe the main industry elements at operational and production levels [Petrasch et al., 2010], including the product life cycle [START_REF] Alcacer | [END_REF], without detailing how it could impact decisions at the managerial level. The gap between EA and digital components should be reduced. Our proposal is to establish a propagation model to identify, at the model level, which elements of the existing architecture could be impacted by a new I4.0 component and how this impact is propagated through the rest of the architecture [START_REF] Kornyshova | Exploring the Impact produced by the Industry 4.0 on Enterprise Architecture Models[END_REF]] [Kornyshova et al., 2020].

The core of EA approaches is represented by conceptual models, reflecting enterprise elements at different levels: business processes, data, applications, and IT models. Conceptual links should be established in order to highlight possible relationships between an introduced I4.0 component and the corresponding elements of the EA models. By means of these established relationships, it will be feasible to identify all the impacted existing EA elements already included in EA models. As the impacted EA model elements are identified in a progressive manner following connections existing within the set of EA models, we call it a Propagation Model, and we represent it using the UML class diagram depicted in Figure 4.22. The propagation model is composed of the following elements:

Perspective. The EA models are grouped into perspectives described by their names. The perspectives list depends on the selected EA framework. For instance, the TOGAF EA framework [START_REF] Togaf | The Open Group Architecture Framework[END_REF] includes the Business, Information Systems (Application and Data), and Technology perspectives called Architectures. Each EA model belongs to a perspective (the corresponds_to association). However, in a concrete organisation, a perspective could not be implemented.

EA Model. An EA model groups different model elements of the same type. EA models could be business process models, data models, applications models, technology models, and so on. An EA model (characterised by a name) is a composition of EA model elements (the composition link on the EA model class in the propagation model).

Model Element. A model element represents each single enterprise element included as part of any of the EA models. It could represent a process, an object, an actor, a system, or a technological enterprise component. Each model element has at least a name. Other characteristics depend on the model type. Relationship. Model elements are related to each other. Possible relationship types are a simple association, an aggregation, a composition, or a generalisation. We use here the basic relationships type from UML [START_REF] Uml | Unified Modeling Language[END_REF], but this list is not exhaustive; it could be completed with others like sequence or exclusivity link. Each relationship has a name to characterise its nature. Inspired from [Barrios, 2001], the effect caused on model elements could be: introduce new element, update element, maintain element, or drop element. Introduce new element means that a new EA element should be added following the introduction of an I4.0 component. Update element implies that the corresponding EA element ought to be revised in order to extend or modify some of its attributes, functionalities and/or its interactions with other elements. A maintained EA element remains the same (no impact). An EA element can be dropped if it is not required anymore after the introduction of an I4.0 component.

Process of the Industry 4.0 Impact Propagation Model Application

To respect the artefacts' design principles [START_REF] Hevner | Design Science in Information Systems Research. In: Information Systems Research[END_REF] and to produce better guidelines while applying the propagation model through the whole set of the EA models within an organisation, we suggest using the process presented in Figure 4.23.

Identify the indirect impact(s).

Using the relationships between different model elements, deduce the related impacted elements and associate the corresponding impact effect.

Group the identified impacts by EA model. Put together the identified impact within the corresponding EA model and check consistency within each model (verify the presence of contradictory or double impacts within the same EA model and arbitrate).

Group the impacted EA models by perspective. Gather the impacted EA models within the corresponding EA perspective and check the consistency (verify the presence of contradictory or similar modifications within the same EA perspective and arbitrate). This step produces the final document containing the identified I4.0 impact.

Application to TOGAF 9.2

We selected The Open Group Architecture Framework (TOGAF) 9.2 [TOGAF, 2020] in its new version as one of the most known EA frameworks. TOGAF is an Open framework; thus, it is accessed easily. We reviewed its full content meta-model (cf. [TOGAF, 2020], p. 287) to check whether the EA model elements are clearly identified. Firstly, we established a list of potential impact points (IP) using the RAMI4.0 framework. Based on the comparison of the TOGAF and RAMI4.0 structures, we have identified different EA models´ components which could be potentially impacted by the introduction of an I4.0 component: the main conceptual element of the RAMI4.0 model (Table 4.7.). Identifying a potential impact point of the I4.0 component over an EA component means that any kind of change may alter current enterprise model elements. Thus, an IP mark indicates that, while defining the EA To-Be model, the EA leader should pay special attention to each enterprise model component that may be somehow impacted by including new I4.0 components. That is, the IS and Technology Architectures will be directly affected by an enterprise I4.0 evolution because I4.0 components must be explicitly included as part of these architecture models; consequently, the impact over current EA components, their change options and gaps must be carefully analysed by project leaders before taking decisions. Besides, current architecture principles, vision and requirements must also be redefined and adjusted according to I4.0 principles and enterprise transformation needs.

The TOGAF 9.2 content meta-model "provides a definition of all the types of building blocks that may exist within an architecture, show how these building blocks can be described and related to one another" [TOGAF, 2020]; thus, it contains all EA entities (corresponding to model elements from the propagation model) and the relationships between them. We applied the propagation process step by step by carrying out a detailed analysis of all meta-model elements and their relationships (based on the meta-model from p. 287 of TOGAF 9.2 and its detailed description given on pages 301-303 and 314-317 of TOGAF 9.2 [TOGAF, 2020]). Finally, we analysed the obtained result to state the completeness of the proposal.

Identify direct impacts. We checked all TOGAF 9.2 meta-model entities (cf. Section 30.5 of TOGAF 9.2 [TOGAF, 2020], pages 301-303) to select the most complete list of entities which could be impacted directly by an I4.0 component and qualify them as direct impacts. The inclusion criteria are (i) the TOGAF entity is an independent atomic component, (ii) it could be easily replaced by a new component of I4.0, (iii) it encapsulates a chunk of an application, data, or infrastructure. For instance, we have included the Physical Technology Component as it is "a specific technology infrastructure product or technology infrastructure product instance" [TOGAF, 2020] as a Commercial Off-The-Shelf (COTS) solution. We have excluded the Physical Data Component ("a boundary zone that encapsulates related data entities to form a physical location to be held" [TOGAF, 2020]) as it represents a sub-set of data entities; thus, it does not correspond to an independent component easily replaceable. Another example of exclusion is the Logical Application Component which is "an encapsulation of application functionality that is independent of a particular implementation" [TOGAF, 2020]: as it is not implemented, it could not be replaced by an I4.0 component. The strategy used was to take each TOGAF entity and check it with regard to the established criteria. The list of the identified direct impacts comprises seven [START_REF]4 Supervision of Students' Works (a Selection[END_REF] ). This step corresponds to the simple identification of the corresponding EA model from the TOGAF documentation. The consistency could be checked only in a case of a concrete project.

Group the impacted EA models by perspective. Identified impacted TOGAF Models were grouped into perspectives (also shown in Table 4.8.). This step includes the identification of EA perspectives from the TOGAF documentation. As for the previous step, the consistency could be checked in a given case.

Based on the application of the propagation approach to TOGAF 9.2, we have obtained the following evaluation results:

• The concepts of the propagation model (EA Element, I4.0 Component, Relationship classes, and Impact association class) are sufficient to represent links between an introduced I4.0 component and directly and indirectly impacted EA elements. This model proposes a quite simple but concise way to trace the I4.0 impact. • Globally, the initial propagation model was not sufficient as we did not include the EA perspective as a class. Based on the first iteration of the application process, we noticed that it is important to have this additional aggregation level to check the global consistency, at least for the EA frameworks containing this granularity level as TOGAF 9.2. But it could be optional, especially for small and medium organisations. As a result, the class EA perspective was added. • With regards to the application process, we confirmed that it is useful to have main steps guiding in the propagation model application, In addition, we stated that the first two steps could be applied to the EA framework, but the third and fourth steps could be completely checked only in a given project of the I4.0 component introduction into EA models. • Finally, we noticed as the major limitation of our proposal, that the feasibility of our approach depends on the solid knowledge about EA concepts and related technology that EA leaders and practitioners ought to have in order to apply it well in real EA projects. Further, this background and expertise are essential to take advantage of the results attained after the application of the propagation model.

Overall, the evaluation of our proposal by applying it to TOGAF 9.2 allowed us to complete the propagation model, confirm its utility, and identify its limitations.

al., 2013], [START_REF] Lapalme | Exploring the future of enterprise architecture: A Zachman perspective[END_REF], [START_REF] Togaf | The Open Group Architecture Framework[END_REF]. The proposal application's outcome is identifying the set of EA models and their elements that should be revised and adapted after the inclusion of new I4.0 components. In order to ensure that the proposition is complete and viable, we examine it, as a general strategy, through the TOGAF 9.2 meta-model. This validation process was based on the detailed analysis of each meta-model concept and the relationships between models. Initially, we identified the direct impacts caused by I4.0 components over TOGAF meta-model entities; then, we determined those entities that may be impacted as a result of their relationships and dependencies, with those entities already identified as directly impacted entities. The obtained results will provide EA leaders and practitioners with practical guidelines and EA researchers with a theoretical propagation model along with its associated application process. EA practitioners can use the proposal to optimize the existing EA models and make them up to date regarding digital evolution. Theoretically, the propagation model will serve as a building block for approaches of Enterprise Architecture 4.0 and their related conceptual models.

Organizational Entities Configuration using Machine Learning

I am working on configuration of digital business ecosystems (DBE). The rapid growth of the number of these organisations accentuates the complexity of finding economic partners, customers, suppliers, or other organisations that can share economic interests. In our research, we propose a recommendation system to find best partners, products, services, etc. depending on the context characteristics and users' intentions, using supervised machine learning algorithms (Section 4.3.1.). In addition, the configuration in DBE is better when entities and/or devices and their data are trustworthy. We explore a decentralised approach using a self-sovereign identity system that relies on Blockchain consensus algorithms, decentralised identifiers (DID) and zero-knowledge proof to build a trust relationship between entities (Section 4.3.2.).

ML-based Configuration for Matchmaking in Digital Business Ecosystems

The approach on the elaboration of the approach for configuration of digital business ecosystems (DBE) in function of the context and intentions presents the PhD topic of Mustapha Kamal Benramdane3 . The current approach includes configuration of DBE to find best partners based on the contextual data. We reviewed the existing literature on matchmaking in DBE [START_REF] Benramdane | Supervised Machine Learning for Matchmaking in Digital Business Ecosystems and Platforms[END_REF] and developed a hybrid machine learning approach to provide recommendations for selecting the best partners depending on several contextual factors [Kornyshova et al., 2023b] [Benramdane et al., 2022] [Benramdane et al., 2021] [Benramdane, 2022]. This approach is validated within the electronic sector.

Literature Review on Matchmaking Techniques in DBE

With the emergence of the Web, businesses and individuals alike are increasingly present on digital platforms. The development of technologies is helping to expand these platforms that allow users to exchange and share content, data, and information [de Reuver et al., 2018]. However, this strong presence of users, the complexity of exchanges, and the abundance of data make it difficult to find partners or services that can meet the needs of a certain organisation or individual. This raises the question of wanting to match the entities that are likely to want to exchange via a business relationship. Matchmaking is a much older traditional problem, especially since the solutions provided date back to ancient Greece [START_REF] Decker | Matchmaking and brokering[END_REF]. Digital matchmaking describes a similar situation where entities that provide a service with characteristics, features, and constraints are matched to each other by a matchmaker with respect to these constraints [START_REF] Raman | Matchmaking: Distributed resource management for high throughput computing[END_REF]]. The modern matchmaking systems like Portable Batch System (PBS) [START_REF] Henderson | Portable batch system: External reference specification[END_REF], Load Sharing Facility (LSF) [Zhou, 1992] and Load-Leveler [START_REF] Evans | Matchmakers: The new economics of multisided platforms[END_REF] use a task control language or queues to tease the tasks submitted to them. [START_REF] Imran | Matchmaking model for bilateral trading decisions of load serving entity[END_REF] use Portfolio Optimisation and Direct-Search in a system of bilateral negotiations and transactions. Other recent systems, with the growing interest in digital matchmaking [START_REF] Evans | Matchmakers: The new economics of multisided platforms[END_REF], use sophisticated algorithms or matchmaking technologies [Tripsas et al., 2009] such as Decomposition Kernels of Graphs [START_REF] Lagraa | Matchmaking OWLS processes: An approach based on path signatures[END_REF] and Owl Search algorithm [START_REF] Xu | Semantic Matchmaking for an Agricultural Materials Exchange Platform: An Ontology-Based Approach[END_REF], or even Ant Colony Optimisation algorithm [START_REF] Essayah | QoS-Based Semantic Micro Services Discovery and Composition Using ACO Algorithm[END_REF]. However, none of these contributions adopted a machine learning approach nor made use of matchmaking to pair companies or services in a digital business environment.

To check and analyse the existing works on matchmaking in detail, the algorithms used therein, and its implementation in digital platforms, we questioned the Scopus API with the request shown in Figure 4.24. We have chosen to limit our research since 2010. We obtained from this database 46 publications which we took care to consult in order to keep only the closest ones to our research topic. Publications that allowed us to reach a considerable amount of information about the latest matchmaking technologies and their use cases.

When several organisations present interactions within the framework of a market segment through a digital platform, then it becomes possible to consider this platform as a digital business ecosystem. Digital systems have emerged in different ecosystems [START_REF] Iansiti | Strategy as ecology[END_REF], whether for electronic materials and components [Gonsalez-Castillo et al., 2001] or the semantic web [START_REF] Peng | A Web Service Matchmaking Approach based on Topic Models[END_REF]] [Celik et al., 2005]. In the semantic web, matchmaking solutions are proposed to match or discover services [START_REF] Friedrich | Integrating matching services into the Web of Needs[END_REF]] [Opasjumruskit et al., 2014], find information about road traffic [START_REF] Zapater | Semantic web service discovery system for road traffic information services[END_REF] or match between players on the Internet [START_REF] Boro | P2P matchmaking solution for online games[END_REF]. In order to find the best games, we can use elementary methods such as Direct Search [START_REF] Imran | Matchmaking model for bilateral trading decisions of load serving entity[END_REF] or Matching Instance [START_REF] Freidrich | [END_REF], whether on a centralised system or Large-Scale System [START_REF] Boro | P2P matchmaking solution for online games[END_REF].

Combinatorial optimisation methods are used as Paolucci Algorithm [START_REF] Zapater | Semantic web service discovery system for road traffic information services[END_REF], OWL search algorithm for an application in agriculture [START_REF] Xu | Semantic Matchmaking for an Agricultural Materials Exchange Platform: An Ontology-Based Approach[END_REF], decomposition kernels of graphs [START_REF] Lagraa | [END_REF], Genetic Algorithm (GA) or Particle Swarm Optimisation (PSO) to make sellers and customers on an online auction platform [START_REF] Ludwig | Matchmaking in multi-attribute auctions using a genetic algorithm and a particle swarm approach[END_REF]. Some of these platforms are based on mathematical models which help to govern them [Chen et al., 2018a], in particular, the probabilistic approach [START_REF] Cassar | Probabilistic matchmaking methods for automated service discovery[END_REF] for machine learning or for video games [START_REF] Christiansen | Multi-parameterised matchmaking: A framework[END_REF].

Others have opted for intelligent [START_REF] Christiansen | Multi-parameterised matchmaking: A framework[END_REF] approaches in distributed data environments [START_REF] Raman | Matchmaking: Distributed resource management for high throughput computing[END_REF]]. [START_REF] Cisneros-Cabrera | An approach and decision support tool for forming Industry 4.0 supply chain collaborations[END_REF] developed an approach integrating industry domain ontologies and multi-criteria decision support techniques to find the best partners and collaborators and form a coherent working team to tender to new business opportunities.

According to the different experiments, machine learning algorithms offer significantly higher performances when they are hybrids [START_REF] Ouksel | Matchmaking software agents in b2b markets[END_REF]] [Bao et al., 2017]. This surge of experiences directs us towards a hybrid approach between machine learning, statistical rules, and data imputation algorithms. To preserve the data of the users who are increasingly coveted on digital platforms, [START_REF] Wu | PSM2: A Privacy-Preserving Self-sovereign Match-Making Platform[END_REF] offer a solution based on Blockchain to protect the system user input on a service matchmaking platform.

At the end of this research, we found that none of these contributions have considered combining the different matchmaking techniques with machine learning in order to consolidate its performance. The cited approaches make use of static or combinatorial optimisation algorithms. In our view, the usage of machine learning algorithms, possibly hybridised with existing algorithms, should provide more accurate recommendations. In addition, the solutions offered are mostly dedicated to very specialised fields of use, namely games, agriculture, or web services. It is important, then, to consider a solution involving multiple entities belonging to different fields and market segments and try to match them.

Matchmaking Approach

The matchmaking approach uses data about business entities or actors and matchmaking algorithms, which indeed allow making the match between the given entities. The recommendation process includes two main phases (See Figure 4.25). The functioning of the MICE algorithm is based on data completion attribute by attribute. For instance, a set of data known as a sample of the form X = {x1, ..., xk} contains variables like {product ion capability, no of companies supplied, expertise level}. Some of these variables have missing values in some rows. The missing data are progressively replaced, attribute by attribute, by an average, median, fixed value, or by using a regression model depending on the attribute nature. It is important to repeat this process for several cycles on all the missing data variables, i.e. 10 to 20 cycles, according to Van Buuren [Van Buuren et al., 1999], to ensure that the MICE algorithm imputation model converges to consistent data. Using a machine learning-based prediction model, it iterates over the variables several times until it converges to consistent data. Thus, it reconstructs missing data [START_REF] Royston | Multiple imputation by chained equations (MICE): implementation in Stata[END_REF].

We train the model using two machine learning algorithms: Logistic Regression and Decision Tree. Both are subsequently trained and evaluated to predict whether the relationship (customer-supplier, supplier-distributor, or partner-partner) exists or not between two given organisations (the Relation attribute). The Relation has a binary value that indicates whether the use case relationship exists or not, according to the database. It is this value that the trained models are supposed to predict subsequently for new organisations in input. This process is repeated for the different use cases, which implies that we have a model for each of the different relations studied.

The matchmaking phase contains the steps followed to obtain a list of the recommended entities. Inside this phase, the first step of matchmaking corresponds to a set of software based on static rules (static matchmaking). In the second step, we use the trained models and machine learning algorithms to provide more precise recommendations. The database used for this study mainly contains business actors and data on their environment. It represents the contextual data considered at this stage of our research. The data in this database makes it possible to extract information on the relationships between actors. Figure 4.26. shows the Entity-Relationships (ER) diagram of the used database. Actors could be a foundation, an investor, a non-profit organisation, or any other form of organisation or individual. The study of these data makes it possible to deduce essential and vital information which can allow a new arriving business actor to understand better the environment in which it is likely to operate. The adopted approach aims to create, via different kinds of algorithms, optimal relations between the organisations and generate for a newcomer a list of potential partners, customers, or suppliers.

Static Matchmaking. As mentioned previously (see Figure 4.25.), the first step of the matchmaking phase represents static matchmaking. This is a set of algorithms using static rules applied to the database to generate a recommendation list at the request of the user and according to the data he has inserted as input. Static matchmaking is called so, not in opposition to dynamic but because it uses rules of the trade that are predefined and static. In addition, this also applies in a case where the user requests a list of customers, suppliers, distributors, or partners. Static matchmaking comprises two types of parallel and independent processing that we call layers, in this case, layer 1 and layer 2. For layer 1 of static matchmaking, the algorithms are essentially based on knowledge of the market and the type of activities of organisations belonging to a particular market segment. Indeed, the database can provide the information necessary for each market segment to identify with which other market segments the given organisation may have relationships. The same approach is used for an organisation regarding categories. The market segment and the category of the input organisation are first identified. Then, tables established in advance are used in order to find which categories or sectors of markets can be customers, for example, for a given organisation. Finally, we list the organisms appearing in these market sectors and categories identified according to the alphabetic in the absence of other criteria. For layer 2, the algorithms essentially follow two rules, which are, in the case of looking for a list of suppliers for an input organisation: 1) a supplier of a competitor is a potential supplier; 2) a supplier's competitor is a potential supplier. The obtained list is ordered according to an alphabetic order in the absence of other criteria. Depending on the use case, the user can request a list of customers, suppliers, partners, or distributors; the algorithms' processing is adapted to the request. The treatments of the second layer are deduced from existing relationships on the market, hence the relevance of the results, unlike those of the first, which are generic and common to categories of organisations. Static matchmaking combines the results of the two layers by eliminating redundancies and ranking those of the second before those of the first.

Smart Recommendation for Matchmaking. To improve the results generated by the static matchmaking, we use a classification algorithm that allows us to predict if the elements of this list are likely to be, for example, customers of the organisation in input. For now, we have experimented with basic classification algorithms such as Logistic Regression and Decision Trees and compared their results. The proposed algorithm uses a classification model to make an optimised recommendation.

When a user enters an organisation's profile as input, static matchmaking is used to generate the first list of recommendations according to the use case. Since static matchmaking has provided a list of suppliers to the input organisation, this step aims to identify which suppliers are more suitable than others for the input organisation. The pre-trained Logistic Regression or Decision Tree model will be used to predict the probability of the Relation label value to be "True" for the couple (Input_Organisation_data, List_Organisation_data). We call that the probability score. The algorithm will do the same for all the organisms in the list and generate scores for any row. In the end, the list is reorganised in descending order of this score. In the case of equality of score between two elements, the order obtained depends on the sorting algorithm, such as sorting with Timsort under Python. The Smart recommendation process is applied to the two lists that the two static matchmaking layers obtain. This generates two lists whose order is optimised, and by combining the two lists, we choose to rank the second higher than the first.

Validation within a DBE of Electronic Sector

In this section, we present the tests performed on our recommendation system and the results obtained. The data set contains 891 organizations. These organizations are divided into 4 market segments which are "Semiconductor", "Electrical & Electronic", "IT" and "Automotive"; and they are also sorted into 25 categories in total such as: "Software Provider", "Equipment", "Emerging Tech", etc. We discuss the tests and performance results at the level of matchmaking methods on a dataset and illustrate the matchmaking approach application results obtained during the tests.

Matchmaking Performance

Some variables in the dataset deliberately contain missing values that are essential for us to demonstrate the efficacy of our method of imputing missing data. In this test set, we made 20 cycles of MICE to impute the missing data.

The tests are divided into two categories. The first consists of performing matchmaking via the two algorithms of Logistic Regression, and of Decision Tree without any data imputation algorithm. The second is to perform the same matchmaking methods with the imputation of the data by the means of the MICE algorithm. Confusion matrices are drawn to show the efficacy of the algorithms in the different proposed approaches. This implies that Logistic Regression performs best when missing data is imputed in a more sophisticated way through the MICE algorithm than with general imputation.

Matchmaking Algorithm Application Results

We applied the described matchmaking-based business recommender system could be applied to seek for and obtain a list of suppliers, clients, distributors, and partners optimized for a given input organization.

In this scenario, we use the following test set:

• Name of organization: X (the name does not matter);

• Use case: Finding customers;

• Year of foundation: 1995;

• Market segment: Semiconductors;

• Category: Foundry;

• Products: CMOS, NVM, Bipolar, DRAM;

• Revenue range: 2M to 3M $;

• Number of employees: 51 to 100;

• Number of investors: 12.

According to the data and the use case, the system processes internally a list of all the organizations listed in the database. However, for aesthetic reasons, we choose to display a restricted list of 30 elements on the graphical user interface, which are ordered in descending order of their score. An illustration of the seven first items of the list is shown in Figure 4.29. We performed the tests for both Decision Tree and Logistic Regression algorithms and obtained concluding results. In addition, we observed that the Decision Tree algorithm is more efficient with the imputation of missing data with general imputation. The Logistic Regression performs best when missing data is more sophisticatedly imputed through the MICE algorithm than with general imputation.

To provide better recommendations to entities within DBE, we investigated the existing proposals using machine learning and found that these contributions almost have a common problem and do not allow efficient matchmaking between entities. We developed an approach to match different organisations inside digital business ecosystems and platforms corresponding to one or multiple market segments. Our approach combines static and machine learning-based methods to provide recommendations to different actors with a list of potential partners, consumers, and suppliers. From a practical point of view, the presented algorithm will be included in a more global solution for digital ecosystems and platforms to guide users not only to search for the best entities but also to allow a way to gain access to the resources adapted to a particular need. Our next step is to include data about user experience and user intentions to improve recommendations (an ongoing work).

Identity Protection using Self-Sovereign Identity in IoT

Lydia Ouaili is a PhD student on this topic4 . We are exploring a self-sovereign identity approach based on blockchain consensus algorithms and distributed identifiers to build a trust relationship between entities and IoT devices. The current work includes the literature review on this topic. Some preliminary results on the study are published in [Ouaili et al., 2022a] [Ouaili et al., 2022b].

Literature Overview on Self-Sovereign Identity and on the SSI integration into IoT (ongoing)

Identity Management Systems (IdMSs) are a predefined set of processes to ensure how digital identities are supposed to be ordered, managed, and revoked. It is about facilitating interactions between individuals and organisations in a safe, private, and more effective way. A digital identity can consist of identifiers (user ID, email, URL, etc.), credentials (certificates, tokens, biometrics, etc.), and attributes (roles, positions, privileges, etc.). Due to the increasing number of people in the world using the Internet, many processes are digitised. This means that all these people have the possibility to create an account in any available service. The user must provide information to the company managing this service. The company will create an account for that user, allowing him to access the service via a combination of credentials (usually email or username) and password. Therefore, manually managing all login credentials becomes a challenge. Today, one of the most common forms of identity management systems is based on federated solutions that allow businesses to share data with the same user and allow the same user to have a single login to access multiple services. This somehow solves the problem of too many passwords to remember but still allows several companies to hold the data of their customers. This last point is one of the many questions that the Self-Sovereign Identity (SSI) wishes to address, using decentralised identifiers (DID) and Verifiable Credentials (VCs), whose governance is managed by the user, allowing him to disclose only the necessary information while having the power to revoke it.

With regards to the Internet of Things (IoT), the use of IoT devices has increased rapidly; designing a digital identity for connected objects is a use case that is not considered in many identity management systems. Traditional identity and trust management frameworks are designed for humans, not devices, and digital identity is primarily linked to individuals or enterprise information systems that individuals also manage. Allowing IoT equipment to have its own identity opens up new possibilities, as there is today a significant presence of "autonomous" or "Smart" devices, which can act and make decisions alone or with the partial help of humans. These decisions usually involve communication between different equipment and using SSI to prove that the devices are what they claim to allow many use cases to be safer and less prone to attacks. In this case, the challenge is to ensure self-sovereign identity in IoT environments using an appropriate machine learning algorithm.

There is a gap between industries, independent foundations, and universities with respect to SSI. The first two focus on open source and software architectures for implementing SSI as a service. Although this is open-source code, there was a lack of in-depth analysis and a formal framework on the different solutions to explain some implementation choices, for example, the choice of registry (blockchain or other such as The Tangle). This led to the publication of many works on this topic. Some of them propose a formal framework [START_REF] Ferdous | [END_REF]] [Naik et al., 2020a] [Naik et al., 2020b] [Naik et al., 2021] [Cucko et al., 2021] [Belchior et al., 2020[START_REF] Muhle | [END_REF], other analyse its compatibility with the General Data Protection Regulation (GDPR) [Naik et al., 2020c] [Kondova et al., 2020]. Another work focuses on the workflows for its creation (DID and VC creation steps up to the verifier) [Nokhbeh et al., 2021], discussing the difficulties and limitations of these concepts. [Brunner et al., 2020] [Stokkink et al., 2021] analyse Sovrin and uPort implementations based on ISS requirements (for example, longevity, security, confidentiality, interface, scalability). Architectures and design models characterising the SSI have been proposed to support the development software [Gruner et al., 2021] [Liu et al., 2020].

SSI is independent of the central authorities. With decentralised management, several entities collaborate to manage the VC, the DID, and ensure the replication of the data, persistence, and integrity between these entities with an open-source code. This differs from centralised solutions (federated and user-centric models), which are generally non-transparent. Distributed registries such as blockchain appear to be good candidates to meet these requirements [START_REF] Kaneriya | [END_REF]] [Bhattacharya et al., 2020] [Gilani et al., 2020].

With regard to use cases, in [START_REF] Abraham | [END_REF], an identity system for eGovernment was proposed, where it is possible to move and connect centralised and qualified identities to the SSI system by transforming the data format so that it corresponds to the SSI format and switch to decentralised management using Hyperledger Indy. The transformation is done via an agent acting as an interface.

In [START_REF] Belchior | [END_REF], the authors propose a model that replaces the traditional resource access control model where the storage of sensitive data such as user attributes is required. In their model, SSI allows access to resources by associating VCs and the distributed registry with access policies. In [START_REF] Abraham | [END_REF], authors are interested in the revocation process in real-world scenarios (for example, when a police officer revokes a certificate).

Although most of the above-mentioned work has addressed the conceptual part, there is a lack of indepth work on SSI and decentralisation based on distributed registry technologies. Indeed, blockchains depend mainly on protocols; more precisely, consensus algorithms are necessary to ensure the operation and management of these registers. This consensus depends on several factors, such as the use case that will influence the choice of the type of registry (private or public) and the security and integrity of the registry.

Most of the recent work on SSI is limited to human identities. In an IoT ecosystem, each IoT device that wants to connect securely to another must verify its own identity as well as the identity of the others during the connection. Thus, managing the digital identities of IoT devices is a subject that needs to be explored further. One of the first works in this direction was published by [START_REF] Bartolomeu | [END_REF].

The authors study the use cases, technologies and challenges related to the application of SSI to manage identities in an IoT environment. They provide a detailed comparison of the most promising SSI-focused implementations (Hyperledger Indy, uPort, BlockStack, VeresOne, Jolocom). The challenges highlighted in this paper illustrate the key issues for adopting and using SSI in IoT-based domains. In [START_REF] Fedrecheski | Self-sovereign identity for iot environments: A perspective[END_REF], the authors provide an analysis and comparison of existing identity management models according to the uniqueness of the identifier, centralised management, service termination points and emphasise that only SSI allows selective disclosure and zero-knowledge proof. They also discussed the benefits of SSI in IoT, such as confidentiality and decentralisation, and identified it as the best option for managing digital identity in IoT ecosystems. Other challenges are addressed, such as the storage capacities of IoT devices and the limited processing resources for encryption algorithms. In [START_REF] Gebresilassie | [END_REF], the authors explain the problems of device identity management and mention the frameworks most used to implement decentralised identity management (uPort, Hyperledger Indy). They propose a new solution for the identity management of IoT devices based on self-sovereign identity and the Tangle IOTA [START_REF] Popov | [END_REF]. In [START_REF] Weingaertner | [END_REF], the authors consider the identification of IoT devices from their manufacture to their use to have transparency on their origin and history, which ensures proof of origin for the traceability of devices. Their approach is based on SSI to identify devices and on Blockchain Ethereum to ensure immutability and autonomy. They also consider registration in the client's environment using bootstrapping of remote secure key infrastructures (BRSKI). In academic research, most identity-based access management systems based on blockchain and applied to IoT are generic solutions. In [START_REF] Terzi | [END_REF], an in-depth analysis is done on how to use SSI to ensure that the emission rates produced by Internet of Vehicle (IoV) devices (a subtype of IoT devices) are verifiable and not falsified. Hyperledger Indy is used to authenticate and authorise entities on a Hyperledger Fabric network. In [Capela, 2021], proof of concept of a new system based on the SSI was developed in the charging networks of electric vehicles, using Hyperledger Indy and Aries.

Blockchain technology inspires a fundamental transformation in the vision of identity and online trust. We plan to move towards the axis of decentralisation in the IoT. Our solution is an ongoing work. It main objective is to propose an identification system for IoT devices in a community of entities to interact with each other and securely perform intelligent tasks, using the SSI and the immutability of the blockchain.

Smart Life

The rise of Smart applications and technologies in different domains, such as Smart cities, Smart home, Smart factory, Smart energy, and so on, articulates a need for a more encompassing understanding of Smart that can function as a fundamental theoretical concept. The concept of the Smart object was already introduced in 1998 by [START_REF] Kallman | Modeling Objects for Interaction Tasks[END_REF]]. Since then, numerous works were purposed to present Smart-related fields. We can see it with the number of state-of-theart papers and research agendas on these topics. For instance, just the number of state-of-the-art papers on Smart cities is about 80-90 by year. We can cite just some of them [START_REF] Gopinath | State-of-the-Art and Emerging Trends in Internet of Things for Smart Cities[END_REF]] [Echebarria et al., 2021] [Bohloul, 2020] [Ali et al., 2019]. Recently all "Smart" terms have been bundled under the umbrella topic of Smart Life. However, we did not find any clear explanation of what exactly Smart Life is. We studied the literature and suggested a more detailed vision of Smart Life. In addition, a set of methods, approaches, tools, etc., should be established to design, develop, maintain, and eventually recycle Smart applications. We call that Smart Life Engineering (SLE).

Smart Life Definition and Engineering

Our goal is to define and characterize the terms Smart, Smart Life, and Smart Life Engineering (Section 5.1.1.). To move forward with Smart Life Engineering, we started with the first phase of the engineering process -requirements engineering, and we defined a new kind of requirement to deal with the wellbeing of humans using various ICT and digital devices (Section 5.1.2.).

Definition of "Smart" and Smart Life

We defined Smart Life in [Kornyshova et al., 2022d] [Kornyshova et al., 2023c] using a systematic approach and by specifying three degrees of smartness. In [Kornyshova et al., 2022a], we analysed the existing literature to identify a taxonomy of contemporary Smart applications and analyse their evolution. In addition, we defined a Smart Life research agenda to identify the key issues remaining in this field [Kornyshova et al., 2022d].

Defining Smart Life

We used a systematic mapping study (SMS) methodology [START_REF] Petersen | Systematic mapping studies in software engineering[END_REF] to identify and analyse the current definitions of Smart Life. We searched and selected papers in the Scopus scientific database using the Scopus Search API in November 2021. Firstly, we searched for papers containing the term "Smart" only in the title, and the number of obtained papers was more than 126 000. Thus, we limited our search to secondary research papers like state-of-the-arts and research agendas. This reduced search allowed to obtain 2410 sources with DOIs. We analysed the titles and, if needed, abstracts and papers content. We excluded 69 sources, not representing research papers or not relevant to Smart Life topics papers. We obtained 2341 papers that we used in our study. See for detail [Kornyshova et al., 2022d].

In the existing literature, the concept of Smart Life is often linked to the Internet of Things (IoT). IoT has made revolutionary changes in human life and enables the exchanges of information in a wide variety of applications such as Smart buildings, Smart health, Smart transport, and so on, which can be unified into a single entity referred to as Smart Life [START_REF] Harbi | A Review of Security in Internet of Things[END_REF]] [Benhaddi, 2017]. A step beyond is in [Chen et al., 2018b], where this new entity of IoT is characterized as a new lifestyle. Smart Life connects all IoT microdevices and microsensors under wireless communication grids [START_REF] Lee | Enhanced Electrochemical Performance of Micro-Supercapacitors Via Laser-Scribed Cobalt/Reduced Graphene Oxide Hybrids[END_REF]. This widely spread idea of a connection of all embedded devices around us to the internet has the potential to change our lives and the world, to enable us to live a Smart Life in a Smart world [START_REF] Baruah | Impact of IOT in Current Era[END_REF]. IoT then becomes an indispensable technology to improve the quality of life for human beings [START_REF] Cho | Sustainable hybrid energy harvester based on air stable quantum dot solar cells and triboelectric nanogenerator[END_REF], [START_REF] Ho | Developing a life rhythm related human support system[END_REF] and people want to live a Smart Life [START_REF] Sharma | Indian smart city ranking model using taxicab distance-based approach[END_REF].

However, Smart Life is not reduced to IoT. The key concept of Smart Life is the data use and processing to improve our living. Each artefact processing data is Smart even if it is not connected. In addition, "Being smart" should not be confused with "being digital" as infrastructures and technologies are the means, not the end, enabling a set of services that affect deeply life [START_REF] Coccoli | Smarter universities: a vision for the fast changing digital era[END_REF]. IoT objects and devices collect every possible data about a user, but their final goal is to make intelligent use of such data to support this user [START_REF] Yoon | SuperCaly: Smart life assistance by integrating a calendar app with location tracking, media organization and social connection[END_REF]. These intelligent devices will drive people into Smart Life, becoming the new innovative direction of the internet [Fu, 2016].

In a thorough analysis of the studied literature, we did not find any consistent definition of Smart Life. Even the notion of Smart is understood rather differently between sub-fields and even inside fields. For instance, different notions of Smart object could be found in [START_REF] Garcia | [END_REF]] [Liu et al., 2016], but there is no common agreement on the notion of Smart object. Thus, we developed the notion of Smart Life with regards to its structure and the definition of different smartness degrees to better specify the concept of Smart.

Smart Life Structure. From the structure point of view, we foresee Smart Life using the systemic approach [Thagard, 1993]. The core element of Smart Life is a so-called Smart Artefact, the term we selected to avoid intermingling with already established terms such as a Smart object or Smart thing. Smart artefacts correspond to any standalone device with a program and a capability to store and process data. Smart artefacts of the same or similar functional usage form a Smart Application. Smart applications could be identified at different levels of granularity from detailed and concrete (e.g., a Smart lighting system including several sensors about the home environment and people positions in a home) to more global ones (such as a Smart home application covering different aspects: lighting, heating, windows management, and so on). Smart artefacts could belong to two or more Smart applications, like Smart lighting systems could be found in Smart home, Smart factory, or Smart city. Each Smart application is a system of Smart artefacts, which means that it should have at least one emergent property [START_REF] Nikolaev | Systems thinking ontology of emergent properties for complex engineering systems[END_REF]. Emergent properties correspond to features of the whole system and that system elements do not have, like all components of a car should be put together in a certain manner so this car could run. Smart Life, in its turn, is composed of various Smart applications, thus Smart Life is a system of systems. In its simplest form, Smart Life is a combination of at least two Smart applications, that requires coordination based on the input and analysis of emergent properties. This system-oriented vision of Smart Life is illustrated in Figure 5.1. Smartness Degree. To understand better the nature of Smart Life, we go in deep into the definition of the term "Smart". We define the degree of smartness depending on data integration and processing type. The first axis reflects different levels of consideration of data coming from the environment and users. Data complexity varies from the embedded sensors data (immediate environment) to data from the distant environment in addition to the sensors data, and, finally, to data on users' well-being and state. The second axis shows how data are processed from non-AI processors to AI-based processors (expressing the processor complexity). We distinguish three degrees of smartness: smart, intelligent, and sentient.

• Degree 1 of Smartness -Smart: is a capability to process data and to adapt its functioning.

• Degree 2 of Smartness -Intelligent: is a capability to process data and to adapt its functioning with the usage of AI (Smart + AI). • Degree 3 of Smartness -Sentient: is a capability to process data coming from users about his/her feelings, emotions, physical state, and so on. The notion of sentience came from the field of animals' rights protection and is quite new to the field of ICT. It is already used to qualify the evolution of artificial intelligence of machines [Husain, 2017] or to introduce requirements for human-aware information systems and technologies [Kornyshova et al., 2021a].

To illustrate this proposal, we position the smartness degrees according to the two axes (data complexity and processing complexity) and give some examples (Figure 5.2.). We can sum up the main definitions of our proposal as follows:

Smart Artefact is any autonomous and stand-alone artefact provided with a data processor when data is obtained, stored, processed, and used to trigger actions of the artefact in the environment. A Smart artefact could be connected or not. For example, a Smart artefact can be a Smart watch, Smart window, Smart toy, Smart antenna, and so on.

Smart Application is a system of connected Smart artefacts, and possibly other Smart applications. Thus, it corresponds to a set of artefacts with a common goal. For instance, a Smart city application can be composed of a Smart parking application, a Smart energy application, and so on. A Smart home can be composed of a Smart TV, a Smart fridge, a Smart assistant, and so on. A Smart application should contain at least two Smart artefacts.

Smart Life is defined as the domain that embraces all Smart applications and Smart artefacts for the purpose of an enriched experience from the personal, societal, environmental and enterprise perspectives [Kornyshova et al., 2022a] development approaches, a multitude of modelling and coding. Furthermore, the individual or human perspective is not included. We relate these viewpoints in chapter 5 when describing the research agenda.

Taxonomy and Evolution of Smart Applications

Smart applications appeared and they are interconnected to each other. A structuration should be done. We studied the topics of the selected 2341 papers. Firstly, we followed the bottom-up approach: we studied the titles of all papers, however, when titles were not sufficient to identify the application field, we read the abstracts, and, if needed, looked inside the papers. We attributed from one to three levels of applications classification to each paper (for instance, Smart energy -> Smart grid -> Smart grid communication), except papers dealing with Smart artefacts, technologies, or systems without attachment to a concrete application field. The attribution of each paper to a Smart application was done by an expert. When the mapping of a topic to a Smart domain was not obvious, the paper was analysed in more detail by two or more experts to find a consensus. Once papers qualified, we started to organize them within a taxonomy using a top-down approach: we took the major fields of Smart Life like Smart home, Smart city, Smart industry, Smart healthcare, etc. and we organized the identified application fields within major fields. Considering the number of the major application fields, we organized them within four categories that we called Smart Life domains: Smart applications for persons, Smart applications for environment, Smart applications for society, and Smart applications for enterprises (See Figure 5.3.). Smart applications for society deal with various not-for-profit aspects of human life in groups like Smart city and Smart village, but also applications related to the management of people living in groups: Smart citizenship, Smart state, Smart policing, and so on. (See Figure 5.6.). To give some more detailed illustrations, the Smart city concept is used to solve the challenges in urban cities by providing a good liveable environment for the citizens [START_REF] Al-Ani | Smart city applications: A survey[END_REF]. Therefore, in the taxonomy, the Smart city application domain contains sub-applications addressing security, growth, lighting, parking, and so on. With regards to Smart agriculture, new technologies are more and more used in modern agriculture and IoT farmers can remotely monitor their crop and equipment by phones and computers [START_REF] Mekala | A Survey: Smart agriculture IoT with cloud computing[END_REF]. The Smart agriculture application domain contains usual agricultural types like Smart farming, Smart fishery, Smart crop management, and Smart livestock farming, but also some other domains influencing agriculture, like climate-smart agriculture, Smart pest management, and Smart irrigation.

122/158 HDR

In addition to this main taxonomy, we identified the presence of "generic clusters" that can be used in different Smart applications. For instance, Smart energy is an independent application domain, within Smart industry. However, we can find it in other domains: Smart city, Smart home, etc. Another identified cluster is the Smart transportation one. This specific cluster identifies the Smart applications related to the transportation domain. These applications can be relative to several other applications, like Smart vehicle charging which can be applied in Smart cities (to identify the flow of electric vehicles in a specific area and the distribution of energy in the grid), or in a Smart home (to analyse the consumption of a specific house). We observed that new notions are introduced in the literature, even if they are not completely implemented yet. Smart island is an attempt to classify the existing Smart-related methodologies in the urban context to analyse their possible application to the islands [START_REF] Desogus | Smart Islands: A Systematic Review on Urban Policies and Smart Governance[END_REF]. Smart state is described in [Hortz, 2016] as a direction of "Knowledge-Based Urban Development". In [START_REF] Kaur | A Systematic Literature Review of Blockchain Technology for Smart Villages[END_REF], a literature review is done on the usage of the blockchain technology in Smart villages. Finally, the term Smart world appeared in the literature [START_REF] Kumari | A Review on Hybrid WSN-NGPON2 Network for Smart World[END_REF]] [Liu et al., 2019] as a unifying term of various Smart applications. For instance, [START_REF] Liu | A review of the smart world[END_REF] defines Smart world as "an attractive prospect with comprehensive development of ubiquitous computing involving penetrative intelligence into ubiquitous things". In our vision, this term corresponds to our vision of Smart Life.

When constructing the Smart Life applications taxonomy, we excluded 328 sources dealing only with Smart artefacts, Smart technologies, and Smart systems not related to specific application domains. The taxonomy does not either include Smart infrastructure-related applications as we foresee them as transversal issues, we can find infrastructure almost in all major Smart applications fields.

The evolution of Smart domains is shown in Table 5.1. for the period from 1986 to 2022 (publications already available in 2021). We grouped the first 21 years in the same column as the number of publications was very law for this period. We complete this chronological vision by a graphical representation illustrating the distribution of Smart domains (See Figure 5.8.).

We can see that the first reviews appearing in the literature concern Smart applications for enterprises (in 1986). Then literature shows interest in two other domains, namely Smart applications for persons and for society, in the 2000s. More recently, Smart applications for the environment came out more prominently.

In the Smart applications for enterprises domain ( 1142

Smart Life Research Agenda

In the research agenda, we define four perspectives for Smart Life and Smart Life Engineering research: technological, methodological, organizational, and societal (See Figure 5.9.). Different research agendas in particular Smart technologies or applications can be found in other works, for instance [START_REF] Gopinath | State-of-the-Art and Emerging Trends in Internet of Things for Smart Cities[END_REF]] [Echebarria et al., 2021] for Smart cities, e.g. We focus on generic research topic related to all Smart domains.

Technological challenges. Smart applications generate all sorts of data that is of interest to other applications (it does not make sense to build a central data archive). The necessity to manage a huge amount of data implies multiple issues: How can secure and privacy-aware access to data be granted and obtained for various applications? How can high-level information wishes be expressed in distributed queries over a variety of applications? An appropriate distributed infrastructure should be defined accordingly. In addition, Smart applications require devices, resources, and energy, which are scarce and need careful implementation and a recycling perspective. Thus, other questions should be highlighted: Can we identify Smart Life methods for Green IT and ensure sustainable development?

Thus, we define the following SLE technological challenges: developing shared but secure and privacyaware access to data, developing efficient distributed infrastructure, considering Green IT, considering sustainability, and so on. Organisational challenges. When multiple Smart applications build up a large-scale Smart Life experience, there is a variety of stakeholder groups (e.g., citizens, entrepreneurs, city officials) that have different interests in the data, products, and services sharing. How can multi-stakeholder policies be organized and communicated? How can governmental and democratic representations assist in the elicitation of views and strategies for the future? Smart artefacts and applications in real-life settings are usually owned by different stakeholders, who have their own budgets, plans, and Information and Communication Technologies infrastructures. Bringing these parties together in various Smart Life projects requires careful communication and planning across organisations. How agile engineering approaches can engage distributed owners in a SLE project? How investments in facilities and resources can be shared in complex beneficiary dependencies, where long-term costs and benefits are not balanced among stakeholders? We then define the following preliminary set of organisational challenges for SLE: defining policies for Smart applications governance, defining policies for distributed ownership engagement, defining policies for data, products, and services sharing, etc.

Methodological

Societal challenges. The propagation of Smart Life applications raises questions related to ethics and well-being issues. The issue of system accessibility is becoming critical. While organisations are promoting guidelines for making some websites more usable by people with disabilities, almost no attention is being paid to other types of Smart products and embedded systems. How can we build Smart systems that will reason coherently over the type of ethical dilemmas that we humans have to deal with? Engineering of Smart Life artefacts and applications should not only provide means to attain their main functional purposes, but also contribute to users' well-being. Many current technologies cause addiction or depression, for instance, social media induce the FOMO (Fear Of Missing Out) syndrome (discussed in [START_REF] Kreps | Understanding Digital Events: Process Philosophy and Causal Autonomy[END_REF]) which could increase the risk of becoming depressive. How the well-being of users can be considered during all engineering phases starting from requirements elicitation?

The most important SLE societal challenges include ensuring machine ethics, developing Smart Life applications consciousness, providing sentient systems, providing system accessibility, and so on. We made an important step in defining and structuring the field of Smart Life. Firstly, we discovered a very large, and continuously growing, set of Smart topics ranging from very established (like Smart energy, Smart material, Smart city, and so on) to emerging ones (like Smart airport, Smart toy, or Smart gun) and from very practical (like Smart waste bin system and Smart self-power generating streetlight) to more conceptual (like Smart earth and Smart world). We believe that a huge scientific effort should be made to optimize these fields to make life smarter. In line with it, we summarised the research work on "Smart" state-of-the-arts and research agendas to identify and classify Smart applications. We carried out a systematic mapping study based on 2341 publications to define a taxonomy of Smart applications, understand their distribution, analyse sources of the research works, and identify the underlying terminology. Our main goal was to promote the field of Smart Life and Smart Life Engineering to provide fundamentals for more efficient and sustainable research efforts. Currently, we are preparing an open access book to move forward this topic [Kornyshova et al., 2023a].

Definition of Sentient Requirements

As a first step to develop SLE, we selected to start by studying requirements to improve interactions between Humans and ICT. The technologies intending to improve life of humans are various: Internet of Things, Robotics, Autonomous Vehicles, Cloud technology, Big Data, Automation of knowledge work, Digital entertainment business practices, augmented reality, and so on. Many works and even European Commission (EC) projects are done to analyse social and ethical issues of ICT and to protect humans' and animals' rights [START_REF] Jørgensen | ICT and Human Rights, Frame Fostering Human Rights among European (external and Internal) Policies, largescale FP7 Collaborative Project[END_REF]] [Misuraca, 2019[START_REF] Ericsson | ICT and human rights: an ecosystem approach[END_REF]. On the other side, Michel Serres, the French philosopher, states that throughout history, Humankind lost abilities, but each time it occurred, it was for a greater benefit [Serres, 2013]. Humans "lost" their heads with the invention of the computer. But at the same time, the computer raised new opportunities that we now experience through the digital era and the new tools emerging from it. It extended our minds. Michel Serres also states that Humans have completely changed since the mid-20th century. Humankind lost its connection to Earth and nature. We do not feel life the same way anymore. Over the world, most of them live in cities, and this phenomenon is far from being stopped [Serres, 2011]. Our creed is that this statement shows a missing link in our approach to the digital era. As we are losing the connection with nature, we need to reinforce the way we sense our environment. It will only be possible through Information and Communication Technologies (ICT). On the other hand, the impact is double. Digital and social media technologies can take control of human consciousness, and by this way, they imply dissatisfaction about technologies [START_REF] Kreps | Understanding Digital Events: Process Philosophy and Causal Autonomy[END_REF]. For example, social networks stimulate depression when "we feel we have to check, but checking does us no good" [START_REF] Kreps | Understanding Digital Events: Process Philosophy and Causal Autonomy[END_REF]. Technologies take control of human sovereignty [START_REF] Kreps | Understanding Digital Events: Process Philosophy and Causal Autonomy[END_REF].

The interactions between Humans and ICT should be improved at various levels. In my vision, it should be done starting from the earliest stages of ICT design -the requirement engineering phase. The requirements are traditionally seen as functional and non-functional. A functional requirement is a "description of a behaviour that a software system will exhibit under specific conditions [START_REF] Wiegers | Software Requirements[END_REF], a non-functional requirement (NFR) is a "description of a property or characteristic that a system must exhibit or a constraint that it must respect" [START_REF] Wiegers | Software Requirements[END_REF]. The former type represents the set of functionalities to be provided by ICT devices, and the latter covers additional aspects like security, availability, and scalability. However, the traditional requirements do not cover the need to provide ICT and ICT devices (called globally ICT in the following) dealing with the well-being of their users. This kind of requirement is not functional by nature. Their purpose does not cover the suitable functionalities addressing the application needs. They don't address non-functional requirements which deal with the operationality of the system architecture. This new kind of feature adds an additional dimension to the usual requirements and also impacts a subset of traditional functional and non-functional requirements.

We analysed the existing literature and suggested a new kind of requirement that we called "sentient", illustrated them in the case of a visiting game in a museum, and positioned them in relation to other types of requirements (functional and non-functional) inside a pyramid [Kornyshova et al., 2021a].

Identification of Sentient Requirements

As sentient requirements represent an emerging field, it is difficult to carry out precise research of the literature. Thus, this first step of the literature review was wide. We proceeded by using the following search string: "ICT" AND "Human" on google scholar in January 2021, and we used the backward/forward strategies to complete the study. We have checked the 20 retrieved pages and stopped after 5 pages without relevant results. We included works directly dealing with requirements and those with the associated terms, like "need", for instance. We excluded several works related to our topic but not specifying any requirements-related information. We classified the gathered literature into the following perspectives: philosophical perspective [START_REF] Kreps | Understanding Digital Events: Process Philosophy and Causal Autonomy[END_REF]] [Hultin, 2019] [ [START_REF] Baxter | Socio-technical systems: From design methods to systems engineering[END_REF]] [Kaptelinin et al., 2018] [Creswell et al., 2010] [Kreps, 2018a] [Markus et al., 2018] [Lee, 2019]; IT and business perspective [Stephanidis et al., 2019] [Cecchinato et al., 2019[START_REF] Kagermann | Recommendations for implementing the strategic initiative Industrie 4.0: Securing the Future of German Manufacturing Industry[END_REF]] [Lu, 2017] [Ozdemir et al., 2018] [Geoghegan et al., 2004] [Whitworth, 2011]; ethical perspective [Misuraca, 2019] [Musiraca et al., 2019[START_REF] Jorgensen | [END_REF][START_REF] Ericsson | ICT and human rights: an ecosystem approach[END_REF]; and societal perspective [Patel, 2014] [Ratan et al., 2007]. Then, we carried out the textual analysis of the selected sources and extracted sentences that could be useful to capture the nature of human interactions with ICT with regard to their well-being. In addition, this step allowed us to identify the list of keywords to be used during a more detailed literature review: sentient requirement, well-being requirement, welfare requirement, smart requirement, affective requirement, and synergy requirement.

To identify sentient requirements, we used science-fiction literature to feed the list of sentient requirements. As I. Asimov [START_REF] Asimov | Asimov, I.: Runaround[END_REF] inspired thoughts on Artificial Intelligence, we have been inspired by the Powers Trilogy of Anne McCaffrey and Elisabeth Ann Scarborough [McCaffrey et al., 1993] [McCaffrey et al., 1994] [McCaffrey et al., 1995]. This trilogy describes a living planet, Petaybee, which is also depicted by the authors as a sentient planet. We extracted from the first book sentences characterizing the sentient planet's abilities and its interactions with humans and other beings.

Together with the literature collected from the previous steps, we grouped different ideas depending on their nature.

For instance, to formulate the requirement "Interaction and Involvement", we generalized the following retrieved sentences and ideas: (i) The synergy requirement studied with application to interactions between human beings: ICT should be designed to support synergy between human beings. The synergy could be understood as interaction and involvement as it also covers the relationship between human beings and ICT [Whiworth, 2011]; (ii) Human beings and ICT should co-evolve together through time [START_REF] Kreps | Understanding Digital Events: Process Philosophy and Causal Autonomy[END_REF]] [Markus et al., 2018] [Kreps, 2018b]; (iii) Human-Technology symbiosis "defining how humans will live and work harmoniously together with technology" and Human-Environment Interactions referring to "the interaction of people not only with a single artifact, but with entire technological ecosystems featuring increased interactivity and intelligence" [Stephanidis et al., 2019]; (iv) "It[planet]'s only courteous to communicate", "There's a relationship [between the planet and humans] involved", "Living here, most of us know that and accept the gifts, the protection, and in return, we offer it companionship", "I just know that Petaybee works for us, and for itself, in a unique symbiosis…" [START_REF] Mccaffrey | Powers that Be[END_REF]. We proceeded in the same way for the other requirements. Based on the analysis, we did not include several requirements detailed in different perspectives as we consider them belonging to the two other types of requirements (exclusion criterion). For instance, a requirement "ICT should help to learn on technologies" [Buchanan, 2019] is a functional requirement as learning objectives are covered by the ICT functionalities. Another example is "ICT should ensure end-to-end encryption" [START_REF] Ericsson | ICT and human rights: an ecosystem approach[END_REF] is typically a non-functional requirement as it is related to the security of data usage.

To qualify the new kind of requirements, we used the term of sentience. Broom [Broom, 2006] defines: "a sentient being is one that has some ability: to evaluate the actions of others in relation to itself and third parties, to remember some of its own actions and their consequences, to assess risk, to have some feelings and to have some degree of awareness". This author underlines different aspects of sentience [Broom, 2016]: the sentience is related to ethics and moral issues; sentient abilities could be acquired and also be lost; the sentience requires "to act in an acceptable way towards each other person and toward each animal that is used"; and effects should be adapted to a given animal, "some components of sentience being dependent upon cognitive ability". [START_REF] Feinberg | The Ancient Origins of Consciousness: How the Brain Created Experience[END_REF] mention that sentience covers all aspects of sensory consciousness; to be sentient means to be "capable of experiencing an affective state". By [DeGrazia, 2020], the capacity to have pleasant or unpleasant experiences "entails having a quality of life or experiential welfare, from which it follows that sentient beings have interests". With regards to the Human-Computer Interaction challenges [Stephanidis et al., 2019], four sentient requirements (interaction and involvement, awareness, inclusiveness, and self-reflectiveness) could contribute to developing the five challenges, namely: Human-Technology symbiosis, Human-Environment Interactions, Well-being, Health and Eudaimonia, Accessibility and Universal Access, and Learning and Creativity.

Considering current trends in ICT, a set of concepts arose recently: digital humanities, Life 3.0, Health 3.0, Welfare Society 2.0 etc. Digital humanities refer to "the intersection of digital technology and humanities: arts, literature, music, dance, theatre, architecture, philosophy, and other expressions of human culture" [START_REF] Drucker | Intro to Digital Humanities: Concepts, Methods, and Tutorials for Students and Instructors[END_REF]. Tegmark [Tegmark, 2017] presents the role of Artificial Intelligence can play for humans. He defines three stages of Life: Life 1.0 (biological evolution), Life 2.0 (cultural evolution), and Life 3.0 (technological evolution). The last stage (not yet reached) refers to design not only "software" (meaning knowledge used to process the information issued from senses to decide about action, a kind of living "biological software"), but also "hardware", that is to say, the ability of organisms to change their physical components. To attain this future Life 3.0, Artificial Intelligence (AI) will play a particular role and should be friendly. One of the main requirements to the friendly AI is to align goals, thus, to better accomplishing human goals using superintelligence. The goals alignment could be done by resolving three problems: "making AI learn our goals, making AI adopt our goals, making AI retain our goals". Within a visionary editorial, Nash [Nash, 2008] defines Health 3.0 as using social networking technologies to exchange about symptoms, medication and providing medical care. Misuraca [Misuraca, 2019] foresees different socio-technical trends as, for instance, "Care 3.0 -Robotics for personalized care solutions" and calls it Welfare Society 2.0. These trends underline the necessity to go forward with the definition and application of sentient requirements and make us consider the necessity to take into account the goal-oriented dimension in process-relational philosophy underlying our research.

Illustration of Sentient Requirements

We applied the sentient requirements to the case of a role-playing visiting game in a museum based on our experience with museums and the related literature [Kornyshova et al., 2021a].

The purpose of the game is to learn the process of manufacturing an artefact. The visitors can choose between three different roles. The game is provided through touchable tablets to each player. The visitor has a role and follows different steps of the game to build his knowledge. Across the museum, the visitor solves puzzles related to the content encountered corresponding to different resources and manufacturing tasks. In Table 5.3, we illustrate the sentient requirements expressed for our use case and deduce related functional requirements to show how the sentient requirements could be implemented in practice. The tablet should be able to guess visitors' unforeseen needs and provide answers/guidelines. Include a chatbot service.

Awareness

The tablet should be able to identify satisfying conditions to be used by a visitor (clean, enough power, functional).

Alarm if it is dirty, compute the amount of available power, and detect any misbehaviour.

Safety

The tablet should alarm in case of any kind of danger.

Display/broadcast an alarm and personalized instructions to avoid danger in time.

Belongingness and Felicity

Users should feel proud of their accomplishments through the game.

Monitor game achievements, stimulate users, and provide incentives during the game.

Adaptability

The tablet should sense emotions and adapt the game to the mood of the user.

Have sensors, compute emotional states, and adapt puzzles.

Sustainability

The tablet should optimize network communications to lower radio waves emissions.

Compute and adapt radio communication intensity to the appropriate level.

Respectfulness

The tablet should react to inappropriate usage.

Have sensors to detect unexpected movements, bumps, and drops and display/broadcast warnings.

Inclusiveness

The tablet should detect disabilities and adapt the interaction with the visitor (for instance, switch to speech).

Have sensors, detect how the interaction is going on, and provide accurate help.

Self-Reflectiveness

The tablet should help to improve the user experience.

Gather game data, analyse player behaviour, and enhance gameplay.

Based on this example, we have obtained the following results: (i) We have succeeded in expressing the identified sentient requirements applied to the visiting game in a museum, and (ii) We have shown that sentient requirements could be translated as a set of functional requirements. Therefore, our proposal about sentient requirements could be applied to a real case, and it provides useful insights to improve user experience design.

The introduction of sentient requirements could contribute to the maintenance of human sovereignty by aligning the properties of technologies to human needs, and by creating this kind of harmony between human beings and technologies. For instance, the application of sentient requirements to social media inducing the FOMO (Fear Of Missing Out) syndrome (discussed in [START_REF] Kreps | Understanding Digital Events: Process Philosophy and Causal Autonomy[END_REF]) could decrease the risk of becoming depressive. Based on infomateriality of [Kreps, 2018a] [Kreps, 2018b] and close to the relational synergy of [START_REF] Markus | Is IT Changing the World? Conceptions of Causality for Information Systems Theorizing[END_REF], our point of view is that human beings and ICT should co-evolve together through time. In line with these works, we claim that symbiosis between human beings and ICT is often foreseen as two opposite sides. This leads us to sentience, which we define as a new kind of harmonious co-existence of human beings and ICT through time.

The specification of sentient requirements would allow to overcome this gap. Sentience becomes a topic in scientific Information Technology-related publications. We believe that this term reflects well the concept of requirements contributing to building an emotional link between human beings and ICT. Our proposal will also contribute to the method axis, as the sentient requirements will impact the existing methods of requirements engineering and the whole cycle of IS engineering.

However, the introduction of sentient requirements will produce many additional, often new, questions to be solved as, for example, can ICT and devices be designed to be sentient, especially when we think about robots and the Smart Internet of Things? Can we expect a smarter and more sustainable life with the digital surroundings we are providing? The way we embrace the future and the relationship with artificial intelligence-based technology is different from transhumanism [Bostrom, 2019], where human beings are extended or augmented with ICT parts.

Research Perspectives and Conclusion

My research perspectives follow the three defined axes and allow progress on the definition and formalisation of context and intentions, configuration methodology improvement in the context of digitalisation, and the definition of intelligent and sentient interactions of humans with ICT.

Definition and Formalisation of Context and Intentions

With regards to this research direction, my main short-term goals are, firstly, to finalise the approach, allowing to improve intentional process models with data about the context gathered from sensors and other devices. The main challenge here is to find a way to associate the context data with event logs. Secondly, the idea is to link the intention mining approaches with the user experience concept. In fact, the current studies on user experience are oriented on ergonomic aspects and the creation of personas. I believe there is a huge potential to improve user experience by using event logs, but it would require corresponding data gathering and storage. The already established conceptual model is currently under the adaptation to the context of employees' experience (ongoing work with IRSN). In the long term, I foresee developing a holistic approach to preparing data for intention and process mining to improve and personalise user experience.

Configuration Methodology Improvement in the Context of Digitalisation

This research axis is mainly oriented on integrating Machine Learning techniques to carry out the configuration. Digital devices produce a vast quantity of data that is very heterogeneous. During the finalisation of the PhD projects of Mustapha Kamal Benramdane and Kaoutar Sadouki, machine learning algorithms will be adopted for the configuration of digital business ecosystems and ICT components in the case of Industry 4.0. Together with the usage of Machine Learning techniques, the corresponding configuration methodology should be adapted too to consider the data flows.

Smart Life and Smart Life Engineering

The main research direction here is to develop the notion of Smart Life. For the short term, I am interested in specifying the definition of Smart according to the other terms like intelligent, autonomous, etc. For the long term, my research project is to contribute to establishing the field of Smart Life Engineering that would aim to develop generic methods, approaches, and tools for optimised resource usage, thus using the principles of context-awareness, modularity, flexibility, and reuse. More precisely, I foresee applying principles and approaches of intention-and context-based configuration in this field. In addition, I'm interested in developing ethical aspects of "Smart". Indeed, several Smart artefacts developed currently are Smart guns and Smart weapons. There is an important ethical question related to the definition of smartness of these objects. I am working with my colleagues from the Smart Life Task Group on a chapter about the definition of Smart.

Conclusion

In this document, I summed up my research contributions. The complexity of information systems has never stopped growing, necessitating the use of methods to aid in their design and development. In recent years, new digital technologies like sensors, mobile devices, and connected objects have become ubiquitous in various industries and daily life. Therefore, it is even more fundamental to develop responsible information systems that can utilise these technologies to improve citizens' lives or help businesses maintain and expand their activities.

To answer this challenge, my work focuses on engineering methods adapted to the context and the users' intentions. My research contributions are organised around three main themes in the field of methods engineering: contextualisation (context modelling and discovery) and intentions mining; the configuration of models and methods to support decision-making; and, more recently, understanding and formalising the field of smart life engineering for a further contextual and intention-based configuration of smart applications. My main goal is to analyse and improve interactions between humans and ICT by providing methodologies adapted to given cases. Considering the growth of digitalisation, these problems have a lot of future research directions.

Figure

  Figure 2.1. Intention Model.

Figure 2 . 2 .

 22 Figure 2.2. Map Model Graphical Representation. An example of a map is given at Figure 2.3.

Figure 2 . 3 .

 23 Figure 2.3. Map Example. This map contains three intentions, namely: Start, Identify DM Requirement, and Stop. There are four strategies: By problem exploring, By variability exploring, Tool-based strategy, and By expertise which correspond to the four sections: <Start; By problem exploring; Identify DM Requirements>, <Start; By variability exploring; Identify DM Requirements>, <Identify DM Requirements; Tool-based strategy; Stop>, and <Identify DM Requirements; By expertise; Stop>. These sections represent four method components.

  research work mostly with other researchers.

Figure 2 . 5 .

 25 Figure 2.5. Overview of the Main Research Topics and Contributions.

Figure 2

 2 Figure 2.6. Main Contributions Organisation in Chapters.

Figure 2 . 7 .

 27 Figure 2.7. Evolution of Research Contributions by Main Topic.

Figure

  Figure 2.8. Evolution of Other Research Supervision.

Figure

  Figure 3.1. Context-Awareness of Teleological Processes.

Figure 3 . 3 .

 33 Figure 3.3. Method Component and Project Context.

Figure 3 . 4 .

 34 Figure 3.4. Context Meta-Model.The central element of this model is the characteristic concept. A set of characteristics constitute the context. Context characteristics indicate specific conditions to use the component. Characteristics are organized into facets for better representation and comprehension. We distinguish two types of characteristics (and consequently two types of facets): generic and specific. The first ones are common for most IS engineering projects; the latter ones vary from one project to another. To distinguish between them is important because of their different identification approaches. The context characteristics set is defined for a method component. Therefore, each method component is described by the valuations of these characteristics (value). In the following, we describe different context characteristics by facets.

Figure 3

 3 Figure 3.6. depicts the UX conceptual model. This model features different UX-related dimensions.Senses, affects, responses, and context are the basic components that could be considered as input/output to feed the user experience. User experience is related to the corresponding objects (used in a specific experience) and subjects (that we foresee larger than the concept of a simple user). It is also connected to a device represented by an ICT component used in the experience (in our work, we consider user experience only supported by digital technologies). User experience could be expected (by the user or by designers) and lived during the experience. In the following, we explain all these concepts.

Figure

  Figure 3.6. User Experience Conceptual Model.

Figure 3 . 7 .

 37 Figure 3.7. Contextualisation Map.

Figure 3

 3 Figure 3.8. IT-PPM Map.

Figure 3

 3 Figure 3.9. Path used in the Contextualisation Map for the IT-PPM Case Study.

Figure 3 .

 3 Figure 3.10. Domain Ontology Construction Approach.

Figure 3 .

 3 Figure 3.11. Event Logs and Sensor Logs Samples.

  Position ontology represents the different parts of the home where the activities can take place, and the sensors are attached. Position ontology is divided into six main position categories: Entrance Position, Exercise Place Position, Bathroom Position, Kitchen Position, and Living Room Position. Each position category has its own instances representing the different fixed locations inside the home. As an illustration, the Kitchen Position contains the different positions inside the conditions, such as the dining table, the fridge, the kitchen shelf, and the kitchen sink.Then, Human ontology is a needed domain to characterise the human profile. It categorises the different person types that perform different activities. It can be divided into two main subdomains: the initial home residents (inhabitants) and the guests.

Figure 3 .

 3 Figure 3.12. Links between the Domains (Ontologies).

Figure 3 .

 3 Figure 3.13. Example on the Link between the Different Domain Ontologies.

Figure 3 .

 3 Figure 3.14. Approach Overview. Data Transformation. Data transformation consists of data cleansing and data manipulation according to our needs. The activity logs and the sensors log contained some noise, in addition to some duplicated records. A data cleansing was established on those logs to remove noise and duplicated data. Hence, we obtained 3154 records in the activity logs and 4332 records in the sensors log in data

Figure 3 .

 3 Figure 3.15. Contextual Process Model.

Figure 3 .

 3 Figure 3.16. Intention Mining Comparison Framework.

Figure

  Figure 3.17. Overview of the Ontology-based Intention Mining Approach for Contextual Recommendations.

Figure

  Figure 4.1. Method Family Meta-Model.

Figure

  Figure 4.2. General Vision of Method Families.

Figure 4 . 3 .

 43 Figure 4.3. Map and Method Family Correspondence.

Figure

Figure 4

 4 Figure 4.4. MADISE DM Method Family (DM Map).

  Figure 4.5. summarizes the Input and Output Data.

Figure 4 . 5 .

 45 Figure 4.5. Input and Output Data of the DM Method Family.

Figure

  Figure 4.6. Decision-Making Ontology.

Figure 4 . 7 .

 47 Figure 4.7. DMO: Application to the ERP Tool Selection Case.

  DMO elements are organized into DM method components in order to explicit the relationship with the context and intentions. The DM component model is shown in Figure4.8. It includes six concepts: component, actor, intention, concept, activity, and context.

Figure

  Figure 4.8. DM Method Component.

Context.

  The context describes conditions in which decisions are made. The context is represented as a taxonomy of characteristics, such as cost, time, etc. These meta-concepts are related to each other as follows. An actor has the intention to make a decision in order to resolve a problem. He defines several DM concepts and carries out different DM activities. DM activities use various concepts and produce other ones. Both DM concepts and activities are related

Figure 4

 4 Figure 4.9. represents the DM concepts used in the REDEPEND approach.

Figure

  Figure 4.9. DMO: Application to the REDEPEND Approach.

Figure 4 .

 4 Figure 4.10. illustrates DM method components used in the REDEPEND approach. REDEPEND implements the AHP method and has three related components, which are used for the pair-wise comparison of tasks and pair-wise comparison of criteria (two instances of PWComponent), and for the computation of candidates ranking (an instance of CompComponent).

Figure 4 .

 4 Figure 4.10. REDEPEND DM Method Components.We detail the PWComponent dealing with alternatives ranking in Figure4.11.

Figure 4 .

 4 Figure 4.11. PWComponent of the REDEPEND Approach.

Figure 4 .

 4 Figure 4.12. Method Family Configuration Map.

  Figure 4.13.

Figure 4 .

 4 Figure 4.13. Configuration Types.

Figure 4 .

 4 Figure 4.14. The Crews-L'écritoire Method (the CL Map).

Figure 4 .

 4 Figure 4.15. shows the graph meta model.

Figure 4 .

 4 Figure 4.15. Meta Model of Graph.

Figure

  Figure 4.16. Graph Example.

Figure 4 .

 4 Figure 4.17. MAP and Graph Correspondence.

  Figure 4.18. Map of the O* Model Construction Process.

  Figure 4.19.) represents the refined section <Start, Class Driven Strategy, Construct Class>.

Figure

  Figure 4.19. IAG1 Section Refined Map.

  Inclusion criteria are the following: search string ((industry 4.0/Smart industry/Smart factory OR manufacturing OR production OR IOT) AND (intent-based/oriented OR intention-based/oriented OR goal-based/oriented OR objective-based/oriented)), published year (between 2010 in 2022), subject categories (AI and Image Processing, Computer Software, Distributed Computing, IS, Manufacturing Engineering), search clause (title and abstract).Then, we applied the exclusion criteria. Exclusion criteria include the lack of explicit mention of intention-based approaches in the title or abstract. We obtained 80 articles divided into several subdomains of I4.0. The process with criteria is shown in Figure4.21.

Figure 4 .

 4 Figure 4.21. Inclusion and Exclusion Criteria Applied.

Figure

  Figure 4.22. Industry 4.0 Impact Propagation Model.

I4. 0

 0 Component. I4.0 components correspond to various elements or components of digital technologies introduced into an organisation. An I4.0 component could be atomic or a composite one. To express the latest one, we use a recursive aggregation link on the I4.0 component. The I4.0 component has two main attributes: descriptor and body. A descriptor allows to identify the given component. For instance, in the RAMI4.0 framework, it corresponds to the Administration Shell [RAMI4.0, 2015]. The body is the core of the I4.0 component, like in RAMI4.0 [RAMI4.0, 2015]. Impact. The impact represents an association class between an I4.0 component and an EA model element. Each I4.0 component can impact a number of EA model elements, and each Model element can be impacted by several I4.0 components. For each, we can identify the type of impact: direct or indirect, and the effect of impact. With regard to the impact type, the direct impact is when the I4.0 component directly touches a model element. The indirect impact is deduced from the directly impacted model element and from other model elements related to the directly impacted element by different relationships. Direct or indirect impacts may have different effects on model elements.

Figure 4 .

 4 Figure 4.23. Process of the Industry 4.0 Impact Propagation Model Application. Identify the direct impact(s). Depending on the description of the I4.0 component, define the EA model element(s) which are directly touched and associate the corresponding impact effect. The EA Models and the proposed propagation model constitute the Inputs of this step.

Figure 4 .

 4 Figure 4.24. Search String Used on Scopus API.

Figure 4 .

 4 Figure 4.25. Overview of the Matchmaking Approach. The preparation phase contains the data preparation steps: missing data imputation and model training. Missing data can have many reasons, namely that it has not yet been completed, does not yet exist, or is considered confidential or private by the organisation that holds it. Multiple Imputation by Chained Equation (MICE) is an algorithm that allows imputing missing data in a data set through different strategies.

Figure 4 .

 4 Figure 4.26. Entity-Relationships (ER) diagram of the database.

Figure 4 .

 4 Figure 4.27. shows the confusion matrix of results obtained for a run without data imputation. In fact, in these tests, the missing data were imputed only by the mean value of the variable under consideration. The left matrix on Figure 4.27. relates to the results of the Decision Tree algorithm with general imputation. We can observe the existence of 10 true negatives and 2 false positives. The matrix on the right illustrates the results of the Logistic Regression algorithm for matchmaking with general imputation. We can observe the presence of 100 true negatives and 83 false positives.

Figure 4 .

 4 Figure 4.27. Confusion Matrix Using General Imputation Algorithm.

Figure 4 .

 4 Figure 4.28. depicts the confusion matrix of results obtained for execution with MICE data imputation. The missing data algorithm uses mean imputation as a base imputation. The left matrix in Figure 4.28. shows the confusion matrix of the results obtained with the Decision Tree algorithm. We can observe the obtaining of no false positives and no true negatives. This means that the Decision Tree algorithm is more efficient with the imputation of missing data, unlike the previous run carried out with general imputation. The matrix on the right of Figure 4.28. concerns the results of the Logistic Regression algorithm with MICE imputation. This matrix contains no false positives and no true negatives.

Figure 4 .

 4 Figure 4.28. Confusion Matrix Using MICE Algorithm.

Figure 4 .

 4 Figure 4.29. List of Customers as Matchmaking Output. The recommendation system not only provides names of organizations but also other data concerning said organizations (See Figure 4.30).

Figure 4 .

 4 Figure 4.30. Customer Information.

Figure 5

 5 Figure 5.1. System-Oriented Vision of Smart Life.

Figure

  Figure 5.3. Smart Life Domains. Smart applications for persons contain applications oriented on the personal life of humans, like Smart healthcare, Smart home (Smart living), Smart welfare, etc. (See Figure 5.4.).

Figure 5 . 4 .

 54 Figure 5.4. Smart Life Applications for Persons. Smart applications for environment include different topics related to the environment study and preservation: Smart natural resource management, Smart earth, Smart disaster management, and Smart space exploration. (See Figure 5.5.).

Figure

  Figure 5.5. Smart Life Applications for Environment.

Figure 5 . 6 .

 56 Figure 5.6. Smart Life Applications for Society.

Figure 5 . 7 .

 57 Figure 5.7. Smart Life Applications for Enterprises.

  papers), Smart industry dominates (891 papers), essentially with Smart energy-related topics, followed by Smart agriculture (104 papers), Smart transportation (78 papers), and Smart business management (60 papers). Smart home and Smart healthcare are equally represented in Smart applications for persons (191 and 190 papers respectively over 408), with a little part for Smart welfare. Smart applications for Environment are only represented by 16 papers, half of them focused on Smart natural resource management (9 papers). Smart city is taking the big part of the Smart applications for society (384 papers over 440), followed by Smart education (43 papers).

Figure

  Figure 5.8. Smart Domains Distribution.

Figure

  Figure 5.9. Smart Domains Distribution.

Figure 5 .

 5 Figure 5.10. Requirements Hierarchy Pyramid.

  , qui est déjà accepté par Springer pour publication et qui sera finalisé en 2023. Je suis également co-organisatrice de trois ateliers sur ce sujet (ISESL'20 En outre, j'ai lancé un projet exploratoire inter-équipes du laboratoire CEDRIC (Centre d'Etudes et de Recherche en Informatique et Communications) du CNAM financé à 8 k€. Le but de ce projet est de financer le développement de collaborations par le financement de voyages afin de faciliter la rédaction de chapitres du livre sur ce sujet.

http://isesl20.cnam.fr/, ISESL'22 -http://isesl22.cnam.fr/, et ISESL'23 -http://isesl23.cnam.fr/). J'ai effectué deux séjours scientifiques à l'Université d'Utrecht (en octobre 2022 et février 2023) et j'ai organisé deux séjours scientifiques du Pr. S. Brinkkemper au CNAM (en avril 2022 et en avril 2023) et deux séjours scientifiques du Pr. J. Murray au CNAM (en novembre 2022 et en mars 2023) pour travailler sur ce projet.

Table 2 .1. Evolution of the Contribution Types.

 2

  Table 2.2. contains statistics about collaborative research including external to my university collaborations and international collaborations.

Table 2 .2. Data about Collaborative Work. Contribution type Total Number Number of contributions in collaboration with researchers external to my university

 2

	Number of
	contributions with
	international
	collaboration

Context Modelling Context Discovery Intention Discovery Context-and Intention-based Method Configuration Configuration of Digital Components Organisational Entities Configuration using ML Smart Life Definition and Engineering

			Definition of	Definition of
			«Smart» and	Sentient
			Smart Life	Requirements
						Smart Life
						Identity Protection
						ML-based	Using SSI in IoT
						Configuration
	Graphs on MC methods and Configuration Based	SME Approach Method Family	Intention-based	into EA I4.0 Components Integration of	of DBE
			Configuration of
	Decision-Making		I4.0 Components
	Ontology
						Configuration
						Ontology-based Intention
						Mining Approach for
						Contextual
	Generic Context				Recommendations
	Model				Intention Mining
						Approaches
	Modelling UX		Context Definition Approach	Sensor Logs with Data from Process Enrichment	State-of-the-Art
			Context Extraction
			from Sensor Logs
						Contextualisation

Legend:

Semantic link between main topics

Semantic link between contributions inside a topic

Elena Kornyshova 27/158 HDR

• Mohamed Amine El Afrit, 2016

  . Mohamed analysed the impact of digitalisation and uberisation on the business models of the existing organisations by demonstrating the advantages and risks of not considering this evolution[START_REF] Afrit | [END_REF].

	• Shurooq Alhodar, 2019. Shurooq analysed the existing approaches allowing personalising user
	experience using museum visit games and suggested a comparison framework for these
	approaches [Alhodar, 2019].
	• Eva Friggiati Chateignon, 2021. Eva conducted a large empirical study to identify requirements
	for user experience tools in case of usage of scientific and technological equipment. She
	identified and described a set of personas -user types of scientific employees [Friggiati E.,
	2021].
	• Lydia Ouaili, 2021. Lydia investigated Intelligent Decision-Making in Digitalized Processes
	[Ouaili, 2021].
	• Kahina Machouche, 2021. Kahina studied how emotions are analysed in social networks
	[Machouche, 2021].
	• Anis Yahiaoui, 2021. Anis worked on the application of Machine Learning and Artificial
	Intelligence for Industry 4.0 [Yahiaoui, 2021].
	• Ilyes Benni, 2022. Ilyes conducted a detailed study of the existing literature on decision-making
	in industrial IoT using the systematic literature review methodology. He developed a
	comparison framework and defined evolutions and future direction of decision-making
	approaches in this field [Benni I., 2022].
	• Lilia Meziani, 2022. Lilia analysed different data types in digitalised processes and developed
	a technique to help in decision-making in processes implemented with blockchains [Mezani,
	2022].
	• Anxhela Joti, 2023. Anxhela investigated the existing literature to identify and compare
	different sentiment analysis approaches to detect emotions on Twitter [Joti, 2023].
	• Hiba El Haouaji, 2023. Hiba prepared a state-of-the-art on emotion analysis of social media
	users [El Haouaji, 2023].
	• Léa Da Costa, 2023. Léa worked on the state-of-the-art on sensors and IoT used to detect
	health-related risks for employees [Da Costa, 2023].
	2.3.3 Projects Direction
	I have initiated and conducted several projects. The IRSN, Airbus, and Smart Life projects are the most
	important.

IRSN (Institut de Radioprotection et de Sûreté Nucléaire), (Institute of Radiation Protection and

	Nuclear Safety). A partnership agreement between CNAM and IRSN was signed in November 2021 with
	a financial flow of €78k to CNAM. I have initiated this project. I work with the IRSN team to develop
	the methodological aspects of building an extensive immersive platform for scientific and technological
	equipment. The scientific supervision includes a Master 2 research internship already carried out in
	2020-2021 (Eva Friggiati Chateignon)

Life and Smart Life Engineering. This

	project contributes to the development of the field of
	Smart Life Engineering. Motivated by sustainable, human-oriented, and sentient development of
	Smart applications, we are observing the emergence of a novel scientific domain around Smart
	applications and devices. We aim at the systematisation of existing knowledge and formulating
	common principles, design and development methods, with associated technologies for applications
	improving the life of Humans. We call this domain Smart Life Engineering. Smart Life is defined as a
	domain that embraces all Smart applications and Smart artefacts for the purpose of an enriched
	experience from the personal, societal, environmental and enterprise perspectives. Examples of
	applications of Smart Life are Smart cities, Smart manufacturing, Smart homes, Smart healthcare, and
	so on. The goal of our project is threefold: (i) establish the scientific domain of Smart Life Engineering;
	(ii) develop a scientific community around Smart Life Engineering; and (iii) organise scientific events
	and lead publication initiatives. I am the main initiator and coordinator of the project. I co-authored
	several publications related to this topic [Kornyshova et al., 2023c] [Kornyshova et al., 2022a]
	[Kornyshova et al., 2022d] [Kornyshova et al., 2021a] [Elali et al., 2023b] [Elali et al., 2022a] [Elali et al.,
	2022b]. Together with my colleagues, I initiated a Task Group on Smart Life Engineering within IFIP
	WG8.1, accepted in June 2022. Dr Rébecca Deneckère and I are the chairs of this working group. We
	have launched a book entitled "Smart Life and Smart Life Engineering: Current State and Future Vision"
	[Kornyshova et al., 2023a], which is already accepted by Springer for publication and will be finalised
	in 2023. I am also a co-organiser of three workshops on this topic (ISESL'20 http://isesl20.cnam.fr/,
	ISESL'22 -http://isesl22.cnam.fr/, and ISESL'23 -http://isesl23.cnam.fr/). I had two scientific journeys
	at the University of Utrecht (Oct 2022, Feb 2023) and hosted two scientific stays of Pr. S. Brinkkemper
	at CNAM (Apr. 2022, Oct. 2023) and two scientific stays of Pr. J. Murray (Nov 2022, March 2023) to
	work on this project. In addition, I launched an Inter-team exploratory project of the CEDRIC laboratory
	(Centre d'Etudes et de Recherche en Informatique et Communications) of the CNAM funded at €8k.
	This project aims to finance the development of collaborations through travel funding to facilitate the
	writing of chapters of the book on this topic. I started this project in 2019 together with Prof. Eric
	Gressier-Soudan. In 2023 we are 35 to contribute to the book. This shows the constitution of a scientific
	community around the Smart Life topic.

Table 3 .1. Comparison of Approaches dealing with Context in ME Field.

 3

	Approach			Characteristics
	Goal/	Organiza-	Technical	Human	Domain	External	Process	Product
	Intention	tional
	Reuse

Table 3 .2. Organizational Facet Characteristics.

 3

	Characteristic	Indicator	Type	Value domain
	Management	Management	Quantitative 3-grade scale
	commitment	commitment degree	Qualitative	ENUM:{low, normal, high}
	Importance	Importance degree	Quantitative 3-grade scale
			Qualitative	ENUM:{low, normal, high}
	Impact	Impact degree	Quantitative 3-grade scale
			Qualitative	ENUM:{low, normal, high}
	Time pressure	Time pressure degree	Quantitative 3-grade scale
			Qualitative	ENUM:{low, normal, high}
	Shortage of resources Shortage of resources	Quantitative 3-grade scale
		degree	Qualitative	ENUM:{low, normal, high}
	Level of innovation	Level of innovation	Quantitative 3-grade scale
		degree	Qualitative	ENUM:{low, normal, high}
	Size	Size	Quantitative 3-grade scale
			Qualitative	ENUM:{low, normal, high}
	Cost	Cost	Quantitative REAL
			Qualitative	ENUM:{low, normal, high}
	Nature of limited	Nature of limited	Qualitative	ENUM:{financial, human, temporal,
	resources	resources		informational }
	Innovation nature	Innovation nature	Qualitative	ENUM:{business innovation, technology
				innovation}
	Duration	Duration	Quantitative REAL

Table 3 .3. Human Facet Characteristics.

 3

	Characteristic	Indicator	Type	Value domain
	Resistance	Resistance degree	Quantitative 3-grade scale
			Qualitative	ENUM:{low, normal, high}
	Conflict	Conflict degree	Quantitative 3-grade scale
			Qualitative	ENUM:{low, normal, high}
	Expertise	Expertise degree	Quantitative 3-grade scale
			Qualitative	ENUM:{low, normal, high}
	Clarity	Clarity degree	Quantitative 3-grade scale
			Qualitative	ENUM:{low, normal, high}
	Stability	Stability degree	Quantitative 3-grade scale
			Qualitative	ENUM:{low, normal, high}
	Expert role	Expert role	Qualitative	ENUM:{tester, developer, designer, analyst}
	User involvement	User involvement	Qualitative	ENUM:{real, virtual}
	Stakeholder number Stakeholder number	Quantitative NUMBER

Table 3 .4. Application Domain Facet Characteristics.

 3

	Characteristic	Indicator	Type	Value domain
	Formality	Formality degree	Quantitative 3-grade scale
			Qualitative	ENUM:{low, normal, high}
	Relationships	Relationships degree	Quantitative 3-grade scale
			Qualitative	ENUM:{low, normal, high}
	Dependency	Dependency degree	Quantitative 3-grade scale
			Qualitative	ENUM:{low, normal, high}
	Complexity	Complexity degree	Quantitative 3-grade scale
			Qualitative	ENUM:{low, normal, high}
	Repetitiveness	Repetitiveness degree	Quantitative 3-grade scale
			Qualitative	ENUM:{low, normal, high}
	Variability	Variability degree	Quantitative 3-grade scale
			Qualitative	ENUM:{low, normal, high}
	Application type	Application type	Qualitative	ENUM:{intra-organization, inter-
				organization, organization-customer }
	Application	Application technology Qualitative	ENUM:{application to develop includes a
	technology			database, application to develop is
				distributed, application to develop includes
				a GUI}
	Dividing project	Dividing project	Qualitative	ENUM:{one single system, establishing
				system-oriented subprojects, establishing
				process-oriented subprojects, establishing
				hybrid subprojects}
	Variable artefacts	Variable artefacts	Qualitative	ENUM:{organisational, human, application
				domain, and development strategy}

Table 3 .5. Development Strategy Facet Characteristics.

 3

	Characteristic	Indicator	Type	Value domain
	Source system	Source system	Qualitative	ENUM:{code reuse, functional domain
				reuse, interface reuse}
	Project organization	Project organization	Qualitative	ENUM:{standard, adapted}
	Development strategy Development strategy	Qualitative	ENUM:{outsourcing, iterative, prototyping,
				phase-wise, tile-wise}
	Realization strategy	Realization strategy	Qualitative	ENUM:{at once, incremental, concurrent,
				overlapping}
	Delivery strategy	Delivery strategy	Qualitative	ENUM:{at once, incremental, evolutionary}
	Tracing project	Tracing project	Qualitative	ENUM:{weak, strong}
	Goal number	Goal number	Quantitative NUMBER
			Qualitative	ENUM:{one goal, multi-goals}

Table 3 .6. Specific Map Characteristics.

 3

	Characteristic	Indicator	Type	Value domain
	Goal satisfaction	Goal satisfaction degree Quantative	3-grade scale.
	degree		Qualitative	ENUM:{low, normal, high}
	Goal achievement	Goal achievement	Quantative	3-grade scale
	degree	degree	Qualitative	ENUM:{low, normal, high}
	Section satisfaction	Section satisfaction	Quantative	3-grade scale
	degree	degree	Qualitative	ENUM:{low, normal, high}
	Section completeness	Section completeness	Quantative	3-grade scale
	degree	degree	Qualitative	ENUM:{low, normal, high}

Table 3 .7. Correspondence between the Proposed Typology and Existing Context Elements.

 3

	Proposed Typology	Context Elements (cf. Table III.3.1.)
	Organizational	Organizational
	Human	Human
	Application domain	Domain
	Development strategy	Technical
	Intentional	Goal/ Intention
	Satisfaction	External, Process, Product
	Decisional	Process, Product
	Internal	Technical, Process, Product

Table 3 .8. Contextualisation Map Sections.

 3 All these sections are explained below. Operators are defined for each section in order to indicate how to proceed for carrying out its execution. The generic characteristics deduction is based on the context typology. This section gives a selection of characteristics carried out by the IS method engineer.

	Section	<Source intention, Strategy, Target intention >
	S 1	<Start, By deduction, Define method context>
	S 2	<Start, By deduction, Define method component context>
	S 3	<Start, By generation, Define method context>
	S 4	<Start, By generation, Define method component context>
	S 5	<Define method context, By instantiation, Define method component context>
	S 6	<Define method component context, By assembly, Define method context>
	S 7	<Define method context, By completeness, Stop>
	S 8	<Define method component context, By completeness, Stop>

<Start, By deduction, Define method context>.

Table 3 .

 3 3. and Table 3.4. as generic characteristics to specify the context of the method. The engineer has applied the operator Select Context Characteristic () in order to define a sub-set of generic context according to the given project. He has selected three generic characteristics for this example: Expertise degree, Expert role, and Application type (Table3.10.).

	By requirement consideration
					1
	Start	By goals-oriented criteria identification
	3	10	Identify project over criteria By applying function By lack of goals-coverage 8	project Prioritize By ad-hoc classification 2 4	portfolio By modulating project development By canceling project
	Evaluate project	7	By project completeness By controlling goal 9 achievement	By project portfolio completion 6	Stop 5
	Start	By generation	Define method component
	S1 By deduction	S3	Define By instantiation S5	context By completeness S8
					method context	Stop

characteristics

Table 3 .10. Generic Characteristics.

 3 The engineer also uses specific context characteristics(cf. Table 3.11.). This specific context is depicted by the constraints of the business environment (the design situation), the intention of the designer and the strategy for reaching the intention. So, the three operators were applied to identify the specific characteristics. Analyse Method Goal () is used to identify the Intention which is related to the intentional type of specific characteristic. Measure Method Satisfaction () allows defining the Situation in the Satisfactional facet (as it describes the satisfaction degree of the previous intention). Finally, Analyse Method Argumentation () defines the Strategy in the decisional facet of the specific characteristic.

	Characteristic	Value domain
	Human facet
	Expertise degree	{low, normal, high}
	Expert role	{tester, developer, designer, analyst}
	Application domain facet
	Application type	{intra-organisation application, inter-organisation
		application, organisation-customer application}
	Definition of the specific characteristics (S 3 ).

Table 3 .11. Specific Characteristics.

 3

	Characteristic	Value domain
	Intentional facet
	Intention	TEXT
	Satisfactional facet
	Situation	TEXT
	Decisional facet
	Strategy	TEXT

Second step (S 5 : Definition of Method Components Context). The

method context defined at the previous step is now instantiated for each component. A value is affected to each characteristic in order to help the case process execution guidance. The following operators are applied to each method characteristic: Retain Context Characteristic () and Attribute a Value to Context Characteristic (). The results are presented in Table

Table 3 .12. Specific Characteristics Instantiation.

 3

	Section	degree Expertise	role Expert	Type Appli.	Situation Intention Strategy
	S1 <Start; By goals-oriented criteria	Normal Analyst	Intra-	Problem	Identify	By requirement
	identification; Identify project>		designer	Org.	statement	project	consideration
	S2 <Identify project; By ad-hoc	Low	Analyst	Intra-	Project	Prioritize	By ad-hoc
	classification; Prioritize project>		designer	Org.	identified	project	classification
	S3 <Identify project; By goals-	High	Analyst	Intra-	Project	Evaluate	By goals-oriented
	oriented criteria identification;		designer	Org.	identified	project	criteria identification
	Evaluate project>
	S4 <Prioritize project; By	High	Designer Intra-	Project	Prioritize	By modulating project
	modulating project			Org.	prioritized	project	development
	development; Prioritize project>
	S5 <Prioritize project; By cancelling	Low	Designer Intra-	Project	Stop	By canceling project
	project portfolio; Stop>			Org.	prioritized		portfolio
	S6 <Prioritize project; By project	Low	Designer Intra-	Project	Stop	By project portfolio
	portfolio completion; Stop>			Org.	prioritized		completion
	S7 <Prioritize project; By	Low	Designer Intra-	Project	Evaluate	By controling goal
	controlling goal achievement;			Org.	prioritized	project	achievement
	Evaluate project>
	S8 <Evaluate project; By applying	Normal Analyst Intra-	Project	Prioritize	By applying function
	function over criteria; Prioritize			Org.	evaluated	project	over criteria
	project>
	S9 <Evaluate project; By project	Low	Designer Intra-	Project	Stop	By project
	completeness; Stop>			Org.	evaluated		completeness
	S10 <Evaluate project; By lack of	Normal Analyst Intra-	Project	Identify	By lack of goal
	goals-coverage; Identify project>			Org.	evaluated	project	coverage

  Association rule mining is the technique of finding relationships between different items. It is commonly used in Market Basket Analysis, identifying which items are frequently purchased together for marketing purposes. It is the process of finding frequent patterns, associations, causal structures, and correlations within different datasets existing in various types of databases like transactional

			Domain Ontology Construction
	Events Log	1	Activity Ontology	Activity Ontology
	Sensors Data	2	Sensor Ontology	Sensor Ontology
			Domain	Domain
			Ontology	Ontology

databases, relational databases, or any other form of databases

[START_REF] Zaki | Data Mining and Analysis: Fundamental Concepts and Algorithms[END_REF]] [Sunita et al., 2012]

. The purpose of association rule mining is to find the rules that allow us to guess the appearance of a specific item after the occurrences of other items in the transaction. It is one of the top concepts of machine learning rule-based techniques that discover interesting relations between items in big

Table 3 .13. Sample of Activity and Sensor Mapping. Activity Sensor

 3

	Brush Teeth	Position Sensor Water Use Sensor
	Change Clothes	Position Sensor Pressure Bed Sensor
	Clean	Position Sensor Home Aired Sensor
	Close or Open	Windows Sensor
	Windows	Blinds Sensor
		Unwashed Dishes Sensor
	Washes Dishes	Position Sensor
		Water Use Sensor
	Eat Cold Meal	Food Sensor
	Get Food from Fridge	Fridge Door Contact Sensor Position Sensor

Table 3 .14. Apriori Experiments. Experiment Minimum support Confidence # of obtained rules

 3

	First Experiment	0.15	80%	56 rules
	Second Experiment	0.05	80%	8565 rules
	Third Experiment	0.03	80%	34623 rules

Table 3 .15. Sample of the Obtained Rules.

 3

	Rule

Table 3 .16. Details of the Object Dimension.

 3

	Attributes		Values
	Structuredness	ENUM (Individual, Model)
	Intention Taxonomy	SET OF (ENUM (Action/Semantic; Soft/Hard; Uni-token/Multi-token;
			Informational/ Ambiguous/Navigational/Transactional; Explicit/Implicit;
			Objective/Subjective; Research/Purchase; Collective/Individual))
	Intention	Modelling	ENUM (Map, I*, Kaos, linguistic, Schemata)
	Formalism

Table 3 .17. Details of the Usage Dimension.

 3 As shown in Table3.18., the Method dimension of intention mining can be further refined with the following attributes: Machine Learning to characterise the use of machine learning techniques; Automation method, which indicates the degree of automation used in the method; Observation record type, that indicates what the input of the method is; Mathematical method, that characterises the theoretical foundation of the mining technique; and Classificationbased and Ontology-based, which indicate whether the method exploits a classification technique and ontology.

	Attributes		Values
	Usage Goal		ENUM (Discovery, Recommendation, Conformance, Enhancement)
	Domain	of	ENUM (Information Retrieval, Robotics, Video, Network forensics,
	application		Security, Bioinformatics, Learning, Business Process Modelling,
			Requirements Engineering, Virtual Consumption, Map Visualisation,
			Game, Database, e-Government, Healthcare, …)
	Source Artefact ENUM (Individual, Group)
	Target Artefact	ENUM (Individual, Group)
	The Method Dimension.

Table 1 .18. Details of the Method Dimension.

 1 Intention mining approaches can be further characterised in terms of the techniques and tools needed to put them into practice. As Table3.19. shows, the Tool Dimension of the intention mining classification framework has six attributes: mathematical model, classification type, algorithm name, ontology name, support, and tool name.

	Attributes	Values
	Machine Learning	ENUM (Supervised, Unsupervised, Semi-supervised, NULL)
	Automation method	ENUM (Manual, Semi-automatic, Automatic)
	Observation record	ENUM (Log, Contextualized trace)
	type
	Mathematical	ENUM (Probabilistic, Statistic, Deterministic, Fuzzy, NULL)
	method
	Classification-based	BOOLEAN
	Ontology-based	BOOLEAN
	The Tool Dimension.

Table 3 .19. Details of the Tool Dimension.

 3

	Attributes	Values
	Mathematical model	ENUM (Bayesian Model, Hidden Markov Model, Conditional
		Random Field, NULL)
	Classification type	ENUM (manual, automatic)
	Algorithm name	STRING
	Ontology name	STRING
	Support	ENUM (sensor, robot, microphone, internet navigation, NULL,
		etc.)
	Tool name	STRING

Table 3 .20. IM Comparison Framework Application to the Selected IM Approaches.

 3

		[Xiao et al.,	[Breazeal et al.,	[Hu et al., 2009] [Tang et al., 2012]	[Xia et al.,
		2005]	2002]			2018]
	Object Dimension
	Structuredness	Individual	Individual	Individual	Individual	Cluster
	Intention taxonomy Query intent	"Approval,	Query intent	Keyword	User intent
			prohibition,
			attention,
			comfort, neutral"
	Intention Modelling	Linguistic	Linguistic	Linguistic	Linguistic	Linguistic
	formalism
	Usage dimension
	Usage Goal	Discovery of	Discovery of	Discovery of	Recommendation	Discovery
		Click Graphs	emotional intent	category	of images
	Domain of	Information	Robot speech	Information	Internet search	Information
	application	retrieval		retrieval	image	retrieval
	Source Artefact	Group	Individual	Group	Individual	Group
	Target Artefact	Group	Individual	Individual	Individual	Individual
	Method Dimension
	Machine learning	Semi-supervised	-	-	-	Semi-
	Method					supervised
	Automation	Semi-automatic	Automatic	Automatic	Automatic	Semi-
	method					automatic
	Observation record	Query /	Sentence	`Search query log	Query keywords /	Search query
	type	clickthrough		/ category graph /	query image	log
		data		article graph
	Mathematical	-	-	Probabilistic	Probabilistic	Probabilistic
	method
	Classification-based	1	1	1	1	1
	Ontology-based	0	0	1	0	0
	Tool Dimension
	Mathematical	-	Gaussian model Markov random	Word probability	-
	model			walk	model
	Classification type	Content based	EM algorithm /	Intent classifier	one-class SVM	Intent
		classification	Kurtosis-based		classifier	detection
		(maximum	approach			classifier
		entropy
		classifier)
	Algorithm name	"Algorithm 1" /	-	"Algo 1" / "ESA" /	-	"Algorithm 1" /
		"Algorithm 2"		"Intent predictor"		"Algorithm 2"
	Ontology name	-	-	Wikipedia articles	-	-
				and categories
				link
	Support	Internet	Microphone	Internet	Internet navigation	Internet
		navigation		navigation		navigation

  Scenario" and "Conceptualize a Scenario". In this example, we have selected six indicators for carrying out the configuration: Expert role, Expertise degree, Formality degree, Complexity degree, Relationships degree and Goal achievement degree. Table4.1. illustrates these indicators applied to the method components.

					Start
			Template driven strategy	S1	Initial goal identification strategy
	Goal structure driven strategy	S2	S3	S4	Linguistic strategy
	Write a Scenario Template driven strategy	S5 Free prose strategy	Elicit a Goal strategy Composition Conceptualize Refinement discovery strategy Discovery strategy Dicovery S10 Alternative S6 S9 S11
	S8	S7	Manual strategy		a Scenario
		Computer supported strategy	Completness S12	Stop
						strategy
	Elena Kornyshova			87/158	HDR

", "Write a

Table 4 .1. Indicator's Values.

 4

	Method Components	Expert role	Expertise degree	Formality degree	Goal Achievement degree	Relationship degree	Complexity degree	Duration
	S1	Analyst	1					15 mn
	S2	Analyst	3	3	Low			10 mn
	S3	Analyst	2	3	Low			10 mn
	S4	Analyst		2	Low			15 mn
	S5	Analyst	3	3	High			10 mn
	S6	Analyst	1	1	High			5 mn
	S7	Analyst	2	1	High			10 mn
	S8	Analyst	1	3	High			15 mn
	S9	Analyst			High	Medium	Medium	20 mn
	S10	Analyst			High	Medium	Medium	20 mn
	S11	Analyst			High	Medium	Medium	20 mn
	S12	Analyst		1	High			5 mn

Table 4 .2. Normalized values of Duration, Expertise degree and Formality degree.

 4

	Indicator	S2	S3	S4	S5	S6
	Duration	10	10	15	10	5
	Formality degree	3	3	1	3	1
	Expertise degree	3	2	1	3	1
	Normalized values
	Duration degree	0,5	0,75 0,75	0,5	0,25
	Formality degree	1	1	0,33	1	0,33
	Expertise degree	1	0,67 0,33	1	0,33
	Aggregated Value	2,5	2,42 1,41	2,5	0,91

Table 4 .3. Aggregated Value of Expertise degree and Formality degree of the CL Map.

 4

	Indicator	S1 S2 S3 S4 S5 S6 S7 S8 S9 S10 S11 S12
	Formality degree

Table 4 .4. Correspondences between Maps and Graphs.

 4

	Map concept	Graph concept	Correspondance
	Map	Graph	Each map will be represented as a specific graph.
	Section	Vertex	The executable service in a map is the section, which is represented as
			a vertex in a graph.
	Sequence	Edge	The concept allowing the navigation in a map is the sequence of
			sections in the map, which may be represented as edges in a graph.
	Indicator	Weight	The guidance parameters called indicators in the map are the weights
			in a graph.
	Path	Walk	The set of section sequences (path) is clearly a graph walk.
	Thread	Set of adjacent
		vertices

Table 4 .6. Normalized values of Duration, Expertise degree and Formality degree.

 4

	Indicator	S1	S2	S3	S4	S5	S6	S7	S8	S9	S10 S11 S12
	Duration	15	10	10	15	10	5	10	15	20	20	20	5
	Formality degree

Table 4 .7. Points of Impact of RAMI4.0 on EA Components from TOGAF.

 4 from 35 TOGAF 9.2 meta-model entities: Data Entity, Information System Service, Logical Technology Component, Physical Application Component, Physical Technology Component, Process, and Technology Service. To identify indirect impacts, we used the TOGAF 9.2 meta-model relationships(cf. Section 30.7 of TOGAF 9.2 [TOGAF, 2020], pages 314-317). For each previously identified direct impact, we have repeated the following procedure: enumerate all other entities related by at least one relationship from the meta-model and its textual description (more complete than the graphical representation of the meta-model); if more than one relationship is present between two entities, enumerate all of them; qualify them as indirect impacts; for each indirect impact, select one or more possible impact effects; for impact, identify the corresponding EA model and EA perspective. For instance, Process is related to Control by "Is guided by" relationship. Due to the nature of this relationship, we deduce that the Control entity could only be updated further to the changes in a Process Entity. In TOGAF, the Control entity is a part of the Process Modelling Extension (EA model) within the Business Architecture perspective. Table4.8. illustrates the first-level impact. The next levels are done in the same manner.Group the identified impacts by EA model. Identified impacted TOGAF Entities were grouped into TOGAF Models (illustrated in Table4.8.

		Impact Points
		Architecture	Business		Information	Technology	Architecture
		Principles,	Architecture		Systems	Architecture	Realisation
		Vision, and				Architecture
	Axe	Requirements
		Preliminary	Architecture	Vision	Architecture Requirement	s Motivation	Organisation	Behaviour	Data	Application
	AXE I:
	HIERARCHIE
	Connected world
	Enterprise
	Work Center (i4.0 component)	IP		IP				IP	IP	IP
	Station (i4.0 component)	IP		IP				IP	IP	IP
	Control Device (i4.0 component)	IP		IP				IP	IP	IP
	Field Device (i4.0 component)	IP		IP				IP	IP	IP
	Product (i4.0 component)
	AXE II:
	ARCHITECTURE
	Business		IP		IP	IP	IP	IP
	Function (i4.0 component)				IP	IP	IP	IP	IP
	Information (i4.0 component)							IP	IP
	Communication (i4.0 component)								IP
	Integration (i4.0 component)								IP
	Asset (i4.0 component)
	AXE III:
	PRODUCT LIFE CYCLE
	Type
	Design,	Plan,				IP	IP	IP		IP
	development	simulation,
	(i4.0	prototype
	component)
	Maintenance	Update,				IP	IP	IP		IP
	usage	manual
	(i4.0	instruction,
	component)	maintenance
		cycles
	Instance
	Production	Product				IP	IP	IP	IP	IP	IP
	(i4.0	elaboration +
	component)	data
	Maintenance	Facility				IP	IP	IP	IP	IP	IP
	usage	Management
	(i4.0
	component)
	Identify indirect impacts.

Smart Artefacts Smart Applications Smart Life

					Smart Transportation
					Smart car	Smart ship
	Smart	Smart Home			Smart …
	window Smart	Smart Lighting System	Smart City	Smart parking
		…
				Smart
				…
	Figure 5.2.

Smartness Degrees according to Data and Processor Complexity.

  . Smart Life can be seen as a societal domain that unifies all in initiatives to apply Smart artefacts and applications in any setting. We also use the term of Smart Life as a comprehensive scientific research domain that includes all research areas with studies into Smart technology, artefacts, and applications.Smart Life Engineering as the use of scientific principles to design, build, implement and evolve Smart Life applications. SLE can therefore be seen as overlapping with the domain of Information Systems Engineering, but it also has a broad set of links with research domains in Wireless Network Technology, Artificial Intelligence, Urban Geography, Logistics, Medical Technology, etc.

	Data
	Complexity	Non-AI Processor	AI-based Processor
	Data about users' well-being and state	Smart & Connected & Sentient Ex: Smart insulin pen detecting the state, defining the dose and injection duration.	Intelligent & Connected & Sentient Ex: Robot dancing with disabled people.
			Intelligent & Connected
	Data from	Smart & Connected	Ex: Smart home energy device
	the distant	Ex: Connected fridge ordering	connected to distributed grid
	environment	lacking food.	storing electricity and
			optimizing its consumption.
	Data from the immediate environment	Smart Ex: Vacuum cleaner robot adapting its drive depending on the flat configuration.	Intelligent Ex: Air conditioner adapting the temperature depending on people and environment.
			Processor Complexity

Note, that in these definitions, the perspective of the distributed ownership or multi-stakeholder arrangements does not appear. Smart Life usually deals with a variety of technologies, a variety of

Table 5 .1. Smart Domains Evolution.

 5

  challenges. Smart Life is already applied in a lot of projects, sometimes successfully, sometimes not. The Information Systems Engineering field has brought about many strong conceptual modelling techniques (class diagrams, process models, object-orientation, state-transaction graphs). What conceptual modelling techniques provide the most effective modelling of Smart applications? Situational Method Engineering focuses on formalizing the use of methods for systems construction using organisation-, project-specific and context-aware methodological approaches. Would these approaches be suitable for Smart Life applications? Would it be possible to use these methods to provide a real-time adaptation of Smart Life applications? Next to scientific reporting, a huge variety of application projects have been reported in the popular press and industrial magazines. What are the key factors of success? How can we objectively obtain the essential contributions of contextual factors in different cases? Early estimations of explicit and implicit values of Smart applications projects are often vague and debatable. How different value-modelling techniques can assist in Smart Life projects quantification? In this manner, a first list of methodological challenges for SLE comprises: defining common methods for SLE, defining quality criteria and value models, providing context awareness of SLE, providing real time adaptation, etc.

Table 5 .3. Illustration of Sentient Requirements with a Visiting Game in a Museum.

 5

	Sentient	Sentient Requirement Expression	Corresponding Functional
	Requirement		Requirement(s)
	Interaction and
	Involvement

Only already published results are included in this document.

Only already published results are included in this document.

Only already published results are included in this document.

Only already published results are included in this document.

93/ 158 HDR classes (and vice versa).

The map designer has defined the following values for the weight indicators. The Goal state and Guideline Realization values are always equal to 0 before any execution of the process, as they are dynamic values which will be evaluated "on the fly". The static aggregated values of the section weights (Table 4.5.) are calculated before any navigation on the map. They represent the complexity of the corresponding executable services. In this example, some sections may be refined by other maps which are themselves complex guidelines. The section weight represents the complexity of the map hierarchies.

Based on rules presented in section III we describe the 0* map as a graph (Figure 4.20). Assume this graph is described in an interpretable language. There are different ways to store graphs in a computer system (either lists or matrices, or both of them). For instance, the representation suggested by van Rossum, in which a hash table is used to associate each vertex with an array of adjacent vertices, can be seen as an instance of this type of representation. Another possible way to represent this graph will be to use the XGMML (eXtensible Graph Markup and Modeling Language) structure. We chose the matrix representation in this example.

Our example graph may be described with the following sets E and V. This part illustrates the configuration process with the same example than in the section (4. 1.3.3.). We want to construct an O* model for the following description of the project: "The client phones to the company to obtain a reservation. He gives information about himself (name, address, and phone) and about the reservation (beginning date, ending date). The client may also cancel an "OK" reservation."

The engineer chooses to apply systematically the algorithm of the minimal weight path. The procedure "Apply-algo (A, B)" will then choose a path between the vertices A and B which will be the one with the minimal weight.

Initial affectations:

First iteration:

The first iteration of the algorithm will allow realizing the section IAG4 which will create the event "Demand of reservation".

After this iteration, the engineer analyzes the situation and establishes that the intention is realized at 50 %. The guideline of this section is not complete as there is still an event to identify.

Second iteration:

Realize

95/158 HDR

The second iteration performs a second time the section IAG4, in order to create the event "Cancel a reservation". In this stage, the engineer establishes that the given intention is completed. Based on these findings, the engineer continues to apply the algorithm from IAG4 without return back to the initial vertex (I).

The algorithm application identifies that the next section to realize is IAG5, therefore it is necessary to couple found events to classes.

Third iteration:

The third iteration will go further in the map in order to realize the section IAG5 to identify the classes coupled to the event "Demand of reservation", which are firstly the reservation class, but also the client class (which we find by a study of the reference links of the reservation class).

The next section to realize is IAG3, to test the completeness of the product.

Fourth iteration:

Realize The fourth iteration performs the section IAG3 which tests the completeness of the desired product.

At the intentional level, the engineer reaches the Stop intention; therefore, the map navigation is finished. At the operational one, the process gets into the final vertex F, which ends the navigation through the graph.

This example shows the use of the shortest past algorithm on a map expressed as a graph. The guidance has been improved to ease the engineer decisions as each section was proposed to him during the process, by minimizing the process complexity.

Illustration of a Complete Method Line Selection using Graphs

This illustration deals with a complete method line selection using the graph theory. It continues the example from sub-section 4.1.3.2. The given approach allows finding an optimal path through the method family using the graph theory algorithms.

Graph Theory Algorithms by Single Indicator. Possible algorithms to apply are the Shortest path, the Hamiltonian path (path navigating through all the sections of the Map) and so on. The engineer selects an indicator, identifies all possible paths, and calculates values for each path (for quantitative HDR * The choice between these effects is made depending on the nature of the direct impact.

To help managers and enterprise architects faced with digital transformation, we proposed an impact propagation model and the associated process to use when introducing an Industry 4.0 component into current EA models, usually represented with different frameworks [Zachman, 2018], [Cameron et 128/158 HDR

Based on literature about need for better consideration of humans in ICT, we define the sentient requirements as follows:

• Interaction and Involvement: ICT should interact and communicate with humans.

• Awareness: ICT should be aware of human beings, know and learn about them, and sense/perceive humans. • Safety: ICT should protect from danger and harm and take care of humans; the laws of I.

Asimov fall into this requirement. To illustrate the role of sentient requirements in the ICT field, we suggest modelling the requirements hierarchy as a pyramid (Figure 5.10.). This pyramid is built by analogy with Maslow's pyramid of needs [Maslow, 1943]. It shows the importance of sentient requirements and allows us to position them in accordance with the existing requirements typology. As in Maslow's five levels allow to satisfy human needs, we believe that all three levels of sentient requirements should be achieved in order to provide mindful ICT.