BoardZ Moodle Stat Project

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

Après une petite correction le calcul du cube calculé est maintenant stable. On peut itérer sur le processus de calcul en remettant à jour les données. Un travail ultérieur s'intéressera à l'optimisation du calcul.

Requête paramétrique sur le cube (et par extension requêtage paramétrique 'en général“ dans boardz

Les principes de réception des paramètres de contexte d'une demande d'affichage sont établis et implémentés : Les paramètres de requêtes (queryparams) sont capturés, transmis au panneau puis distribués sur les widgets (ou transmis au widget si on invoque directement le widget). De là les paramètres redescendent sur les indicateurs et sur leurs composantes respectives (mesures ou sous indicateurs), afin d'influencer leur fonction interne de récupération de données ou de calcul de données.

Les descentes de paramètres sur le MoodleCube permettent d”établir à ce niveau un premier principe de gestion de l'arité (nombre de valeurs dans un résultat et organisation de ces valeurs). Cette gestion est essentielle pour permettre de faire fonctionner correctement des assemblages de fournisseurs de données avec un moteur de rendu associé. Pour ce qui est des mesures sur le cube (ce sont elles qui sont sollicitées pour afficher un indicateur, on peut établir que l'arité d'un résultat est établi par le formule suivante :

Q* - QPe

où

Q* est le nombre de dimensions de groupes (*/for each) de la mesure, et ou QPe est le nombre de dimensions exprimées dans les QueryParams

Exemple :

• Si une mesure calcule un résultat par cours et par cohorte, alors l'arité maximale du résultat d'interrogation de la mesure est 2.
• Si la requête sur l'indicateur vient expliciter une des deux dimensions (par exemple l'explicitation de la cohorte à cohortid=2), alors l'arité du résultat baisse d'une unité.
• Si les deux dimensions de groupes sont explicitées alors la dimension du résultat tombe à 0 (résultat scalaire).

Ceci sera très important pour le pilotage des fonctions de rendu associées à l'indicateur. Pour l'instant, nous forgeons des fonctions de rendu qui sot mono-arité, c'est à dire, ne peuvent répondre qu'à une seule arité (0, 1, 2 ou plus) à la fois. Les besoins d'indicateur à court terme doivent s'en suffire à première vue. Plus tard, nous pourrons forger des fonctions de rendu pus “adaptatives” : L'idée d'une pseudo-fonction de rendu mettant en jeu des sous-fonctions de rendu à travers un choix conditionnel est plausible, de la même manière que nous intégrons la possibilité de forger des indicateurs à partir d'autres indicateurs, le raisonnement d'architecture sera très similaire.

L'indicateur complexe \boardz\data_processing\ComplexIndicator fonctionne, avec un mécanisme de formule paramétrique.

Cette phase de développement a permis de mettre en pratique (et de consolider) le principe des fonctions de rendu. L'implémentation a fait apparaître la nécessité que les fonctions de rendu devaient également être des objects “instanciables” de Boardz et pas seulement des objets globaux et “en dur”.

Cependant, certaines fonctions de rendu n'ont pas besoin d'instances, soit parce qu'ils ont pas de paramètres à faire varier, soit que les choix de paramètres sont plutôt de l'ordre d'un réglage global de boardz :

Exemples :

• Le \boardz\renderer\ScalarRenderer (qui affiche simplement une valeur numérique), n'a pas de paramètre propre de rendu.
• Les \boardz\renderer\CsvRenderer ou \boardz\renderer\XMLRenderer, dont les paramètres d'ordre technique (Encodage du résultat, fins de ligne et séparateur de champs) sont plutôt d'un ordre “environnemental du SI”, en général.

Deux attributs spéciaux : nondeletable et nomutable, permettent de verouiller certaines possibilités d'administration pour ces objets. On ne peut donc ni supprimer ni éditer une fonction de rendu \boardz\renderer\ScalarRenderer.

Afin d'anticiper sur les point qui suivent, le serveur Rest a été complété par un \www\server\JsManager qui vient compléter le \www\server\StyleManager.

Ces deux objets (singletons) sont respectivement responsables de la gestion des javascripts et des styles, collectés tout au long du processus de montage de la page Web. Ainsi les classes de grapagre pourront injecter leurs librairies (pre-requis et post-requis) ainsi que leurs appels aux feuilles de style qu'ils utilisent.

La séquence d'assemblage de sortie a été corrigée pour que la collecte puisse agréger les pré-requis (appels de script ou de style à afficher AVANT le contenu, ou post-requis, idem, après le contenu).

Après un premier essai sur une fonction TrafficLightRenderer qui pose les bases d'interaction entre une fonction de rendu, un widget appelant et l'indicateur associé au widget, nous avons commencé l'intégration d'une première libriaire de graphes. Après analyse des propositions et recherches, nous ne retenons pas immédiatement la libraire HighCharts pour des raisons de license, et d'une complexité à gérer les reports de droits dans le cas d'un usage non académique du moteur. Les premières intégrations sont faites sur une librairie très connue (charts.js), complètement libre, simple à intégrer et suffisament flexible pour proposer les modèles attendus de graphage à court terme. Cependant, le modèle architectural étant ce qu'il est et le découplage fonctionnel étant clairement établi, il sera très facile de continuer à développer des nouvelles prises en charges sur d'autres librairies, enrichissant ainsi l'offre en Renderers disponibles.

2 renderers sont ébauchés actuellement :

• Le \boardz\renderer\GraphJSRadarRenderer
• Le \boardz\renderer\GraphJSBarRenderer

Ils fonctionnent dans une configuration de données simple et bénéficient d'un paramétrage de base. La poursuite des travaux viendra au fur et à mesure augmenter la paramétrabilité de ces renderers si besoin.

Ces fonctions sont instanciables, contrairement, par exemple, au ScalarRenderer. Cela veut dire que l'on pourra invoquer autant d'instances de ce renderer que nécessaire, avec des paramétrages différents. Bien entendu, plusieurs indicateurs différents pourront réutiliser la même instance de fonction de rendu, tant que leur arité de sortie est compatible.

Les prochains renderers à sortir seront :

• le GraphJSLineRenderer
• le GraphJSTimelineTenderer

Ils fournissent des tracés de courbe sur des axes respectivement scalaires / temporels.

Surveillance annexe des performances et indicateurs de fonctionnement du Boardz. Des accès à des futurs panneaux “Système” pour la surveillance organique de boardz ont été ajoutés.

Les écrans d'administration du boardz ont été épurés (formulaires de configuration d'objet)

Il sera rapidement à prévoir une montée en fonctionnalité des listes d'administration des objets du Boardz, en prévision d'une forte augmentation du nombre d'instances d'objet Boardz à définir. Pagination et filtrage devront être implémentés.

Dans certains cas de figure est apparue la nécessité de pouvoir saisir des “listes ordonnées d'items” à partir d'un pool initial d'options. Malgré mes recherches, je n'ai absolument trouvé aucun précédent dans la littérature Jquery, QuickForm ou ailleurs. On pourrait envisager lancer ce chantier.

Un balayage du projet antérieur a permis d'identifier la plupart des requêtes d'indicateurs de la première version. C'est une source important pour la poursuite du travail car il faudra les “faire rentrer” dans le nouveau modèle. L'analyse a pu permettre de comprendre pourquoi ce modèle ne pouvait tenir à la charge d'une base moodle opérationnelle lourdement remplie. N

Nous pouvons également donner quelques éléments comparatifs :

Il reste cependant un grand nombre de résultats déjà établis dans la version 1 à récupérer et réintégrer.

1. Continuer à implémenter les fonctions de rendu

1. Afin de pouvoir travailler certains indicateurs, il sera nécessaire d'injecter dans le cube moodle des données ne pouvant provenir directement des logs moodle, mais d'autres requêtes SQL plus générales lancées sur la base de données moodle, et résultant en une donnée qui peut être qualifiée dans l'espace dimensionnel du cube (ou au moins un sous espace pertinent). Cela donnera lieu à une classe \boardz\data_processing\MoodleCubeSqlMeasurement

1. Forger un principe de mesure \boardz\data_processing\MoodleStructureMeasurement sur le modèle local de structure de moodle (afin d'obtenir le résultat d'un certain nombre de fonctions de comptage de l'architecture boardz précédente.) Ces mesures pourront alors servir de composantes dans des formules d'indicateurs.

1. Commencer à préparer dans quelle mesure une partie du travail pourra être distribué, notament, la création d'un certain nombre de configurations dans le prototype installé sur Avignon pour “reconstruire” les panneaux d'indicateurs principaux.

Pour aider à cet objectif, il faudrait ressortir l'inventaire des indicateurs et les hiérarchiser par importance décroissante. Il faudra que l'identification des fonctions du premier modèle soit possible pour retrouver rapidement l'implémentation des calculs, et voir au cas par cas comment ils peuvent être réintégrés dans le nouveau modèle.

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