Choix techniques

• L'application est développée en langage Haxe compilé (transpilé) en Javascript. Elle ne requiert qu'un navigateur web pour fonctionner.
• Le moteur de gabarits haxe.Template de la bibliothèque standard est utilisé.
• La feuille de styles utilisée est W3.CSS.

Fichiers

• Le point d'entrée du programme est le fichier app/index.html et les fonctions de rappel sont définies dans le fichier src/Index.hx. Les gabarits pour la présentation sont dans le dossier tpl.
• Le fichier src/Promotion.hx contient la logique métier et les fichiers src/Eleve.hx, src/Groupe.hx et src/Specialite.hx les structures de données.
• Le fichier src/Export.hx contient le générateur permettant l'enregistrement du résultat.
• Les fichiers doc/README.md et doc/Usage.md contiennent la documentation utilisateur ; ce fichier (doc/Dev.md) contient la documentation développeur.
• Le fichier build.hxml contient les directives de compilation pour générer le fichier app/index.js.
• Le fichier Makefile, adapté à un environnement de développement Linux, permet notamment d'automatiser le déploiement de l'application.
• Le programme tests/Faker.hx permet de générer des données de test : haxe -cp tests -main Faker --interp > tests/exemple-voeux1.csv

Portabilité

Concernant la portabilité : seul le code source du fichier src/Index.hx est spécifique à la cible d'éxécution Javascript / client web ; la logique métier et les structures de données peuvent être compilées (transpilées) en C++, C#, Java, PHP, Python, ... Le moteur de gabarits est lui aussi indépendant de la plateforme cible.

Débogage

Activer l'option -debug dans le fichier build.hxml pour générer le fichier app/index.js.map permettant au navigateur de faire le lien entre le code Javascript généré et le code Haxe sous-jacent.

Données

Fonctionnement

Les priorités des l'algorithme sont la satisfaction des voeux, puis l'équilibrage de la taille des groupes. Il ne cherche pas à regrouper les élèves ayant choisi les mêmes combinaisons de spécialités (au contraire) ; par conséquent, il contribue :

• à la disparition de notion de filière (scientifique, littéraire, économique - un des objectifs de la réforme) par le mélange d'élèves ayant choisi des combinaisons différentes ;
• et à la constitution de groupes hétérogènes, plus favorables à la réussite que les groupes homogènes (cf Duru-Bellat et Mingat, 1997 ; Suchaut, 2007).

Priorité des spécialités

Par défaut, la priorité initiale dépend du rang de la spécialité dans le fichier des paramètres, la première ayant la priorité la plus forte. Cette fonctionnalité permet des optimisations manuelles.

Lors du tri des spécialités, la priorité est recalculée et dépend du nombre de groupes et de places libres :

priorité <- arrondi (1000 / (nbGroupes x 10 + moyenne_des_places_disponibles_par_groupe))

Exemples :

• pour 150 élèves demandant la spécialité "Maths", il faut 5 groupes, ce qui donne une capacité de 175 élèves (donc 25 places libres) ; la priorité sera : 1000 / (5 x 10 + 25 / 5), soit 18.
• pour 29 élèves demandant la spécialité "Théatre", pour lesquels l'établissement souhaite limiter le nombre de groupes à 1 avec 24 élèves ; la priorité est : 1000 / (1 x 10 + -5 / 1), soit 200.

Ainsi la priorité d'une spécialité cherche à traduire la pression de la demande ; l'exemple montre qu'il est plus difficile de placer un élève ayant demandé la spécialité théatre qu'un autre ayant demandé la spécialité mathématiques.

Priorité des élèves

Par défaut, la priorité initiale dépend du rang de l'élève dans le fichier des vœux (les élèves étant affectés dans l'ordre de leur apparition). Cette fonctionalité permet des optimisations manuelles.

En cas de tri des élèves, la priorité est calculée en fonction de la priorité des spécialités choisies. Exemple, pour un élève de terminale demandant théatre et mathématiques, sa priorité sera de 218 (cf priorités calculées précédemment).

Affectation

Les élèves sont affectés un a un. Pour chacun d'eux, plusieurs tentatives sont faites (6 en première, 2 en terminale) ; exemple, pour la première

• la première tentative essaiera de placer le vœu 1 dans le premier alignement, le vœu 2 dans le deuxième et le vœu 3 dans le troisième (cf [0 1 2]) ;
• la deuxième tentative ([ 0, 2, 1 ]) essaie de placer le vœu 1 dans le premier alignement, le vœu 2 dans le troisième et le vœu 3 dans le second ...
• ...

L'algorithme compare les solutions et retient celle qui laisse le maximum de places libres pour les autres élèves ; par exemple, avec les alignements et groupes suivants :

Alignement 1 :

• SVT : SVT-1 (reste 10 places), SVT-2 (reste 11 places)
• SES : SES-1 (reste 16 places)
• LLCE : LLCE-1 (reste 16 places)

Alignement 2 :

• Maths : Maths-1 (reste 20 places)
• SVT : SVT-3 (reste 16 places)
• LLCE : LLCE-2 (reste 16 places)

Alignement 3 :

• SES : SES-2 (reste 21 places), SES-3 (reste 21 places)
• SVT : SVT-4 (reste 16 places)
• HLP : HLP-1 (reste 15 places)

Pour un élève qui souhaite faire SVT, LLCE et SES ; les solutions sont :

• SVT-2 (reste 10), LLCE-2 (reste 15), SES-2 (reste 20), soit 45 places restantes
• SVT-3 (reste 15), LLCE-1 (reste 15), SES-2 (reste 20), soit 50 places restantes
• SVT-4 (reste 15), LLCE-2 (reste 15), SES-1 (reste 15), soit 45 places restantes

L'élève sera affecté en SVT-3, LLCE-1 et SES-2 (solution 2), et ce pour deux raisons :

• le plus petit nombre de places restantes est 15 (identique à celui la troisième solution), et aucune autre solution n'a de valeur plus élevée ;
• cette combinaison est celle qui laisse le plus grand nombre de places restantes.

Essais multiples

L'algorithme fait plusieurs essais avec des priorités différentes et retient la solution qui apporte le plus de satisfaction :

• essai d'affectation des élèves dans l'ordre des données fournies ;
• tri des élèves en fonction de l'ordre des spécialités saisies en paramètre ;
• et enfin, tri des spécialités puis tri des élèves.

Construction

Téléchargement ou clonage du dépôt :

git clone git://git.tuxfamily.org/gitroot/respe/respe.git

Compilation :

haxe build.hxml