Le niveau CIM : mod` ele BPM

El´ement

d’interaction ^{Sp´ecification}

UIGroup ^{Repr´esente l’espace de travail qui permet de grouper} logiquement des UIUnits et des UISubUnits.

UIUnit ^{Permet de regrouper des ´el´ements d’interaction en groupes} logiques du point de vue des interactions

UIFieldInManual ^{Repr´esente un ´el´ement d’interaction permettant `a} l’utilisateur d’effectuer une entr´ee manuellement.

UIFieldStatic ^{Repr´esente un ´el´ement d’interaction capable d’afficher des} informations statiques ne pouvant pas ˆetre chang´ees. UIFieldOneChoice ^{D´efinit un ´el´ement d’interaction permettant `a l’utilisateur}

de s´electionner ou pas une alternative unique. UIFieldMultiChoices ^{II s’agit d’un ´el´ement d’interaction permettant `a}

l’utilisateur de s´electionner une alternative parmi plusieurs. UIFieldOut ^{Constitue un ´el´ement d’interaction permettant au syst`eme}

d’effectuer une sortie d’informations.

UIFieldAction ^{Est un ´el´ement d’interaction permettant de d´emarrer une} action.

UIFieldMenuItem ^{D´ecrit un ´el´ement d’interaction qui permet de naviguer} entre les UIUnits, les UISubUnits et les UIgroups. UIFieldMenu ^{Repr´esente un ensemble de UIFieldMenuItems qui sont}

regroup´es.

3.3 Le niveau CIM : mod`ele BPM

3.3.1 D´efinition du mod`ele des tˆaches

Afin de mod´eliser les tˆaches, il est important de bien choisir le formalisme ou la notation qui permet de les d´ecrire en prenant en compte l’ensemble des donn´ees de l’application (le contenu) ainsi que leurs dynamiques. Comme pr´esent´e dans le chapitre 1, il existe plusieurs formalismes permettant la mod´elisation des tˆaches. Toutefois, les notations existantes ne permettent pas d’envisager tous les changements de contexte et de prendre en compte la personnalisation ou l’adaptation de l’IHM depuis la phase de conception. Pour cette raison, il est important d’apporter quelques extensions `a ces formalismes. Dans la cadre de cette th`ese et afin de mettre en œuvre notre mod`ele des tˆaches, nous avons adopt´e la notation BPMN (BPMI, 2004) pour les raisons suivantes :

– C’est l’unique notation qui est standardis´ee parmi celles pr´esent´ees dans le chapitre 1 ; – Elle est plus proche de l’ing´enierie des syst`emes et, par cons´equent, elle permet la mod´elisation des tˆaches fonctionnelles et la description de la logique m´etier de l’ap-plication (appel´ee ´egalement le comportement de l’interface (Weyersa et al., 2012)),

– Elle permet de mod´eliser le flux d’informations inter tˆaches, ce qui est particuli`erement important pour l’int´egration de la personnalisation du contenu. BPMN apporte les no-tions des” messages” et des “flows connexions”. Par cons´equent, les tˆaches dans des pro-cessus diff´erents peuvent communiquer au moyen des “messages” et celles appartenant `a un mˆeme processus utilisent les “flow connexion” pour contrˆoler leurs s´equencement. N´eanmoins, il est important de souligner que, dans le cadre de notre approche, BPMN est uniquement utilis´ee pour exprimer les interactions des utilisateurs tel que propos´e par (Brossard et al., 2007) et elle ne sera pas int´egr´ee dans un moteur de workflow. Notre ob-jectif est de l’exploiter dans une approche d´eclarative afin de g´en´erer l’interface utilisateur final, suite `a une s´erie de transformations.

En plus des ´el´ements de base fournis par BPMN, nous avons tenu `a chercher la bonne mani`ere permettant d’inclure la personnalisation du contenu dans le mod`ele des tˆaches. Pour cela, il faut d’abord d´efinir les informations de contexte que nous devrions prendre en compte mais ´egalement indiquer les informations du domaine pouvant ˆetre influenc´ees par le contexte. Cette correspondance est ´etablie par les mappings pr´ec´edemment pr´esent´es (cf. chapitre 3, §3.2.2).

Enfin, pour mieux d´efinir la fa¸con dont les informations de contexte devrait ˆetre utilis´ees pour fournir des contenus personnalis´es, il est important de sp´ecifier, d’une mani`ere abs-traite, quels sont les ´el´ements d’interaction `a travers lesquels le contenu sera pr´esent´e.

Figure3.9 – Mod`ele des tˆaches annot´e

En r´esum´e, trois mod`eles sont utilis´es pour soutenir la mod´elisation des IHM `a contenus personnalis´es : le mod`ele de contexte, l’ontologie de domaine et le mod`ele d’interaction.

L’ensemble des informations issues de ces mod`eles est utilis´e pour annoter le mod`ele des tˆaches (cf. Figure 3.9). Dans ce contexte, une extension de BPMN est n´ecessaire. Apr`es avoir pr´esent´e chacun de ces mod`eles dans les sections pr´ec´edentes, nous d´etaillerons l’ex-tension que nous avons apport´e `a BPMN pour soutenir les annotations au niveau de notre mod`ele des tˆaches.

3.3.2 Extension de BPMN pour la mod´elisation des tˆaches

Dans le but de prendre en compte la personnalisation du contenu depuis la phase de conception, nous avons ´etendu la notation BPMN utilis´ee afin que le concepteur puisse annoter le diagramme avec les ´el´ements issus de l’ensemble des mod`eles de notre approche. De ce fait, nous avons commenc´e par une modification des ´el´ements de base fournis par BPMN tels que :

- Les conteneurs qui sont r´ealis´es `a l’aide de l’´el´ement BPMN de type “Pool ”. Dans la version 2.0 de BPMN1, les conteneurs sont des ´el´ements qui permettent de sp´ecifier un acteur ou une entit´e organisationnelle particuli`ere. Dans notre mod`ele des tˆaches, un “Pool” est utilis´e comme ´etant une entit´e organisationnelle repr´esentant un espace de travail qui regroupe un ensemble d’´el´ements li´es `a un mˆeme objectif m´etier. Pour indiquer l’acteur d’une tˆache, nous avons fourni la possibilit´e de le mentionner directement sur la tˆache concern´ee. Le deuxi`eme type de conteneurs propos´e par BPMN est l’´element “Lane”. ´Etant donn´e que nous avons chang´e le rˆole des “Pools”, nous n’aurons plus besoin d’utiliser les “Lanes” au sein de notre mod`ele BPMN propos´e ;

- Les nœuds du graphe nomm´e Contained Element Type qui repr´esentent les ´ev´enements (Start Event, Intermediate Event et End Event), les branchements conditionnels ou les “gateways” (Exclusive Gateway, Inclusive Gateway et Parallel Gateway) ainsi que les tˆaches. Dans notre mod`ele des tˆaches propos´e, nous avons d´efini deux types de tˆaches. Des tˆaches r´ealis´ees par l’utilisateur appel´ees User Task et des tˆaches r´ealis´ees par le syst`eme, appel´ees System Task. Pour des raisons d’organisation, ces nœuds pourraient ˆetre regroup´es en utilisant, soit l’´el´ement “SubProcess”, soit l’´el´ement

“Group”. L’id´ee de sp´ecifier les acteurs directement sur les tˆaches (User Task qui

est effectu´ee par un ˆetre humain intervenant dans le processus d’interaction et System

Task qui est effectu´ee par le syst`eme) a ´et´e adopt´ee du travail de (Brossard et al.,

2007) ;

- Les arcs qui repr´esentent le flux d’informations. Il y a deux types d’arcs : le Sequence

Flow pour montrer l’ordre dans lequel les activit´es seront r´ealis´ees dans un processus

et le Message Flow pour afficher le flux de messages entre les “Pools”. Dans notre mod`ele de tˆache, nous autorisons uniquement l’envoi des messages `a partir des tˆaches vers les “Pools”. Pour chaque type d’arc, il existe trois sous-types ´etablis grˆace `a la classe Condition type : Expression lorsque l’arc est dot´e d’une condition qui sera

´evalu´ee lors de l’ex´ecution pour d´eterminer si le flux concern´e sera suivi ou pas ;

None pour se r´ef´erer au flux qui ne contient aucune condition ; et Default pour les gateways exclusives ou inclusives, afin d’indiquer que ce type de flux est celui suivi

par d´efaut.

Une fois que nous avons d´efini un mod`ele des tˆaches `a l’aide des ces ´el´ements, nous proc´edons `a son annotation afin d’y int´egrer la personnalisation du contenu. Cette an-notation est r´ealis´ee grˆace aux ´el´ements suivants :

- L’attribut RelatedInteractionElement qui permet l’association d’un ´el´ement d’interac-tion `a une tˆache sp´ecifique. En effet, chaque espace de travail contient un certain nombre d’´el´ements qui le construit et chaque ´el´ement sera associ´e `a la tˆache qu’elle manipule. Cette association n’est pas arbitraire, et elle est r´ealis´ee en respectant les r`egles que nous avons d´efinies, comme illustr´e dans le Tableau 3.5 ;

- L’attribut OntologyElementName, qui repr´esente le concept ou les concepts de l’ontologie de domaine li´e `a la tˆache ;

- L’attribut MappingType qui permet de sp´ecifier la mani`ere dont l’´el´ement de domaine est associ´e `a l’´el´ement du contexte. Dans le cas d’un mapping indirect, nous avons propos´e ´egalement la classe Inference Criteria qui permet de pr´eciser les crit`eres qui seront utilis´es lors de la recherche d’une information sp´ecifique.

La Figure 3.10 pr´esente notre mod`ele des tˆaches propos´e qui permet de mettre en œuvre la personnalisation du contenu (adapt´e de la version 2.0 de BPMN). Les ´el´ements mis en ´evidence par la couleur grise sont les parties que nous avons ajout´ees au mod`ele BPMN, afin de parvenir `a la personnalisation du contenu.

Table 3.5 – Association entre les ´el´ements BPMN et les ´el´ements d’interaction ´

El´ement BPMN El´^´ ement d’interaction associ´e

Pool UIGroup SubProcess UIUnit UISubUnit UIFieldMenu User Task UIFieldAction UIFieldInManual UIFieldNavigation UIFieldNavigation UIFieldInMultiChoices UIFieldInOneChoice System task ^UIFieldOut

UIFieldStatic

.3 – L e n ive a u C IM : m od `el e B P M 1 0 5

3.3.3 Conception des IHM `a contenus personnalis´es

Dans cette section, nous pr´esentons la mani`ere avec laquelle nous pouvons mod´eliser une IHM `a contenus personnalis´es en nous appuyant sur le mod`ele des tˆaches. Cette phase de conception s’effectue en deux ´etapes principales :

1. ´Elaboration du mod`ele des tˆaches non annot´e.

2. Annotation du mod`ele des tˆaches par les ´el´ements de personnalisation.

3.3.3.1 Elaboration du mod`^´ ele des tˆaches

Tout d’abord, le concepteur de l’IHM doit commencer par pr´eciser les conteneurs qui sont mis en place `a travers l’´el´ement “Pool”. Comme expliqu´e pr´ec´edemment, chaque “Pool” sera utilis´e comme une entit´e organisationnelle qui correspondra `a un espace de travail dans l’interface finale.

Ensuite, le concepteur doit mod´eliser les activit´es (“Task” et “Subprocess”) appartenant `a chaque conteneur. Pour chaque tˆache, le concepteur doit pr´eciser s’il s’agit d’un UserTask ou d’un SystemTask.

Afin de synchroniser tous les ´el´ements BPMN cr´ees pr´ec´edemment, le concepteur doit utiliser les “events”, “gateways” ainsi que les “arcs” en respectant les r`egles d´efinies par le standard BPMN 2.0.

3.3.3.2 Annotation du mod`ele des tˆaches

Apr`es l’´elaboration d’un mod`ele des tˆaches non annot´e, le concepteur annote, si n´ecessaire, les composants BPMN suivants : “Pool”, “Task”, “Subprocess” et “Group”, dans le but d’int´egrer la personnalisation du contenu. Nous d´esignons par la lettre A, chaque ´el´ement appartenant `a cet ensemble de composants.

Puisque chaque espace de travail contient un ensemble d’´el´ements qui le construit, chacun de ces ´el´ements sera associ´e `a un composant A. De ce fait, le concepteur peut associer `a chaque composant A l’´el´ement d’interaction qui lui est appropri´e (via l’attribut

Relate-dInteractionElement), tout en respectant les r`egles d´efinies dans le Tableau 3.5.

Ensuite, en utilisant l’attribut OntologyElementName, le concepteur doit associer `a chaque tˆache d’entr´ee/Sortie, le concept ou les concepts de l’ontologie de domaine manipul´es par cette tˆache.

Enfin, lors de l’annotation d’une tˆache avec le concept de l’ontologie de domaine, le concep-teur doit aussi pr´eciser, le type du mapping (par la classe Ontology Element Mapping), conform´ement aux r`egles suivantes :

- R`egle 1 : Le mapping direct doit ˆetre d´efini lorsque les ´el´ements de l’ontologie et du contexte ont la mˆeme signification s´emantique. Ce genre de mapping est toujours uti-lis´e avec les UserTasks qui sont associ´es `a l’´el´ement d’interaction UIFieldInManual. Si le concepteur pr´evoit la valeur de ce champ d’entr´ee d’information, il doit annoter la tˆache qui lui est associ´ee, par le concept de l’ontologie de domaine correspondant (par l’attribut OntologyElementName). Ensuite, il doit sp´ecifier l’option Direct (par l’attribut mapping type).

- R`egle 2 : Le mapping indicatif est toujours utilis´e dans le cas de s´election d’une infor-mation. Par cons´equent, il est toujours utilis´e avec un UserTask qui est associ´e `a un ´el´ement d’interaction de type UIFieldOneChoice ou bien UIFieldMultiChoice. Dans les deux cas, le choix de la meilleure information sera influenc´e par le contexte. Pour int´egrer cet aspect d`es la phase de conception, et par analogie avec mapping direct, le concepteur doit associer `a la tˆache correspondante le concept de l’ontologie de domaine et sp´ecifier qu’il s’agit d’un mapping indicatif. Cela signifie que la s´election ou non d’une telle information est d´ependante de la valeur de l’´el´ement de contexte qui lui est mapp´e.

- R`egle 3 : Le mapping indirect est utilis´e lorsque l’information (un concept de l’onto-logie) d´epend d’un autre. Il est toujours utilis´e avec les composants BPMN de type

SystemTask aux quels sont associ´es des ´el´ements de type UIFieldOut, ´etant donn´e

que le concepteur estime que la tˆache correspondante servira comme une sortie d’in-formations. Lors de l’annotation des tˆaches, le concepteur doit pr´eciser le concept de l’ontologie principal (par l’attribut OntologyElementName) qui repr´esente l’in-formation `a rechercher. Ensuite, il doit indiquer (par la classe Inference Criteria) les autres concepts de l’ontologie qui repr´esentent des crit`eres `a prendre en compte pendant le processus de la recherche.

L’ensemble des axiomes et des relations de l’ontologie entre les classes pourraient ˆetre exploit´ees lors du mapping indirect. Du fait que nous nous int´eressons `a fournir du contenu personnalis´e `a l’utilisateur, la requˆete initiale pourrait ˆetre ´etendue en incluant automatiquement d’autres crit`eres lors du processus de recherche. Cette proposition sera d´etaill´ee dans le chapitre 4, §4.3.1.2.

Dans le chapitre 5, nous pr´esenterons deux cas d’´etudes permettant d’illustrer et de mettre en œuvre l’ensemble des mod`eles conceptuels ainsi que notre m´ethode de mod´elisation propos´e.