BoardZ Moodle Stat Project

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

Selon les premières requêtes dans l'implémentation ancienne du boardz, il y a en effet pas mal de requêtes qui pouvaient mettre à mal la base de données du fait de leur complexité, et qui n'étaient pas exportées de la base opérationnelle de moodle.

Le travail consiste à voir quelles sont celles qui peuvent être implémentées dans le nouveau modèle et s'il y a delta, comment résoudre le delta.

Nous avons une chaîne générale qui va d'une source à un widget en passant par :

Datasource (ou storage) ⇒ Mesure (captation) ⇒ Indicateur (calcul) ⇒ Renderer (rendu) ⇒ Widget (placement)

Dans l'autre sens notre architecture peut recevoir des paramètres d'entrée pour les acheminer dans le sens inverse :

Utilisation (requéreur) ⇒ Widget (entrée de paramètres contextuels) ⇒ Indicateur (contextualisation du calcul) ⇒ mesures (contextualisation de la mesure) ⇒ Datasource ou storage (paramétrage de la requête sur les données)

Le paramétrage contextuel d'une requête peut avoir des effets importants sur le nombre de données récupérées et leur organisation (arité, taille des dimensions, organisation des données). Il était donc important de pouvoir s'assurer de:

• La cohérence des données transmises entre chaque couche

• Que les calculs des indicateurs assemblent des données d'une forme compatible pour les calculs de l'indicateur

• Que le Renderer adéquat sera choisi quelque soient les valeurs d'entrée contextuelles de la requête, et donc quelle que soit l'arité du résultat (il n'est pas adéquat de présenter une courbe là où une seule valeur scalaire est présente dans le résultat, suite à la focalisation de la requête).

Pour cela je modifie la façon et le format dont les données sont transmises depuis les mesures jusqu'au renderers, afin de :

• Normaliser la construction des données pour les différentes arités (scalaire, séries de données, séries multiples, matrices… etc)

• Disposer des métadonnées nécessaires et suffisantes dans le résultat pour pouvoir “qualifier” la nature et la forme des données et pouvoir faire les opérations de contrôle et d'adaptation susvisées.

Pouvoir tirer un parti maximum des objets Boardz créés sans programmation supplémentaire en leur permettant, pour un calcul donné, une grande flexibilité d'utilisation des données résultat. Là où il faudrait revenir au développement pour chaque contextualisation de la requête, la chaine technique de données doit pouvoir s'en sortir de manière auto-adaptative pour répondre aux requêtes contextuelles sur un indicateur donné. Sont principalement visées :

• A partir d'une définition d'indicateur : la production adaptative de tous les sous-contextes de résultats que l'on demande d'afficher (par exemple, la production de chaque indicateur personnel d'étudiant, paramétré par son userid)

• Les possibilités d'organiser des drill-down / scale-up de l'observation d'un indicateur par simple modulation des URLs et des paramètres de requête associés (le moteur produisant mécaniquement intrinsèquement l'ensemble des réponses possibles)

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