Outils pour utilisateurs
start
Différences
Ci-dessous, les différences entre deux révisions de la page.
| Les deux révisions précédentes Révision précédente Prochaine révision | Révision précédente | ||
|
start [2019/08/01 17:44] admin [Les défis et difficultés] |
start [2020/04/07 11:07] (Version actuelle) |
||
|---|---|---|---|
| Ligne 3: | Ligne 3: | ||
| ===== BoardZ ===== | ===== BoardZ ===== | ||
| ===== Une infrastructure de statistiques haute performance pour Moodle ===== | ===== Une infrastructure de statistiques haute performance pour Moodle ===== | ||
| + | |||
| ==== Présentation ==== | ==== Présentation ==== | ||
| Ligne 18: | Ligne 19: | ||
| * Assurer une construction adoptant des normes industrielles et des standards d'architecture propre à la nécessité du projet, dans une vision de construction à long terme. | * Assurer une construction adoptant des normes industrielles et des standards d'architecture propre à la nécessité du projet, dans une vision de construction à long terme. | ||
| * forger un modèle de soutien budgétaire à long terme, indépendamment des décisions ou changments d'environnement locaux. | * forger un modèle de soutien budgétaire à long terme, indépendamment des décisions ou changments d'environnement locaux. | ||
| + | |||
| + | ===Quel volume de travail représente cette conception ? === | ||
| + | |||
| + | * Boardz : 30983 commits de code depuis le début. Si on compte environ une moyenne de 1mn par commit qui doit équilibrer ceux qui demandent beaucoup de temps d'analyse et ceux qui sont fait à grande vitesse lors de séquences de debug, cela donne environ 65 jours "pleins". | ||
| + | * La partie Moodle : 80 jours | ||
| + | * L'installation sur les VM Avignon : 1 jour | ||
| + | * La documentation : 5 jours. | ||
| + | * Les réunions et les reporting mails et échanges visio : 4 jours | ||
| + | |||
| + | |||
| + | Soit au 24/02/2020 : 154 jours de travail | ||
| === L'approche === | === L'approche === | ||
| Ligne 105: | Ligne 117: | ||
| Les techniques qui permettent l'évolutivité et l'extensibilité des projets logiciels sont connues et répertoriées. On trouvera (non exhaustif) : | Les techniques qui permettent l'évolutivité et l'extensibilité des projets logiciels sont connues et répertoriées. On trouvera (non exhaustif) : | ||
| - | * L'architecture par plugins : En créant des points particuliers où des paquets de code peuvent être ajoutés au code initial et être reconnus et pris en charge comme des extensions. Cette méthode convient à la fois au projets de "script" ou aux projets structurés en programmation "Objet". | + | * **L'architecture par plugins :** En créant des points particuliers où des paquets de code peuvent être ajoutés au code initial et être reconnus et pris en charge comme des extensions. Cette méthode convient à la fois au projets de "script" ou aux projets structurés en programmation "Objet". |
| - | * L'extension de classes : Principalement adaptée aux projet fortement orientés "Objet", elles reposent sur des principe de "Fabrique" ou "Fabrique abstraite", permettant à un projet de remplacer l'usage standard d'une classe par une classe plus riche définie et ajoutée ultérieurement au projet. | + | * **L'extension de classes :** Principalement adaptée aux projet fortement orientés "Objet", elles reposent sur des principe de "Fabrique" ou "Fabrique abstraite", permettant à un projet de remplacer l'usage standard d'une classe par une classe plus riche définie et ajoutée ultérieurement au projet. |
| - | * L'abstraction et les méta-modèles de la persistance de données : Les méta-modèles et abstractions de modèles de données permettent de stocker dans relativement peu de définitions des constructions très différentes. Un modèle très abstrait réduit à un couple "entité - attribut" pourrait en théorie stocker les données n'importe quelle application, mais présente un problème important de performance, car l'accès à certaines données peut se révéler très indirect (et donc très long). L'abstraction doit donc être introduite de manière raisonnée pour permettre des stockages directs là où la performance est critique et des stockages plus "génériques" là où elle est moins indispensable. | + | * **L'abstraction et les méta-modèles de la persistance de données :** Les méta-modèles et abstractions de modèles de données permettent de stocker dans relativement peu de définitions des constructions très différentes. Un modèle très abstrait réduit à un couple "entité - attribut" pourrait en théorie stocker les données n'importe quelle application, mais présente un problème important de performance, car l'accès à certaines données peut se révéler très indirect (et donc très long). L'abstraction doit donc être introduite de manière raisonnée pour permettre des stockages directs là où la performance est critique et des stockages plus "génériques" là où elle est moins indispensable. |
| - | Quels sont les points clefs de l'extensibilité ? | + | **Quels sont les points clefs de l'extensibilité ?** |
| * L'auto-découverte ou auto-enregistrement : Il s'agit d'organiser comment l'applicatif peut intégrer des nouvelles portions de code par simple "ajout" de fichiers. L'applicatif doit être en mesure de soit : | * L'auto-découverte ou auto-enregistrement : Il s'agit d'organiser comment l'applicatif peut intégrer des nouvelles portions de code par simple "ajout" de fichiers. L'applicatif doit être en mesure de soit : | ||
| * directement utiliser le code ajouté et en proposer les principes dans ces interfaces | * directement utiliser le code ajouté et en proposer les principes dans ces interfaces | ||
| * soit, si l'usage du code repose sur des registres et descripteurs, être capable d'aller mettre à jour automatiquement ces registres lorsque le code a été ajouté. | * soit, si l'usage du code repose sur des registres et descripteurs, être capable d'aller mettre à jour automatiquement ces registres lorsque le code a été ajouté. | ||
| - | * La transparence des chaines de traitement : Il s'agit ici de faire en sorte que toutes les étapes et parties intermédiaires qui n'ont pas de rapport direct avec la fonctionnalité étendue soit le moins sensible possible au code de la fonctionnalité. Etendre l'application doit revenir, si l'architecture est bien construite, à ajouter juste les modifications qui concernent la fonctionnalité (les librairies, les réglages, les "templates", les ressources propres), sans qu'aucune structure du "coeur" ne soit concernée par ces modification. En général, le transport de bout en bout de structures de données texte (sérialisées json ou non, suivant les couches à traversées) est une pratique efficace. | + | * La transparence des chaines de traitement : Il s'agit ici de faire en sorte que toutes les étapes et parties intermédiaires qui n'ont pas de rapport direct avec la fonctionnalité étendue soit le moins sensible possible au code de la fonctionnalité. Étendre l'application doit revenir, si l'architecture est bien construite, à ajouter juste les modifications qui concernent la fonctionnalité (les librairies, les réglages, les "templates", les ressources propres), sans qu'aucune structure du "cœur" ne soit concernée par ces modification. En général, le transport de bout en bout de structures de données texte (sérialisées json ou non, suivant les couches à traversées) est une pratique efficace. |
| * Le découplage : Principe par lequel les transformations d'une partie n'impactent pas le tout mais seulement une fonction de transfert entre cette partie et le reste de l'applicatif. | * Le découplage : Principe par lequel les transformations d'une partie n'impactent pas le tout mais seulement une fonction de transfert entre cette partie et le reste de l'applicatif. | ||
| Ligne 121: | Ligne 133: | ||
| * [[:boardz:journal|Journal de bord]] : Le journal de bord des développements en cours. | * [[:boardz:journal|Journal de bord]] : Le journal de bord des développements en cours. | ||
| * [[:boardz:design|Documentation de conception]] : Les principes de construction. | * [[:boardz:design|Documentation de conception]] : Les principes de construction. | ||
| - | * [[:boardz:install|Documentation d'installation]] : L'installation du serveur et sa mise en oeuvre. | + | * [[:boardz:queries|Indicateurs, exemples d'analyse]] : L'analyse et la méthode de décomposition d'indicateurs. |
| - | * [[:boardz:administration|Documentation d'administration]] : L'administration du serveur. | + | * [[:boardz:install|Documentation d'installation]] : L'installation du serveur BoardZ et sa mise en oeuvre. |
| * [[:boardz:integration|Documentation d'intégration]] : L'intégration dans Moodle. | * [[:boardz:integration|Documentation d'intégration]] : L'intégration dans Moodle. | ||
| + | * [[:boardz:userguide|Documentation d'administration]] : L'administration du serveur. (guide d'usage) | ||
| + | * [[:boardz:serverapi|Documentation d'exploitation]] : Les tâches programmées et le fonctionnement continu du moteur. | ||
| + | * [[:boardz:performances|Performances]] : Mesures de performance. | ||
| * [[:boardz:serverapi|Documentation d'extension]] : Les APIs et l'extensibilité. | * [[:boardz:serverapi|Documentation d'extension]] : Les APIs et l'extensibilité. | ||
| + | * [[http://docs.boardz.activeprolearn.com/phpdocs/index.html|PhpDoc des classes]] | ||
| + | |||
| + | |||
| + | [[http://boardz.activeprolearn.com|backend boardz]] | ||
| + | [[https://ma36-qualif.formation-enligne.com|site moodle cible (ma qualif)]] | ||
start.1564674258.txt.gz · Dernière modification: 2020/04/07 11:07 (modification externe)
Outils de la page
