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.

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