BoardZ Moodle Stat Project

L'exploitation des indicateurs et données stockées de BoardZ sera principalement déportée dans des applications tierces clientes de BoardZ.

Pour Moodle, des plugins d'intégration seront implantés dans la construction des pages Moodle, affichant aux utilisateurs une vue “invoquée” dans BoardZ.

Les autres applications pourront implémenter des “portlets” conduisant au même affichage dans leur propre contexte.

BoardZ fournit à toutes les applications tierces les vues sous divers formats de sortie, à travers un serveur de vues implémenté selon les protocoles standards de webservices. Les protocoles principaux envisagés sont Rest et Soap pour les applicatifs qui implémentent nativement des clients Soap. La structure de BoardZ découple l'implémentation du protocole d'échange de l'API des vues BoardZ pour permettre des adaptations et évolutions futures.

La structure générale du service de vues est scindée en quatre couches principales :

• Le point d'entrée : Pour la version prototype PHP, il s'agit d'un script serveur invoqué en http/https sous nginx ou apache (ou tout autre serveur web fournissant php7).
• La couche de réception de service : Elle traite le protocole d'échange de messages avec le client, et extrait les paramètres “métiers” de la requête. Elle peut également effectuer des contrôle généraux d'intégrité de type ou de structure d'entrées.
• La couche de présentation. La couche de réception de service oriente la requête vers un objet de présentation, responsable du rendu des données dans un format de sortie particulier. La couche de présentation peut proposer à son niveau un paramétrage des vues qui agissent sur le “rendering”.
• La couche de données est commune avec le serveur BoardZ de calcul des données. Elle accède à ses concepts d'indicateurs et de stockages pour obtenir les données affichables.

BoardZ fournit des sorties selon plusieurs formats de sortie (output). Ce paramètre de format est généralisé dans toutes les invocations.

Les formats envisagés sont :

• raw : Données brutes sans formatage.

• html : formatées en HTML.

• styledhtml : formatées en HTML + données de style.

• csv : Données structurées en colonnes avec un ligne de titres de colonnes

• json : Les données arrangées dans une structure json.

• debug : une vue spéciale plus techniquement verbeuse pour le deboggage.

Les vues de données sont construites à partir de deux éléments principaux :

• Les Widgets
• Les Panels

Le rendu de données est confié à des Renderers spécialisés dans les différentes mises en forme à produire :

Les Widgets présentent des données d'indicateurs dans une boite avec un titre et un contenu de boite. Le contenu exprime le résultat d'un Renderer.

Les Panels assemblent des Widgets dans un layout pour produire un tableau de bord composite dans une page.

Dans les évolutions envisagées, des structures multi-paneaux commutés par onglets seront possibles.

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

Le widgets reçoivent des données à publier sous différents affichages, formats ou représentation. Le responsable de la transformation des données brutes en une représentation affichable dans le widget (ou la sortie) est un Renderer.

Les Renderers seront en général responsables de la mobilisation de librairies spécifiques pour l'affichage sous les divers formats demandés comme des indicateurs graphiques, des graphes de données, des sorties XML ou Json.

Ils reçoivent des données et ont une configuration d'instance permettant de modifier localement certains aspects du rendu (par exemple les listes de couleurs pour une représentation en camembert). Les instances de renderers sont donc stockées dans la base de données Boardz.

Les données qui sont reçues doivent respecter une certaine construction selon leur structure, afin de faciliter le travail des développeurs de Renderers. le chapitre ci-après donne le détail de ces règles.

Les données fournies aux Renderers doivent respecter certains formats de construction en fonction de l'arité des données. On parlera désormais de “Résultat”.

L'objectif de cette desctription est de pouvoir faire effectuer des contrôles de cohérence dans les assemblages et les formules d'indicateurs et prévenir l'administrateur de statistiques lorsqu'il essaie de combiner ou de calculer des éléments non compatibles, par exemple :

1. des arités différences ou non combinables (par exemple, ajouter scalairement un entier et un tableau)
2. des arités similaires mais aux dimensions ou unités différentes et non compatibles

La donnée est une valeur scalaire numérique sans dimension (la dimension à afficher sera choisie comme option d'instance des Renderers associés. Elle peut également être associée comme métadonnée).

Le type de donnée est en général un “numeric” décimal.

Exemple de structure résultat :

  $data = [
      'data' => value,
      'dimensions' => [
          'users'
      ]
  ];

Dénotera explicitement d'un comptage d'utilisateurs.

Un tableau indexé donne un ensemble de résultats scalaires dans un vecteur “indexé”. Il est représenté par un tableau associatif :

 <index> => <valeur>

L'arité est de 1.

Exemple de structure résultat :

 $data = [
     'data' => [
         1 => 12,
         3 => 22,
         15 => 10
         23 => 43
     ],
     'dimensions' => [
         'courseid',
         'users'
     ],
     'arity' => 1,
     'aritycounts' => [
         4
     ] 
 ]

Les dimensions basés sur des “id” (userid, courseid, coursecatid, cohortid, roleid, sectionid, etc.) doivent impérativement contenir des indices “locaux” au Boardz, et disposer d'une table de translation vers des noms lisibles.

Cas particulier du tableau indexé : Données d'une courbe.

Les données de courbe sont des résultats indéxés par une séquence continue non dimensionée (0, 1, 2, 3, etc) ou par des étiquettes temporelles pour les courbes temporelles (153421123, 153421134, 153421148 pour des timestamps unix, '2019/03/12', '2019/04/20', '2019/04/28' ou autre format pour des expressions de date).

Des codes de dimension spécifiques pourront être utilisés :

Un tableau matriciel est in tableau indexé à 2, 3 ou N dimensions. Chaque niveau du tableau représente une dimension de la matrice.

Exemple de matrice :

  $data = [
      'data' => [
         1 => [
            3 => 10,
            23 => 0
            268 => 12
         ],
         3 => [
            3 => 2,
            23 => 0
            268 => 16
         ],
         32 => [
            3 => 0,
            23 => 0,
            268 => 0
         ],
      'dimensions' => [
          'courseid',
          'userid',
          'undef'
      ],
      'arity' => 2,
      'aritycounts = [
          3,
          3
      ],
  ];

Une matrice doit fournir toutes les valeurs d'indice dans chaque dimension (elle ne doit pas être dégradée vers un arbre).

les matrices sont transposables et sont équivalentes lorsque les dimensions sont interchangées.

Revenir au sommaire de la conception - Revenir au sommaire général