Besoins préliminaires et finals

L’objectif du système Amadeus est d’assurer la sensibilisation au contexte d’un envi- ronnement ambiant pour lui permettre d’adapter son comportement et ainsi améliorer le confort de ses utilisateurs. Au travers des différents capteurs de l’environnement, Amadeus doit acquérir assez d’informations pour anticiper les actions des utilisateurs sur les diffé- rents effecteurs afin de réaliser ces actions à leur place.

Nous définissons une liste des mot-clés utiles à la compréhension du problème et de son domaine. Les définitions associées à chaque mot-clé ne sont pas forcément consensuelles, mais nous nous baserons sur celles-ci pour le reste de notre étude.

– Environnement ambiant : espace physique composé d’un ensemble de dispositifs in- terconnectés. Un environnement ambiant se caractérise notamment par sa forte dyna- mique, certains dispositifs pouvant apparaître ou disparaître au cours du temps, tout comme les connections entre eux. Cette dynamique rend notamment difficile, voire impossible, de délimiter nettement les frontières d’un environnement ambiant ;

Implémentation Conception Analyse Besoins finals Besoins Préliminaires

A1 : Définir les besoins utilisateurs A1 : Définir les besoins utilisateurs S1 : Spécifier des besoins utilisateurs S2 : Valider les besoins utilisateurs A2 : Définir les besoins consensuels

S1 : Spécifier des besoins consensuels S2 : Valider les besoins consensuels A3 : Modéliser le domaine

S1 : Définir les concepts métier S2 : Établir le processus métier A4 : Établir un ensemble de mots-clés A5 : Extraire les limites et les

contraintes

A6 : Caractériser l’environnement A7 : Déterminer les cas d’utilisation

S1 : Dresser un inventaire des cas d’utilisation S2 : Élaborer les diagrammes de séquences S3 : Valider les cas d’utilisation A8 : Qualifier le SMA

S1 : Qualifier l’environnement système

S2 : Identifier les échecs à la coopération acteur-système

S3 : Vérifier l’adéquation au SMA A9 : Élaborer les prototypes d’UI

S1 : Spécifier les prototypes d’UI S2 : Valider les prototypes d’UI

entité et/ou

A10 : Analyser les caractéristiques du domaine S1 : Identifier les entités actives et passives S2 : Étudier les interactions entre les entités

A11 : Vérifier l’adéquation aux AMAS au niveau global

A12 : Identifier les agents S1 : Étudier les entités actives

S2 : Identifier les échecs à la coopération entité-entité et/ou entité-environnement système

S3 : Déterminer les agents coopératifs

A13 : Vérifier l’adéquation aux AMAS au niveau local

A14 : Définir la vue module du système A15 : Étudier les actes de communications

S1 : Définir les interactions des agents S2 : Définir les interactions des entité A16 : Définir le comportement des entités

A17-18 : Définir le comportement des agents (nominal et coopératif)

S1 : Définir les compétences S2 : Définir les aptitudes

S3 : Définir les langages d’interaction S4 : Définir les représentations S5 : Définir la criticité et la confiance de comportement de l’agent

A19 : Validation de la conception S1 : Prototypage rapide

S2 : Compléter les diagrammes de conception

A20 : Développement du framework

S1 : Micro-architecture extraction S2 : Implémentation des composants

S3 : Implémentation des entités A21 : Implémentation du comportement des agents

S1 : Implémentation du comportement nominal

S2 : Implémentation du comportement coopératif

Figure 3.2 – Méthode ADELFE ([Bonjean et al., 2013])

– Système ambiant : environnement ambiant doté d’une couche logicielle reliant les dif- férents dispositifs ;

– Dispositif : entité matérielle présente dans l’environnement ambiant, et possédant au minimum un capteur et/ou un effecteur. De plus, il possède la capacité computation- nelle de supporter une application logicielle, ou au moins d’être connecté à un autre dispositif qui la supportera pour lui ;

– Capteur : élément associé à un dispositif qui permet de percevoir des informations depuis l’environnement (exemple : capteur de luminosité, de présence, etc.) ;

– Effecteur : élément associé à un dispositif lui permettant d’agir dans l’environnement, et par conséquent d’en modifier l’état. Un effecteur intègre aussi un capteur, car son propre état fait partie des informations de l’environnement (exemple : lampe, store électrique, radiateur) ;

– Action : affectation de l’état d’un effecteur, comme par exemple allumer une lampe, ou fermer un store. Le maintien de l’effecteur dans son état courant peut aussi être vu comme une action. Une action peut être faite par un utilisateur ou par une application logicielle ;

– Variables contextuelles : ensemble des variables perceptibles par des capteurs, et pou- vant avoir un impact sur l’exécution d’une tâche par une entité (utilisateur ou entité logicielle). Chaque variable génère des données au cours du temps. Une variable est

considérée comme utile vis-à-vis d’une action si la connaissance de cette variable a un impact sur les prises de décisions quant à la réalisation de cette action par un utilisa- teur ou par une application logicielle (par exemple, la luminosité d’une pièce est une des variables utiles pour décider quand agir sur la lampe de cette même pièce) ; – Situation : état (valeur) de l’ensemble des variables contextuelles à un moment donné. Les besoins fonctionnels désignent les contraintes liées au comportement du système :

– L’adaptation d’Amadeus doit être dynamique : il doit être capable de s’adapter aux situations non prévues, comme les comportements changeants des utilisateurs ; – L’apprentissage d’Amadeus doit à la fois être rapide et produire des actions correctes

et opportunes. Même s’il ne l’aide pas immédiatement, l’action d’un dispositif ne doit pas gêner l’utilisateur. L’apprentissage des actions doit être suffisamment rapide pour ne pas paraître inutile à l’utilisateur. Par exemple, si après plusieurs jours, le système est toujours en train d’apprendre et n’agit toujours pas, l’utilisateur risque de le considérer comme inutile ;

– Amadeus agit en temps contraint : le raisonnement du système doit être assez rapide pour lui permettre d’agir dans un temps acceptable par l’utilisateur. Par exemple, nous pouvons considérer que si le système met 5 minutes à décider d’allumer la lampe quand l’utilisateur entre dans la pièce, celui-ci le jugera inefficace ;

– La gêne occasionnée par les mauvaises actions du système doit être sensiblement inférieure au bénéfice procuré par ses actions correctes. Nous pouvons considérer qu’un utilisateur sera tolérant à quelques mauvaises actions du système s’il agit cor- rectement le reste du temps.

Les besoins non fonctionnels désignent les contraintes liées à la mise en application du système :

– Amadeus doit être ouvert : de nouveaux capteurs ou effecteurs doivent pouvoir appa- raître ou disparaître en cours de fonctionnement ;

– Amadeus doit pouvoir fonctionner sur des systèmes embarqués avec peu de mémoire et de puissance de calcul.

– Amadeus doit disposer des capteurs suffisant pour lui fournir l’ensemble minimal des données requises à son apprentissage.

La phase des besoins préliminaires doit aussi établir les limites du système à concevoir, autrement dit ce qui n’appartient pas à ses objectifs. Dans notre cas, l’objectif d’Amadeus se limite à anticiper les actions régulières de l’utilisateur ; il n’a pas pour objectif d’effectuer des actions sur des évènements particuliers et à risque, en cas d’accidents par exemple. Il n’a pas non plus pour objectif d’assurer un niveau de certitude dans ses actions suffisant pour un cadre d’utilisation impliquant la sécurité des utilisateurs.

L’environnement d’Amadeus se compose d’un ensemble d’entités actives et passives. Parmi celles-ci , nous distinguons :

– Entités actives : les utilisateurs qui peuvent agir sur les effecteurs, et qui ont un com- portement autonome.

– Entités passives :les dispositifs, composés de capteurs qui perçoivent et transmettent les données de l’environnement sans agir dessus, et d’effecteurs qui changent de valeur uniquement sous l’action des utilisateurs ou du système.

En se basant sur les définitions de [Russell et Norvig, 1995], l’environnement d’Amadeus possède les propriétés suivantes :

Inaccessible : les caractéristiques d’un système ambiant font qu’il est impossible d’espérer percevoir la totalité du système à tout moment, les informations perçues pouvant faci- lement être soumises à des délais, des bruits, voire même disparaître ;

Continu : la forte dynamique d’un système ambiant fait que le nombre d’états dans lequel il peut être n’est pas limité ;

Non déterministe : par nature, les effets d’une action dans le monde physique réel ne peut être prédit de façon certaine (par exemple, l’acceptation d’une action par un utilisateur ne peut-être certaine à 100%) ;

Dynamique : un système ambiant est en constante évolution, changeant au cours du temps et sous les actions des utilisateurs.

Les entités actives et passives dans l’environnement interagissent avec le système. En particulier :

– Les capteurs envoient au système les données perçues ; – Les utilisateurs peuvent modifier l’état des effecteurs ;

– Les effecteurs signalent au système tout changement d’état réalisé par un utilisateur ; – Le système peut modifier l’état d’un effecteur.