BoardZ Moodle Stat Project

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

Pour dissocier le plus possible projet du langage. Les “wrappers natifs” ont été généralisés et le principe fonctionne

Celui-ci s'appuie sur une classe TimeTrack (enregistreur temporel simple) pour mémoriser ses valeurs chaque fois qu'une horloge lui demandera de le faire. Le Renderer en tableau préfigure les futurs renderers de courbes car il reçoit un segment de données à afficher. La question étant de trouver un modèle d'architecture faclitant l'assemblage des différents constituants de la chaine, même si les données présentent une différence de structure et d'arité. L'indicateur historisé est conçu pour fournir en sortie une série de donées représentant l'évolution de l'indicateur dans un segment de temps (date à date, ou nombre d'échantillons fixé)

Au passage quelques schémas de base de données ont été révisés pour les simplifier.

Le HtmlPanel assemble des Widgets et des Panels en une structure de panneaux imbriqués pour assembler les différentes vues d'indicateurs ensemble.

L'objectif du projet étant de sortir un enregistreur d'indicateurs massif et robuste, s'est rapidement posé le choix de sa structure : En général deux stratégies sont plausibles :

• 1/ Un grand datawarehouse unique : les mesures (données individuelles) sont stockées dans une immense table avec plein d'index dessus. Les extractions d'indicateurs doivent effectuer des SELECTs dans cette table avec une combinaison de règles qui focalisent les données intéressantes.

Contrainte : si les indicateurs font appel à des “agrégats” ou des fonctions statistiques, la performance sur des centaines de millions d'échantillons peut être catastrophique, en tout cas avec des technologies open-source courantes.

• 2/ Des stockages localisés ultra spécialisés par donnée et par indicateur (ce que ferait naturellement un développement “pratique” dans architecture préalable) à partir d'objets simples.

Contrainte : la multiplication de centaines de milliers d'indicateurs simples génère une consommation et un gaspillage mémoire tous important, et il faut administrer une très grande quantité de paramètres pour obtenir un tableau de bord utilisable au niveau métier.

Ces deux approches théoriques sont donc fausses toutes les deux dans la réalité opérationnelle.

Nous partirons donc sur une approche médiane, un “en même temps” qui permet d'objectiver des indicateurs simples, d'utiliser cette objectivation tant que la demande fonctionnelle est générique et peu précisée, mais capable aussi de porter des objets plus “dédiés” à une structure particulière qu'elle pourra “optimiser en interne” (quitte à dé-normaliser l'approche architecturale générale).

Plus concrètement :

Un indicateur global par exemple, suivre le nombre instantané de connectés sur une plate forme est un indicateur simple. Il peut être monté dans une chaîne d'objets génériques de type “indicateur scalaire”.

Suivre simultanément quelques variantes de cet indicateur (par exemple, les connectés depuis 2 heures) peut être pensé en montant un panneau avec les deux widgets simples sur les deux valeurs.

Maintenant, prenons un indicateur plus complexe qui admet des modalités de paramétrage : je veux savoir le positionnement de chaque utilisateur par rapport aux participants, et ce dans chacun de ses cours. L'indicateur est de type simple, un “ratio”, donc un entier. Mais son arité n'est plus simple (scalaire).

Le résultat :

• Est paramétrique : l'utilisateur que l'on veut observer
• Produit une série de données (tableau) indexé sur les cours (mettons 30 UE de cours que suit l'étudiant)

Il apparaît dans ce cas très maladroit de monter cet indicateur avec une composition graphique de 30 widgets d'indicateur simples, ne serait ce que par l'occupation graphique des ces 30 boites et le gaspillage d'espace visuel. De plus, le paramétrage de la visualisation affectera les 30 valeurs à la fois (le changement d'utilisateur).

Donc un widget capable de supporter un indicateur complexe qui intègre toute la logique de ce cas de figure devient pertinent.

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