• Aucun résultat trouvé

Elaboration et catégories de bases de travail

5. MODELISATION D’UN ECLR

5.3. M ODELISATION GLOBALE DE L ’ECLR

5.3.1. Elaboration et catégories de bases de travail

Chaque composant d’un ECLR doit se ressourcer d’informations pour fonctionner dans le but d’assurer la robustesse de l’environnement de conception et d’utilisation du logiciel créé à l’aide d’un SAM. Ces informations proviennent du concepteur de l’ECLR, du SAM et de l’auteur de niveau 1.

——————————————————————————— Modélisation d’un ECLR Nous avons vu dans les chapitres précédents que les agents peuvent modifier certaines bases de données grâce à leur attitude empirique. De même, certaines bases évoluent à cause des données entrées au fur et à mesure du développement par l’auteur de niveau 1. Par ailleurs, le concepteur de l’ECLR et l’auteur de niveau 1 peuvent fixer dès le départ des informations qui sont valables et non modifiables quel que soit le contexte. Par conséquent deux catégories de bases de travail coexistent dans un ECLR : la base de travail interne et la base de travail externe.

Ces deux catégories de bases de travail sont collectives et accessibles par tous les agents de tous les modules de l’ECLR.

5.3.1.1.Base de travail interne

Dans le chapitre 4.5 nous avons précisé que les agents d’un ECLR possèdent une base de travail ou BdT qu’ils utilisent pour réaliser les tâches qui leur sont attribuées. Nous pouvons distinguer deux types de bases de travail interne :

• Base de données statiques regroupant les données relatives au domaine traité et aux fonctionnements de base (règles). Ce type de base de travail peut être qualifié d’ontologique car elle est fixée dès le départ. En effet, l’ECLR est conçu avec des variables et des paramètres dont les contenus sont fixés à l’avance telle la valeur de retour « vrai » ou « faux » d’un test d’existence d’un périphérique. Ces variables et paramètres peuvent être également renseignées par l’auteur de niveau 1. Nous pouvons prendre en exemple la nécessité d’avoir une carte son pour le fonctionnement du logiciel final.

• Base de connaissances dynamiques qui est évolutive selon le fonctionnement interne des agents. Elle résulte d’une association des modèles épistémiques49, comportementaux et cognitifs50 de l’apprenant. Ce type de base de travail est mis à jour en temps réel et représente le résultat de l’apprentissage de l’ECLR afin d’évoluer avec le contexte environnemental. Cette base est surtout dédiée au fonctionnement des agents de priorité haute telle que l’ACO.

La base de travail interne est complétée ou mise à jour par les agents simples AC et AAE et AAI de chaque module après son activité. Les éléments d’apprentissage, l’historique des

Chapitre 5 ————————————————————————————————— actions des agents et les contenus des messages y sont décrits. Cela donne alors une ontogenèse des actions des acteurs (agents et l’auteur de niveau 1) permettant de vérifier le contexte et la structure du logiciel final.

Exception N° 1: O Exception N° 2: N Exception N° 3: O Exception N° 4: N

...

Liste des exceptions

Figure 5-8 : La liste des exceptions

Parmi les informations contenues dans la base de travail interne, qu’il s’agisse d’information fixe donc constante ou d’information mobile donc variable, nous attachons un intérêt particulier pour les données constituant la liste des exceptions. En effet, cette liste des exceptions garantit le respect de l’objectif défini par l’auteur de niveau 1 ainsi que le respect de l’objectif de l’ECLR c’est-à-dire fournir un environnement de création de logiciel robuste. Nous pouvons scinder cette liste des exceptions en deux parties :

• une liste générale que l’ECLR doit respecter en terme de règles liées aux présentations des fenêtres et des données textuelles, sonores et graphiques. Par exemple, la gestion des polices de caractères doit être associée à celle de la taille des fenêtres.

• une liste contextuelle que l’utilisateur aura définie au préalable par rapport à son cahier des charges : dans la figure 5-8, cela correspond aux règles liées aux variables, à la structure, aux ressources système, au traitement de fichier et à la gestion des composants. Nous pouvons par exemple penser à l’impossibilité d’utiliser le bouton « résultat » du didacticiel tant que l’utilisateur n’a pas choisi sa réponse dans un questionnaire. Cela correspond à la gestion de la présentation et à la gestion des relations procédurales contenues dans les règles liées à la gestion des composants.

——————————————————————————— Modélisation d’un ECLR Cette liste peut être enrichie par les anomalies rencontrées lors de la conception du logiciel final.

5.3.1.2.Base de travail externe

Nous appelons base de travail externe la base qui regroupe toutes les actions faites par l’auteur de niveau 1. Cette base constitue un historique de tout ce que fait l’utilisateur permettant ainsi à l’ECLR d’apprendre son comportement et de vérifier si les actions sont valables par rapport à la liste des exceptions. Pour que cette BdT externe ne soit pas une simple duplication du programme et afin d’éviter une base volumineuse et difficile à gérer, nous n’y ajoutons que les actions signifiantes et nécessaires pour l’évolution future du programme, par exemple les dernières valeurs des variables et paramètres, les appels de fonctions.

5.3.1.3.Plan de gestion des BdT

L’agent superviseur a un rôle fondamental pour la gestion des données. En effet, aucune information ne parvient aux modules de l’ECLR sans son accord. Cela signifie que l’AS est l’interface unique face au SAM et face à l’auteur de niveau 1.

Module n Module n+1 BdT externe AS Base de connaissances statiques Base de connaissances dynamiques BdT interne

Figure 5-9 : Plan de Supervision d’un ECLR

Comme l’AS possède un rôle capital dans la gestion des BdT externes et internes, nous allons les regrouper, comme le montre la figure 5-9, dans un même plan dont les périmètres sont juxtaposés à tous les modules de l’ECLR. Ce plan, appelé plan de Supervision correspond à la

Chapitre 5 ————————————————————————————————— ainsi que le résultat livré par chaque module, à gérer, maintenir et enrichir les bases de travail de l’ECLR.

Les BdT internes ou externes sont communes à tous les agents et à tous les modules pour des raisons surtout pratiques. Selon les tâches effectuées, les agents peuvent utiliser une base plutôt qu’une autre. Cet accès illimité et libre aux deux types de BdT permettent aux agents de mieux évaluer le contexte global c’est-à-dire qu’ils peuvent mieux estimer les souhaits de l’auteur de niveau 1 et faire un rapprochement avec les anciennes actions faites par les deux catégories d’acteurs (les agents et l’individu) pour s’assurer de la structure globale.

BdT interne Situation desirée BdT externe Situation perçue Reconnaissance de situation Apprentissage

Figure 5-10 : Statut opérationnel-cognitif de l’ECLR

La BdT interne regroupe les informations fixées (interdites ou non) dès le départ dans l’ECLR et par l’auteur de niveau 1, avec les anciennes informations apprises dans le temps et qui reflètent les souhaits de ce dernier pour la création de son nouveau logiciel. La BdT externe exprime la situation ou le contexte que veut mettre en œuvre l’individu à un moment donné, d’où l’expression situation perçue dans la figure ci-dessus. En effet, les agents du SMA ECLR perçoivent à travers l’analyse de l’action en cours, une situation voulue et résultante de l’action de l’auteur de niveau 1. L’accès aux deux BdT permet à chaque agent de mieux évaluer le contexte et par conséquent de retenir les informations utiles et donc d’optimiser l’apprentissage.

Cette distinction des bases de travail offre également l’avantage d’être facile à implémenter lors de la conception de l’ECLR lui-même.

——————————————————————————— Modélisation d’un ECLR