BoardZ Moodle Stat Project

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

• Avancées au 07/05/2019
• Avancées au 12/05/2019
• Avancées au 22/05/2019
• Avancées au 06/09/2019
• Avancées au 14/10/2019
• Avancées au 11/11/2019
• Avancées au 16/12/2019
• Avancées au 24/01/2020
• Avancées au 27/01/2020
• Avancées au 10/02/2020
• Avancées au 17/02/2020

Nota :tous ces objets commencent par fournir une abstraction de base, et vont être concrétisés dans des déclinaisons spécialisées. (par exemple, une MysqlDatasource pour une source de données utilisant une base de données Mysql)

• Mesure : Ensemble des informations permettant d'obtenir une valeur unique d'une source (on admet qu'il puisse s'agir d'un tableau de valeurs uniques ayant la même sémantique et unité). Le mesure décrit “comment” on obtient la valeur, si une source appropriée est sollicitée, mais ne détient pas d'information sur la source.

• Indicateur : : Un indicateur contient une ou plusieurs mesures, et représente une formule qui permet de les combiner pour produire la sortie effective de l'indicateur. Certains indicateurs de type complexe peuvent intégrer comme mesure la sortie d'autres indicateurs, proposant une construction récursive du calcul si nécessaire.

• Une “Source de données” : (Datasource) : un objet qui peut se connecter physiquement à un entrepôt de données (une base de données, un fichier, un web service) et utiliser les descriptions d'une mesure pour trouver, extraire et rendre la donnée désirée. Dans un premier temps, on implémente une source de type SQL et éventuellement une source WS REST.

• Un “Storage” : Il prend en charge l'enregistrement persistant des données qui sont obtenues par les mesures. Le Storage peut être scalaire, ou indexé, ou encore temporalisé.

• Un “Trigger” : Un objet jouant le rôle d'une horloge pour déclencher des choses à intervalles régulier. Un trigger enregistre un callback dans un objet.

• Un “Sampler” (ou sonde) : c'est un objet complexe assemblant un storage, un indicateur et un stockage pour offrir un ensemble complet de capture d'un indicateur. Le serveur définit une collection de samplers par configuration statique ou chargement des défintions constituées dans la base de données de BoardZ, il enregistre ses triggers et joue une boucle permanente sur tous les triggers pour actionner les captures.

• Un “Widget” : Un objet qui est la partie visualisable d'un indicateur. Un widget s'associe à un indicateur pour être invoqué seul, ou être assemblé dans un panneau (Panel). Le Widget peut être associé à un ou plusieurs Renderers comparables pour offrir plusieurs mises en forme alternatives de l'indicateur.

• Un “Panel” : Un container qui peut assembler un ensemble de widgets avec un placement.

• Un “Renderer” : Un objet qui met en forme des données brutes et produit une sortie visualisable (ou simplement exportable)

• feeder“ ou alimenteur : Elle complète les “sammplers ou sondes”, et traite un flux d'entrée massif provenant d'une source de “flux” (feed) comme par exemple la sortie du plugin report_etl d'exportation des logs.

Un travail est mené sur la formalisation des questionnements que l'ont veut obtenir du Boardz. Le but étant de trouver un modèle conceptuel formel de description qui :

• permet d'intégrer les questions du cahier des charges
• reste ouvert et extensible
• permette d'envisager à terme une GUI compréhensible de configuration et d'administration.

L'objectif est :

• De trouver dans l'ensemble des questions des formes (patterns) qui isolent des éléments formels syntaxique récurrents et constants, donc extractibles dans des concepts opérationnels et des implémentations formelles.
• De poser suffisamment de questions pour voir dans quelle mesure ces éléments formels syntaxiques résistent à la diversité des cas de figure possibles, la variablilité des demandes et de leurs contextes.

Il s'agit de trouver les éléments de base d'un jeu de légo qui permettent de répondre au problème tout en permettant par la suite des optimisations ciblées sur des éléments dont la “responsabilité” dans le système sera parfaitement déterminée et circonscrite.

Dans ce concept du Lego, nous essayons de trouver des objets et leurs “connecteurs” qui propose un ensemble cohérent de pièces qui peuvent s'assembler naturellement dans une grande combinatoire, ce qui nous donnera une capacité importante de réponse à des problèmes nouveaux.

Pour les briques de calcul d'indicateurs, nous examinons surtout la notion d'entrée (ou de sous-constituants) et la notion de sortie. Quelles sont leurs caractéristiques et par quoi peut on déterminer qu'une sortie peut se “brancher” sur une entrée. Nous examinons s'il est possible de nous rapprocher des objets administrés de moodle, notamment à travers la notion de “contexte”, puisque les contextes identifient dans une bonne mesure les objets “administrables” de Moodle.

La compatibilité des contextes d'une sortie avec une entrée parait une première piste.

Indicator Expressions that the model should serve :

I want to get the (amount of submitted available(not hidden) assigns) [per] course [for each] user

• outputs : userid ⇒ courseid ⇒ scalar (context course)

I want to get the (amount of submitted available(not hidden) assigns) in [each] course [of the] user

• outputs : courseid ⇒ scalar (context course)

I want to get the mean(amount of submitted available(not hidden) assigns) in [each] course [in the] cohort CH

• outputs : courseid ⇒ scalar (context course)

I want know {the position in cohort} in [each] courses [of the] user (typical complex association)

means : I3 = I1 / I2 mapped by [0, 0.1, 0.4, 1] ⇒ [1,2,3] ( ⇒ ['red', 'yellow', 'green'])

• outputs : courseid ⇒ scalar (context course)

I want to know the (amount of late submissions) [per] user [in each] course [in] Category 1

outputs : courseid ⇒ userid ⇒ scalar (context user)

I want to know the mean(assign lateness delay) [in each] course [in] Category 1

outputs : courseid ⇒ scalar (ctx course)

I want to know the mean(assign lateness delay) [in] course X

outputs : scalar (ctx course, implicit)

I want to know the mean(assign lateness delay) [per] user [in] course X

outputs : userid ⇒ scalar mapped by ]5, 1, 0[ ⇒ (4,3,2,1,0) (ctx user)

I want to know the mean(assign lateness delay) [in] category C

outputs : scalar mapped by ]5, 1, 0[ ⇒ (4,3,2,1,0) (ctx coursecategory, implicit)

Revenir au sommaire général