BoardZ Moodle Stat Project

Bienvenue dans le volume de documentation de conception de BoardZ Version 2.

Actuellement nous sommes sur 2 sujets clefs du fonctionnement du moteur de calcul :

• Un calculateur de résultat
• la résolution des index

Nous avons terminé la mise en place de la formalisation du concept de Résultat :

Un objet transportant des données “résultat” issu d'un de nos constituants et suffisamment méta-renseigné pour savoir à quelle structure de données on a affaire.

Le “Result” permet donc d'encoder correctement la variabilité de la sortie d'une source de données ou d'une mesure, en fonction du nombre de paramètres de restriction de “focus” qu'on lui fournit.

Le résultat peut donc évoluer depuis un simple “scalaire jusqu'à des associations de données ou des matrices à plusieurs dimensions.

Cette formalisation permet de passer à la suite :

Un calculateur algébrique de résultat, capable de calculer une transformation de résultats à partir d'une formule. C'est quelque chose qui peut être assimilé au moteur de calcul par formule d'Excel.

Ce calculateur est à la base du principe d'indicateur complexe, capable de calculer une sorite à partir de résultats de mesure ou d'autres sous-indicateurs.

Le moteur de calcul est donc un organe essentiel. il effectue donc des calculs “dimension aware” selon le type de structure de ses opérandes, afin de servir nos besoins sémantiques de construction d'indicateurs complexes.

En voici quelques exemples (non exhaustif) :

• Calculs scalaires : (les deux opérandes sont scalaires), la sortie est scalaire :
  • +, - , * /

• Calculs scalaire vs. associatif (ou tableau ou matriciel) :
  • Arrray + Sca (ajoute à tous les membres) - commutative
  • Assoc + Sca (ajoute à toutes les valeurs) - commutative
  • Matrix + Sca (ajoute à toutes les valeurs de la matrice) - commutative
  • idem avec -, * et / (- et / ne sont pas localement commutatives)

Toutes ces opérations sortent la plus grande structure en sortie

• Calculs tableau vs. tableau :
  • +, -, *, / (membre à membre, sous contrôle d'avoir une même taille de dimension)
  • ^ et ! : resp. intersect et exclude : garde ou exclut les valeurs du premier opérande en fonction du second.

• Calculs associatif vs. tableau:
  • ^ et ! : resp. intersect et exclude : garde ou exclut “par clef” les valeurs du premier opérande

• Calculs associatif vs. associatif :
  • +, -, *, / (membre à membre, par clef. Les clefs manquantes dans l'un des opérandes sont considérées comme existantes à valeur nulle. La résultante des indexes est donc un union des clefs.)
  • ^ et ! : resp. intersect et exclude : garde ou exclut “par clef” les valeurs du premier opérande par les clefs du second opérande (les valeurs sont ignorées)

• Calculs matriciel vs. associatif :
  • +, -, * , / : opère la correspondance sur les clef de première dimension et réduit le calcul localement à un Assoc * Scal

En cours de réflexion :

• Autres cas de matrices
• Intégration de “Fonctions” (MIN, MAX, ABS, AVG, etc)

En cours de test :

Le fonctionnement de la pile d'exécution des motifs parenthésés.

Exemples de cas de calcul visés :

Calcul des écarts normés (sur -100, 100) par rapport à une moyenne : Soit deux mesures : %MA et %MM, respectivement donnant :

• %MA : le nombre d'accès par étudiant à un cours donné (le cours courant) ⇒ Assoc [userid ⇒ Q]
• %MM la moyenne (scalaire)

Soit un indicateur %IA forgé à partir de %MA = %MM comme max(abs¹⁾ qui mesure le maximum des écarts à la moyenne (sortie scalaire)

On vise le résultat suivant :

%IB = (%MA - %MM) / %IA * 100

Le type de résultat de sortie est donné par :

? = (assoc - scal) / scal * 100 ? = (assoc / scal) * 100 ? = assoc * 100 type de sortie “assoc'

Voici l'exercice de montée à la dimension supérieure :

Avec le même mécanisme de calcul et la même définition des mesures, nous souhaitons pouvoir accéder à la généralisation du même résultat, mais “par cours et par étudiant” %MA : on étend la mesure à une matrice [courseid][userid]⇒Q %MM : on étend la mesure de moyenne à une assoc [courseid]⇒M

Le moteur de calcul algébrique peut travailler avec des clefs numérique ou textuelles.

En général les résultats issus du cube ou de requêtes complémentaires sont indexées sur “IDs” (les IDs peuvent être distants ou locaux, selon le cas).

Le problème à résoudre étant, à un certain moment donné de la chaine de traitement, celui de la “résolution des indices” c'est-à-dire leur traduction en libellés “lisibles et compréhensibles par le métier”.

Une réflexion est en cours pour voir :

• A quel moment de la chaine de traitement cette résolution doit être faite.
• Comment cette résolution impacte-t-elle la définition d'un “Résult”.
• Comment cette résolution impacte-t-elle la forme des “Renderers” (qui seront les clients les plus “demandeurs” de données résolues pour l'affichage dans les Widgets).
• Quelle doit être l'architecture “logicielle” de cette fonction.

Une bonne hypothèse de départ serait d'essayer de retarder au plus loin possible (dans les Renderers) le moment où on invoque cette résolution, juste avant la fourniture des données aux librairies techniques de graphage ou de “plotting”.

Cela suppose que les “unités” des indexes soient bien définis et explicitement connus dans la structure résultat.

Un extracteur de données quelconques de moodle pour injection dans le cube (permet d'enrichir le cube avec des données non issues des logs).

Quelques résultats qui fonctionnent bien

• L'invocation des widgets à partir de Moodle fonctionne correctement (en mode IFrame, actuellement).
• La “réponse multidimensionnelle adaptative” (en fonction des paramètres d'entrée) fonctionne bien. Les mesures s'adaptent en type, taille et unités selon les paramètres de contrainte de l'interrogation.

Sommaire du journal - Revenir au sommaire général