Réingénierie

La réingénierie d’un SPO n’est pas aisée en réalité pour l’enseignant qui doit prendre des décisions d’ordre pédagogique. En utilisant les informations collectées (indicateurs) à partir des traces de déroulement de la session d’apprentissage, l’enseignant concepteur peut évaluer des adaptations effectuées et analyser les variantes émergentes dans le SPO descriptif en vue d’identifier les problèmes rencontrés et d’envisager les améliorations nécessaires. La nouvelle version du SPO doit être constituée en intégrant des adaptations éprouvées et considérées comme positives, parce qu'elles améliorent la qualité du scénario prédictif, ces adaptations seront ainsi prises en considération dans des futurs cycles de vie. Cette intégration reste sous la maîtrise de l’enseignant qui décide si une nouvelle variante émergente permet d’améliorer ou non le scénario. Dans le cas où cette variante correspond à un nouveau contexte pour lequel elle est pertinente, ou qu’elle est meilleure qu’une existante, l’enseignant peut l’intégrer dans la deuxième couche des variantes du SPO. Elle sera donc stockée avec son contexte associé dans l’entrepôt. Si l’enseignant remarque qu’une variante se répète dans la majorité des contextes, il peut la considérer comme impérative pour les futurs cycles vie du SPO, et l’incorporer dans la couche statique du scénario. Les variantes qui ne sont jamais, ou très rarement utilisées, peuvent être supprimées par l’enseignant pour éviter le problème de débordement causé par la surcharge de l’entrepôt des variantes.

Afin de donner une représentation formelle de ce processus, nous utilisons les conventions graphiques du profil UML pour ECA (Entreprise Collaboration Architecture) présenté par le consortium OMG [OMG 2004]. Ce profil est destiné à supporter la modélisation dans une démarche de développement dirigée par les modèles utilisant le cadre ODP-RM [Nagase et al. 2004]. Les phases de ce processus, au sens d’ODP-RM, ont toutes des objectifs de production ou d’administration d’artefacts produits dans une communauté d’ingénierie des SPO.

Figure 33 : Diagramme de paquetages UML représentant le processus itératif et incrémental d’ingénierie d'un SPO.

Paquetage : ensemble d’objets métier Connexion : comportement Port ^{Port : rôle à l’initiative} _{d’un comportement} ^{Port Port : rôle participant à un} comportement Processus itératif et incrémental

d’ingénierie d’un SPO

Phase Conception Produire contextes prévus Produire couche statique Produire variantes prescrites Interprétation contexte prévu Interprétation variante prescrite Phase Réingénierie Diffuser variante Diffuser contexte prévu Capitaliser variante émergeante Capitaliser contexteassocié Phase Exécution Interpréter contexte prévu Utiliser couche statique Utiliser variante prescrite Produire variante émergeante Reconnaissance contexte réel Phase Déploiement Identification contexte prévu Interpréter contextes prévus Interpréter couche statique Sélectionner variante pertinente Déployer couche statique Interpréter variantes prescrites

Comme le montre la figure 33, chaque phase est représentée par un paquetage. Une phase produit et consomme des artefacts. Ces derniers caractérisent des flux de communication entre les différentes phases. Chaque flux est représenté sous forme d'une interaction entre deux phases (une phase émettrice et une phase réceptrice).

La phase de conception a pour objectif de spécifier des SPO en étant guidé par le modèle rationnel que nous avons proposé. Pour concevoir un SPO, l’enseignant peut donc soit produire, à nouveau, des variantes et leurs contextes prévus, ou bien réutiliser celles capitalisées lors des phases de réingénierie des cycles antérieurs.

La phase de déploiement consiste à interpréter les spécifications produites lors de la phase de conception. Ces spécifications concernent la couche statique du SPO, ses variantes anticipées et leurs contextes prévus. Une fois ces spécifications interprétées, les éléments de la couche statique sont déployés avec une variante du SPO. Cette dernière est jugée comme la plus appropriée car son contexte associé est identique à celui qui est identifié lors de la reconnaissance du contexte prévu pour l’exécution du SPO. Cette reconnaissance peut être effectuée par l’interprétation de toute information qui caractérise et influence la situation en considération, par exemple, via l’identification des profils des apprenants impliqués, des ressources disponibles, des indicateurs qui peuvent être calculés en amont ou juste au moment du déploiement du SPO, etc.

La phase d’exécution représente l’ensemble des activités des acteurs d’une session d’apprentissage. Elle a pour objectif d’utiliser les instances des éléments déployés du SPO. Ces instances concernent alors les éléments de la couche statique et ceux de la variante prescrite qui est déployée selon le contexte identifié. Dans la réalité, le contexte effectif d’exécution est généralement différent de celui qui a été interprété (prévu) au début de déroulement de la session. En conséquence, cela nécessite des adaptations en temps réel qui peuvent amener à l’émergence d’une nouvelle variante du SPO.

La phase de réingénierie consiste à capitaliser les variantes émergentes produites lors d’exécution et leurs contextes associés dans le but d’altérer le SPO prédictif pour des futures conceptions. Cette phase comporte un processus de gestion des ressources dont l‘objectif principal est de gérer les variantes et les contextes en les indexant et stockant dans un entrepôt dédié qui facilitera la recherche, la sélection et la réutilisation aux enseignants concepteurs à travers toutes les phases de cycles de vie de SPO.

5.3 Conclusion

La définition des SPO selon notre modèle rationnel permet de prendre en compte les différentes approches d’adaptation : soit « proactive », soit « réactive ». Proactive par la conception, en spécifiant a priori un ensemble de variantes anticipées. Réactive par la déviation à la volée des instances de la variante déployée, par le changement de la structure abstraite (au niveau modèle) et/ou d’instance du SPO en temps réel, par la complétude de définition du SPO en intégrant des éléments prescrits via la liaison tardive, ou par la spécification de nouveaux éléments via la modélisation tardive.

En outre, l’approche d’ingénierie des SPO à base de variantes peut réduire les efforts pour les enseignants concepteurs, améliorer la communication de l'expertise et favoriser la réutilisation systématique des pratiques communes ou éprouvées dans un domaine éducatif spécifique.

Cependant, les enseignants praticiens n'ont généralement pas de grandes compétences techniques et/ou de modélisation informatique. Ce processus doit donc être instrumenté par une méthode et des outils, intriqués dans leur domaine métier, qui les aident à concevoir, adapter et gérer les SPO à un haut niveau d’abstraction.

Nous présentons dans le chapitre suivant une méthode s’appuyant sur IDM/DSM visant à instrumenter les enseignants. Elle consiste à fournir un langage spécifique au domaine métier et un éditeur graphique dédié visant à faciliter la conception des SPO conformément à notre modèle rationnel (cf. chapitre 4), tout en respectant le processus d’ingénierie présenté (cf. chapitre 5).

6 _{Méthode d’instrumentation}

pour ouvrir les scénarios

pédagogiques d’un EIAH

Sommaire 6.1 Introduction