| |
Le serveur BoardZ est un outil général de calcul statistique pour un où plusieurs Moodle. Il récupère des données de journalisation brutes et les agrège dans des résultats statistiques et des indicateurs.
Le serveur doit connaître un certain nombre de données de contexte afin de pouvoir qualifier les présentations de données et permettre de définir les indicateurs dans les contextes de validité du calcul.
A cette fin, le serveur va aspirer des données nécessaires et suffisantes à la qualification des données traitées. Ces données sont beaucoup moins nombreuses que les données “opérationnelles de moodle” et consistent en général à des tables de libellés affichables pour clarifier les résultats. Par contre, l'architecture de ces données doit représenter une image fidèle de l'architecture de gestion de moodle et représenter ses objets fonctionnels principaux.
La définition de ce modèle de données inspirera fortement les “domaines et la segmentation d'administration” du serveur. La représentation suivra une définition hiérarchique proche de l'organisation des contextes de moodle :
Ce niveau permet d'isoler un projet de mesure qui porterait sur plusieurs instances de Moodle assemblées en réseau ou en coopération fonctionnelle.
Un groupe d'hôtes est assimilable à un nom arbitraire.
Le groupe d'hôtes intervient comme espace le plus large que lequel un indicateur peut être aggrégé pour fournir une valeur globale.
| Champ | Information |
|---|---|
| id | Identifiant primaire |
| name | Nom du groupement |
Assimilable à une identité wwwroot unique.
Un hôte définit un contexte d'extraction de métadonnées de structure et une source de logs à traiter dans un récepteur propre. Les paramètres techniques de ces fonctions d'obtention de données sont propres à chaque hôte.
L'hôte constitue également une portée d'aggrégation pour obtenir des indicateurs globaux pour l'instance de moodle associée.
| Champ | Information |
|---|---|
| wwwroot | Identifiant primaire |
| name | Nom affichable |
| hostgroup | Référence au groupe d'hôtes |
Assimilable à l'ID numérique de la cohorte ou à l'IDNumber de cohorte.
| Champ | Information |
|---|---|
| wwwroot | hôte |
| id | identifiant primaire de cohorte |
| idnumber | identifiant secondaire de cohorte |
Assimilable à un id interne, l'IDNumber d'utilisateur ou son username.
Il est défini essentiellement par une identité lisible associée à cet ID. La portée “utilisateur” doit pouvoir être désactivée si le contexte d'usage du serveur ne peut être résolu en termes du RGDP, laissant le serveur uniquement calculer des données statistiques aggrégées non nominatives.
La conception des fonctionnalités contingentées à l'utilisateur devra prendre en compte des descripteurs RGDP capables de fournir toutes les indications sur le traitement nominatif tel que :
- la liste des indicateurs individuels configurés et activés, renseigné par l'objectif d'utilisation de ces indicateurs (texte informatif). - un export des données calculées d'un utilisateur nominatif.
Les principes d'effacement de l'ensemble des indicateurs individualisés d'un utilisateur particulier devront être proposés.
Le username étant obligatoire, on le prendre de préférence comme identité primaire. Le cas des utilisateurs importés par réseau Moodle (MNET) nécessite que l'identité complètement qualifiée tienne compte de l'origine de l'utilisateur. Dans une constellation de moodles interconnectées, les identifiants internes d'hôtes MNET d'origine ne sont pas uniformes d'une plate-forme à l'autre. La mention du wwwroot dans l'identifiant complètement qualifié suffit cependant à résoudre cette question, car la valeur du wwwroot est par contre unique et uniforme pour une instance moodle donnée.
Identité primaire : username / Identité accessoire : IDNumber / FQDN : wwwroot/username
| Champ | Information |
|---|---|
| wwwroot | hôte d'origine |
| username | identifiant primaire |
| firstname | Prénom |
| lastname | Nom |
| department | Département -division d'organisation) |
| organisation | Organisation |
| pays | Pays |
| cust1 | champ qualifiant customisé 1 |
| cust2 | champ qualifiant customisé 2 |
| cust3 | champ qualifiant customisé 3 |
| cust4 | champ qualifiant customisé 4 |
Assimilable à un identifiant unique dans l'hôte Moode par l'ID numérique ou par l'IDNumber. L'ID numérique est présent à coup sûr dans l'instance cible. L'IDNumber n'est pas toujours garanti et dépend de la qualité et du degré d'automatisation de la chaîne d'alimentation amont (ERP).
Identité : Id Identité accessoire : IDNumber FQDN : wwwroot/Id
Assimilable à un id interne de cours, à un IDNumber ou au nom court du cours. L'IDNumber n'étant pas une information garantie, le 'shortname' (nom court) du cours sera l'identité primaire visible.
Identité primaire : shortname / Identité accessoire : IDNumber / FQDN : wwwroot/shortname
Les modules d'activité sont assimilables à un id de “module de cours” ainsi qu'à un IDNumber, toujours sur le module de cours. Un des problèmes courants rencontrés dans les stratégies d'administration globales est la très faible mobilisation dans l'usage des IDNumber de modules. En effet, il existe très peu de cas où les modules de cours (activités et ressources) sont produits
Cette portée d'administration est laissée à une évolution ultérieure.
Les dépendances entre données de contexte peuvent être comprises comme des dimensions successives d'axes d'analyse qui permettent une exploration dans des niveaux de détail multiples.
Les contextes de gestion ci-dessus peuvent être assemblés pour définir :
Groupes d'hôte » hôte » catégorie de cours » Cours » Section (ou page) » Type de Module » Instance
Pays » Organisation » Département » Fonction » Utilisateur
Hôte » Cohorte » Utilisateur
et si l'analyse porte sur un cours ou un groupe de cours disposant d'une construction cohérente de groupes :
Hôte » Cohorte » Groupe » Utilisateur
Les notions de groupes et de cohortes étant des relations NxN entre les utilisateurs et respectivement les groupes et les cohortes, les axes ci-dessus n'en proposent qu'une vision restreinte pour des usages où :
Pour permettre de réduire certains environnements à cette contrainte, et si nous prenons l'exemple particulier des cohortes, il faudra pouvoir exclure des définitions examinées celles qui font sortir les données de la restriction proposée. Dans cet exemple, s'il existait par exemple des cohortes basées sur les découpages de promotion ET des cohortes transverses, par exemple de groupes de langues, alors l'une de ces deux dimensions orthogonales devraient être exclues de l'analyse.
Revenir au sommaire de la conception - Revenir au sommaire général