Différences

Ci-dessous, les différences entre deux révisions de la page.

--- boardz:journal27012020 [2020/01/27 09:44] – florence
+++ boardz:journal27012020 [2026/01/13 08:03] (Version actuelle) – modification externe 127.0.0.1
@@ Ligne 1: / Ligne 1: @@
 |
-===== JOURNAL DE BORD au 16 Décembre 2019 =====
+| {{ :avignon-universite.jpg?nolink|}} | {{ :blocks:logo-apl.png?nolink&220|}} |
+===== JOURNAL DE BORD au 27 janvier 2020 =====
 ===== BoardZ Version 2 =====
@@ Ligne 43: / Ligne 44: @@
   * **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.
+         * --> 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
+    *-->  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
+=== Chantier Pilotage des vues en drill-up drill-down===
+**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.
+=== Chantier Renderers adaptatifs===
+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.
+===Cube multidimensionnel===
+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.
+====Fonction de résolution des noms des dimensions====
+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.
+====Travaux de l'infrastructure logicielle====
+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.
 ----
 [[boardz:journal|Sommaire du journal]] - [[:start|Revenir au sommaire général]]