BoardZ Moodle Stat Project

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

Le résultat principal de cette phase est l'implantation complète du système de transport de résultat entre les étapes du système que nous avons déjà commenté dans les précédents articles. Le système de résultat réagit très bien le long du chemin de traitement. Il permet de gérer de manière très contrôlée la connaissance de la structure des données transportées ou transformées à chaque étape. Pour l'instant, nous nous contentons d'exploiter ce formalisme pour garder le fonctionnement de la chaine de production des indicateurs sous contrôle. La partie “conception des indicateurs” ne l'exploite pas encore, mais on peut pressentir déjà comment nous pourrons intégrer ces métadonnées dans une assistance améliorée à l'administrateur ou au gestionnaire de données :

Les métadonnées de structure de résultat encodent respectivement :

• Ce qu'une source produit
• Ce qu'un résultat contient
• Ce qu'un élément terminal de la chaine accepte de consommer (un renderer par exemple)

Lors de la conception des indicateurs, les administrateurs de données vont créer des objets Boardz et les relier entre eux pour former un circuit depuis des entrées (Sources ou stockages) vers une sortie (actuellement renderers web, mais plus tard très certainement des documents). Les metadonnées décrivant les structures de résultat ou les “possibilités” ou “attentes” des objets interconnectés devraient nous permettre de pouvoir “auditer” automatiquement des configurations proposées (et peut être même, de directement contrôler les combinaisons possibles proposées lors de la conception). L'objectif est que la plate-forme fournisse un environnement facilité de conception d'indicateurs et de rapports en diminuant la quantité de connaissances préalables (ou sous-jacentes) nécessaire pour la configurer.

Ce résultat principal a permis de résoudre un certain nombre de chantiers liés :

Le calculateur algébrique fonctionne parfaitement, sur la base d'une “algèbre de résultats”. Toutes les configurations de données d'entrée ne sont pas encore toutes codées, mais déjà l'implémentation est significative et démontre la validité du concept : nous pouvons désormais :

• Parser des expressions arithmétiques y compris des expressions parenthésées
• Combiner des variables polymorphes (scalaires, matrices, associations, tableaux) et des constantes littérales
• Calculer avec des opérateurs arithmétiques (+ - * /) pour l'instant

En prévision :

• Introduction de “fonctions” (comme des pseudos-opérateurs unaires ou binaires)
• Codage des opérateurs include/exclude (fitrage par un autre résultat, ce qui se rapproche d'une opération de jointure positive ou négative)

Ce calculateur algébrique a été mise en œuvre dans l'indicateur ComplexIndicator, qui se base sur le calcul d'une expression combinant les résultats d'un certain nombre de mesures et/ou sous-indicateurs.

L'ancien POC proposant une résolution algébrique limitée à des données scalaires a été remplacé par le nouveau calculateur sur les “résultats”. Le résultat est concluant.

Pour ce qui est des indicateurs, il semble que pour l'instant 3 indicateurs soient suffisants pour la plupart des besoins :

• SimpleIndicator : pour une mesure simple (mise en place minimale)
  • –> Pour la mise en place simple d'une mesure dans un widget, dans un contexte connu et fixe.

• DataSerieIndicator : transforme un ensemble de mesures en une série de données (assoc ou matrice). Le concept n'est pas encore bien terminé, car il faut traiter les cas où les mesures de base sont elles-mêmes structurées. En tout cas, il s'agit de combiner les données pour les assembler dans une structure (et non les réduire en les calculant).
  • –> Pour la réunion, par exemple de 5 indicateurs dans une série de données compatible avec un renderer de type GraphJSRadar

• ComplexIndicator : prend des mesures et des indicateurs et les calcule selon une formule paramétrée.
  • –> Pour obtenir par exemple un écart à une moyenne, ou un ratio relatif par rapport à une somme globale

La mécanique de “drill up and down” fonctionne in fine comme cela avait été supposé par la conception :

Si la mesure est multidimensionnelle par construction alors le principe de propagation des paramètres d'entrée pour fixer les dimensions permet de focaliser très facilement sur un sous-résultat.

La technique se révèle particulièrement simple car elle se réduit à l'ajout d'un paramètre de requête. Ces paramètres reçus par l'interface d'invocation du Widget (ou via un Panel d'assemblage) sont maintenant propagés tout au long de la chaîne jusqu'aux mesures dont ils peuvent altérer l'acquisition. La mesure va donc fournir un résultat différent en fonction du niveau de drill-down imposé par les paramètres d'entrée. Si les Renderers utilisés dans les vues sont adaptatifs, alors une représentation adéquate sera mise en oeuvre en fonction de la structure effective du résultat.

L'objectif principal qui est visé par ce chantier est de pouvoir obtenir un schéma très uniforme d'invocation des vues dans leurs différentes dimensions. Ceci devra faciliter les futures stratégies de “navigation intégrée” dans les vues, c'est-à-dire offrir des liens permettant de “naviguer” dans un jeu d'indicateurs assemblés en tableaux de bords liés.

Pour obtenir cela de manière maîtrisée et bien outillée, il faut que la façon d'invoquer les vues disponibles soit construites sur un même schéma, quelque soient les données observées. La construction des URLs de navigation sera à ce moment largement simplifiée et pourra être systématisé dans les structures du Boardz.

Le principe découle directement de la technique des “Result”. Le résultat qui atteint de Renderer en entrée porte suffisamment de méta-information pour informer le Renderer sur la structure des données incluses. Sur la base de ces informations, un Renderer peut décider en interne, de changer de stratégie d'affichage suivant la structure ou la taille des données à afficher :

Exemple : soit une mesure définie comme multidimensionnelle :

le nombre de visites par cours et par utilisateur.

Au niveau le plus haut de requêtage, le résultat est une matrice [cours][utilisateur] ⇒ fréquentation.

Si le cours est forcé par la requête, alors le résultat se “dégrade” en tableau associatif d'arité 1 : la fréquentation par utilisateur pour un cours fixé. Si de plus on force un drill-down sur l'utilisateur, alors le résultat n'a qu'une seule valeur scalaire.

Le Renderer devra donc prévoir une stratégie d'affichage pour ces trois dimensions possibles du résultat. Il saura facilement basculer entre ces réalisations. Les Renderers ne sont pas “tenus” d'accepter toutes les dimensions.

Certains Renderers ne seront développés que pour accepter certaines structures, soit par “construction”, soit parce que les cas d'usage de certaines dimensions ne sont pas révélés. Il sera toujours possible de faire évoluer ces Renderers vers une construction plus adaptative lorsque le besoin s'en fera sentir.

L'hypothèse d'alimentation des cubes temporels partiels, à partir du cube principal du Boardz a été vérifiée. Elle met en oeuvre une “mesure” particulière qui travaille d'un stockage vers un autre stockage. Une tâche automatique régulière active cette mesure en fond de serveur pour alimenter les compilations résultantes. La même mesure permet de ré-extraire une partie de ces données produites en direction d'indicateurs.

On note ici une évolution du concept de Mesure :

Il s'est révélé utile de dissocier deux fonctions différentes d'une mesure : la fonction d'acquisition, et la fonction de fourniture de la mesure.

La fonction d'acquisition sollicite une Source de données, capte les données mesurées, et les range dans un stockage. Cette opération est asynchrone et indépendante des sollicitations que les usagers font aux rapports.

La fonction de “fourniture” de données fournit au demandeur une partie des données détenues dans le stockage selon des paramètres contextuels à la demande.

Certaines mesures n'ont pas l'étape intermédiaire du stockage et peuvent adopter un fonctionnement plus simple en fournissant le résultat direct de la sollicitation de la Source.

Une fois la mécanique d'acheminement des résultats obtenue, on se rend compte que les résultats portent des données indexées par les IDs internes.

Elles sont donc impropres à un affichage “exploitable” par le métier. Il est nécessaire de transformer un certain nombre d'informations en “nom utilisables” par le lecteur du rapport. Une fonctionnalité générique de “résolution de noms” a été ajoutée et implantée dans le traitement final des Résultats, juste avant “livraison” aux Renderers.

Exemple : je veux rendre un tableau qui présente les noms des courts au lieu des ID de cours.

La technique et la forme de cette transformation est encore en cours de réflexion sur les aspects suivants :

• Transformer les noms ne doit pas perdre les ID initiaux, car ceux-ci serviront probablement dans la construction d'URLs de navigation dans les vues.

• La transformation est aujourd'hui prosaïquement effectuée sur une hypothèse uniquement “Moodle”. Il faudra réfléchir à la généraliser si d'autres applicatifs venaient à être pris en charge par BoardZ.

Les travaux sur les outillages suivants continuent :

• Sécurité du serveur, contrôle des entrées, injections, etc.

• Contrôle et mesure de la performance : l'hypothèse d'architecture a visé la résolution d'une problématique massive. Les performances de calcul et les “benchs” de chaque portion de la solution doivent pouvoir être surveillés et monitorés.

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