BoardZ Moodle Stat Project

Les fonctions de calcul de données statistiques à partir d'enregistrements de bases de données peuvent aujourd'hui être réalisés selon une grande quantité d'architectures techniques tant les langages et les briques logicielles ont évoluées et maturées.

On doit distinguer cependant encore 3 grandes familles d'implémentation :

• Les implémentations scriptées (non compilées) incluant Php, Python, Ruby, NodeJS (Javascript server), Perl, etc.
• Les implémentations compilées comme Java ou C#.
• Les implémentations compilées haute performance, comme le C ou le C++.

Le choix majeur d'une technologie de réalisation d'un projet dépend finalement d'une équation assez simple : Il repose essentiellement sur le rapport entre l'interface et l'interaction utilisateur d'une part, et le masse de calcul ou d'automatisation d'autre part. Les langages scriptés sont très habiles à produire de l'interface et des interactions utilisateur à moindre coût, flexible, agile, permettant des modifications à mise en oeuvre quasi immédiate, ou du moins simple, mais sont d'une performance calculatoire et algorithmique assez faible. En revanche les langages compilés et le mode de conception en serveur persistant rend assez coûteux le travail de l'interface, mais au contraire favorise la vitesse et la quantité de calcul.

Le fonctionnement de BoardZ suppose 3 principales tâches dans son fonctionnement continu :

• Recevoir les données
• Compiler les données sources et les transformer (dimensionnalisation, agrégation, distribution)
• Restituer les données aux demandeurs

Nous négligeons ici les tâches exceptionnelles de gestion du serveur et de maintenance de données.

Tout, dans la problématique de tenue à la volumétrie, va être lié à l'architecture des traitements et des modèles de données sur lesquels ils vont s'appuyer. 3 paramètres influent sur la volumétrie de traitement dans le serveur :

 1. **La volumétrie d'entrée**, de manière non triviale, car l'augmentation de la volumétrie d'entrée n'entraine pas forcément un accroissement équivalent de la quantité de traitement. Dans le cas de BoardZ, on pourra associer ce critère à la "taille du moodle" c'est à dire la somme du nombre de ses contextes multiplié par la densité d'usage de la plate-forme.
 2. **La fréquence du traitement** : Dans une application multiutilisateur, il est fréquent que plusieurs utilisateurs distincts demandent le même calcul. Plus ils sont nombreux et plus ils le demandent, plus ce calcul sera exécuté et réexécuté souvent. C'est ici tout l'intérêt des stratégies de "cache" qui essaient précisément de stocker des résultats précalculés pour s'économiser ce recalcul. Dans le cas de BoardZ, on peut fonctionnellement associer ce critère au nombre d'indicateurs demandés et la fréquence d'affichage de ces indicateurs.
 3. La **complexité du traitement** : avec les mêmes données sources, selon la formule de calcul qui est demandée, le parcours des données peut être multiple, voire même polynomial. Le travail sur la complexité des algorithmes permet de réduire cette complexité dans une mesure importante, mais aussi au prix de mises en oeuvres plus complexes à développer. Ramené à BoardZ, ce critère sera associé à la définition même des indicateurs, selon qu'il sont scalaires, vectoriels, comparatifs, temporels, etc et la mesure demandée sur ces indicateurs.

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