Du Pattern de tâches aux modèles de tâches

Le pattern de tâches ainsi décrit doit être adapté selon la fonction et le système dont on veut construire le modèle de tâches. Les informations permettant d’adapter correctement le pattern de tâches après l’avoir instancié sont connues par un utilisateur expert (expert métier) qui n’a aucune connaissance des notations de tâches. Il est donc préférable d’offrir la possibilité à cet expert d’adapter le pattern. Pour ce faire, le pattern de tâches doit être présenté sous une forme compréhensible, lui permettant de le lire, le parcourir et de l’adapter facilement. Notre objectif est de proposer une démarche proche de celle du simulateur de tâches Prototask (Lachaume et al. 2012) qui simplifie la vérification et la validation des modèles de tâches aux utilisateurs. Prototask est lié au formalisme de modélisation de tâches K-MAD. Pour exploiter pleinement les fonctionnalités de Prototask, la démarche de description du pattern de tâches que nous proposons s’effectue également avec K-MADe. Cependant, il est intéressant de rendre la démarche générique en n’obligeant pas le concepteur à utiliser une notation de pattern spécifique. Pour cela, une étape importante avant l’obtention des modèles de tâches est de transformer le pattern de tâches écrit dans d’autres notations de modélisation de tâches en K-MAD.

Figure 38 Démarche globale d’obtention des patterns à partir des modèles de tâches

La Figure 38 décrit la démarche globale de conception du pattern de tâches et d’obtention des modèles de tâches. La première étape de cette démarche est la conception du pattern de tâches (Annexe 4) de supervision par le concepteur d’IHM. Ce pattern suit le formalisme et la représentation graphique présentés respectivement dans les sections 5.1 et 5.2. Il peut être réutilisé pour la conception des modèles de tâches de la plupart des systèmes de

contrôle-79 commande. Cette étape est suivie de la vérification de la notation dans laquelle est décrit le pattern. Si le pattern est décrit en K-MAD, il est ensuite instancié au cours de la deuxième étape, dans un outil d’adaptation de pattern de tâches pouvant permettre à un utilisateur expert (expert métier) de l’adapter aux différents contextes d’utilisation (aux spécificités de la fonction dont on veut décrire le modèle de tâches). Si le pattern n’est pas décrit avec K-MADe, une étape intermédiaire permet de le convertir en un modèle K-MAD afin de l’utiliser dans le processus d’adaptation. L’outil proposé, dont l’implémentation est détaillée dans le chapitre 4, offre la possibilité à l’utilisateur expert d’adapter le pattern de tâches tout en le simulant pour obtenir les modèles de tâches vérifiés et validés.

6. Bilan sur la conception des modèles de tâches complexes

Les travaux présentés dans ce chapitre, apportent une aide supplémentaire par rapport aux approches existantes, pour la conception des modèles de tâches complexes.

La formalisation, la construction et l’utilisation de patterns de tâches nous permettent de résoudre les problèmes de complexité et de diversité qui augmentent dans la description des modèles de tâches. En effet, l’identification de la structure de la tâche de supervision en s’appuyant sur l’état de l’art a conduit à la construction d’un pattern regroupant, de façon générique, les activités des opérateurs d’une salle ou une passerelle de contrôle.

L’utilisation d’un logiciel concret de modélisation de tâches (K-MADe) pour la représentation du pattern permet une meilleure description de ces derniers. De plus, nous offrons ainsi la possibilité au concepteur de construire lui-même le pattern dont il a besoin pour l’analyse des activités humaines. Pour la généricité de notre approche, nous tentons de nous appuyer sur le principe PIM (Plateform Independant Model), c'est-à-dire les patterns dont la description contient des variables, peuvent être spécifiés avec des outils de modélisation autre que K-MAD. Les concepteurs d’IHM peuvent donc représenter ces patterns avec n’importe quelle notation de modélisation de tâches (KMAD, CTT, Hamsters, etc.). Il faudra dans ce cas assurer le passage d’un modèle à l’autre.

La mise en œuvre des transformations de modèles permet de s’affranchir des contraintes liées au choix de la notation de tâches. Cette opération peut nécessiter d’importantes transformations de modèles mais ces transformations ne sont mises en œuvre qu’à la première utilisation d’une nouvelle notation de tâches.

La proposition d’une démarche d’adaptation qui s’appuie sur la méthode Prototask permet de rendre l’adaptation et la lecture du pattern de tâches accessible aux utilisateurs experts et d’avoir des modèles de tâches vérifiés et validés.

Les modèles de tâches ainsi obtenus contiennent les exigences formalisés nécessaire à la conception du système de contrôle-commande. Ces exigences devront être complétées par les spécifications fonctionnelles du système. En effet, les modèles de tâches permettent d'avoir un ensemble d'exigences fonctionnelles exprimées par le concepteur qui peuvent être utilisées dans les approches de conception, mais ces modèles ne permettent pas d'éviter les erreurs liées à l'interprétation des spécifications fonctionnelles.

81

Chapitre 3 : Spécifications et Génération d’application de

contrôle-commande

L’analyse et la modélisation de la tâche humaine sont largement intégrées que ce soit dans le processus de conception ou celui de génération des systèmes interactifs, car elles permettent d’extraire un ensemble de données relatives aux besoins de l’utilisateur (besoins informationnels de l’opérateur (BIO)) qui sont transformées et intégrées aux IHM. Cependant, le formalisme de modélisation de la tâche, la validation du modèle de tâches et le passage du modèle de tâches vers ces besoins et les objets de l’interface sont autant d’éléments qui rendent difficile la prise en compte de l’analyse de la tâche dans une approche de génération de système interactif (Moussa 2005).

Pour résoudre ce problème, l’analyse de la tâche est souvent combinée avec les spécifications fonctionnelles du système. Cependant l’état de l’art présenté au chapitre 1 rend bien compte des problèmes liés à la spécification fonctionnelle des systèmes complexes (voir section 3.6 au Chapitre 1).

Dans ce chapitre, nous tentons d’apporter une solution aux difficultés rencontrées dans la spécification fonctionnelle des systèmes complexes pour la génération de systèmes de contrôle-commande.

La première section de ce chapitre présente un état de l’art sur les approches permettant de générer les systèmes interactifs à partir des modèles de tâches. Cette première section nous permet d’identifier des verrous présentés dans la deuxième section de ce chapitre. Ces verrous mettent en évidence le besoin de compléter le modèle de tâches par d’autres modèles : les spécifications fonctionnelles. Il apparaît alors pertinent de chercher des pistes pouvant faciliter l’obtention de ces spécifications.

Ainsi, la deuxième section de ce chapitre présente un état de l’art des approches permettant de capturer la connaissance fonctionnelle que les concepteurs ont du système à concevoir pour obtenir ainsi les spécifications fonctionnelles.

En tirant parti de cet état de l’art, nous proposons une démarche détaillée dans la troisième

section de ce chapitre, dont le but est de faciliter la spécification fonctionnelle des systèmes

complexes.

1 La génération d’IHM à partir de modèles de tâches

Depuis quelques années, un grand nombre d'outils et de méthodologies exploitent les modèles de tâches pour la génération d’interface. Une interface utilisateur (UI) est la partie d'un système logiciel/matériel qui est conçue pour permettre l’interaction avec des utilisateurs (Ramón et al. 2016). Dans les approches WIMP (Windows, Icons, Menus and Pointers), qui

constituent encore la majorité d’interfaces sur ordinateur12, elle est présentée avec des éléments

graphiques tels que des icônes ou des menus. Les interfaces utilisateurs disposent d'une partie statique qui est liée à la présentation (par exemple la structure, la disposition, l'accès ou l'esthétique) et d’une partie dynamique qui est liée au comportement du système par rapport aux actions de l'utilisateur (c'est-à-dire les événements qui sont déclenchés et l’exécution des

12 Nous ne considérerons pour notre travail que les interfaces WIMP, seules utilisées aujourd’hui dans les systèmes industriels qui sont cibles de nos travaux.

82

actions et/ou des changements). Pour la suite du chapitre nous nommons la partie statique,

présentation et la partie dynamique, dialogue. Nous définissons ces deux termes avant de

présenter un état de l’art sur la génération d’interface à partir de modèles de tâches.

1.1 La présentation

Le modèle de présentation d’une interface peut être considéré comme une sorte de disposition spatiale des éléments graphiques (widgets ou vues) dans la vue de l’application (Ramón et al. 2016). Les vues sont les représentations graphiques qui sont affichées sur les écrans du dispositif sur lesquels l’interface tourne (les fenêtres dans les applications de bureau, des pages web dans les applications web, des vues dans les applications mobiles, etc.).