Développement de Moodle

Saidi,

Je crains fort que tu ne trouve pas facilement ce que tu cherches. Ceci pour plusieurs raisons :

La modélisation formelle n'est pas une pratique extrêmement répandue dans la communauté open source "pragmatique" (contrairement à une certaine communauté open source théorique). Elle n'est pas non plus très répandue sur les projet PHP-based pour une bonne raison : PHP n'est devenu un vrai langage objet qu'à partir de la version 5.0, qui somme toute est récente.

Donc la pratique de modèles abstraits OO n'est pas une pratique trés développée en PHP.

Deuxième raison : Moodle, comme la plupart des application LAMP (ou WAMP -> AMP pour Apache+Mysql+Php) adoptent un modèle 3/3 (et non 4/3, avec persistance d'objets en mémoire) qui rend assez inutile le concept objet à la papa (C++, JAVA). En effet, pour que ce concept soit intéressant, il faut des masses d'objets en mémoire. L'utilisation de l'objet formel (définition de classes) dans Moodle est accessoire et anecdotique (par exemple, pour les tabs des menus). La notion Object Oriented dans Moodle ne VEUT PAS dire que la programmation de Moodle est orientée objet, mais qu'à un niveau de la gestion des ressources et de leur organisation, on peut penser "objet pédagogique".

Troisième raison, la maintenance d'un tel modèle est un coût assez important pour une communauté de développeurs très large et aussi dynamique que celle de Moodle (je rappelle, plus de 350 développeurs actifs et > 2500 développeurs occasionnels ou dormants). Même si l'équipe centrale de Martin fait un boulot gigantesque de synchronisation et de gestion des distributions internationales, maintenir un tel schéma me semblerait assez pantagruellique en énergies.

Quatrième raison : les équipes de développement PHP-based sont en général des experts des applications TIC et connaissent "à fond" leur modèle. Le recours à une modélisation pour élaguer une étude n'est pas toujours justifié par une nécessité pregnante.

Cinquième raison : la plupart des développements se faisant par des passionnés bénévoles, on va droit au but : satisfaire au plus vite et au plus juste les utilisateurs, à un coût horaire le plus raisonnable possible (nous avons tous de foules d'autres obligations).

Voilà pourquoi je pense que tu aura des soucis à trouver une description complète en UML, même si celle-ci pourrait être intéressante.

Ceci dit, le modèle de données est assez "classique" et parfaitement segmenté. Un modèle d'architecture des librairies pourrait par contre aider, ce qui doit être présent dans la doc anglaise.

Je mets évidemment un conditionnel à tout ça : il serait normal que ce modèle n'existe pas, mais si ils l'ont fait, alors double chapeau !!