namhto / projet-3a Goto Github PK

Wow c'est une meta issue 👍

Voila ce que je conseil d'utiliser pour faire le serveur prolog : http://www.swi-prolog.org/howto/http/

Il y a la de quoi monter un webservice accessible par http qui permet d'attaquer une base prolog

Ci joint (si ca a marché, premier essai avec GitHub deux fichiers :
webserver.txt : montre comment j'ai monté mon webservice prolog
3 regles :
server(Port) permet de lancer le serveur sur un port donné et de paramètrer son timeout
welcome(_) un petit hello world qui explique comment utiliser le serveur
verify(Request) qui lit la requête en prenant en compte le formatage et sort Data qui est utilisé en paramètre de la règle checkGraph qui me permet de vérifier mes graphes et est implémentée en prolog

MobileMeasure_ModelChecker.txt : le fichier qui défini ce qu'est checkGraph et propose cette règle en module.

MobileMeasure_ModelChecker.txt
webserver.txt

Une école contient plusieurs promotions qui peuvent être séparées en groupes de TD et de TP

Pas de commit ce jeudi et vendredi pour cause de nuit de l'info.
J'essaye de rattraper ça ce weekend.

Un cours peut etre composé de tp de td et de cours magistral

Les différentes règles du projet doivent être commentées.

Vous pouvez trouver un template de commentaire pour les règles dans le projet example.

pour les paramètres, les + indiques que sans ce paramètre la clause n'est pas sensé fonctionner et les - que c'est cette variable qui obtiendra le résultat.
on peut également utiliser des ? pour signaler que le paramètre peut être ou ne pas être renseigné, comme par example pour la clause append/3 de la documentation prolog.

%%%%%----------Clause----------%%%%%
%%% safeConvert(+From,+To,-Ratio).
%%% (unitRep,int,unitRep)

% converts the unit From into the unit To asserting that they are of the same dimension

% From : a unit
% To : a unit
% Ratio : a value

%%% Example
%%% safeConvert(prefixedUnit(kilo,metre), metre, Result)
%%%%%----------%%%%%----------%%%%%

Un calendrier scolaires contient des mois, des semaines, des jours, des créneaux.

Bonjour,

Je vois qu'un merge hasardeux et un commit ont été réalisés sur le git. Cependant :

• les commits ne sont pas assez explicites. Que veux dire 'promo' il faut décrire ce que le commit ajoutes dans le projet
• Ou sont les nouveautés? Tout ce que je vois c'est encore le meme fichier que celui que vous m'avez montré la semaine dernière. Je vous rappelle que vous avez quatre objectifs pour la semaine prochaine (1-optionel pour le moment) rendre le code propre (séparer les différentes entités dans des fichiers différents pour mieux les maintenir / Commenter le code (le projet est encore petit donc je peux suivre, mais il faut que les différentes règles soient commentée pour permettre une lecture facile du code) (2) implémenter les contraintes de bases du calendrier => pas de profs/etudiants/salle multipliée pour un créneau, + prof x ne veux pas avoir cours à tel heure (3) la hiérarchisation des éléments : un cours (ou une formation ) peux contenir des heures de cours, de tp de td idem pour la promo (3) la création de la notion de Jours, semaines...

je vais créer des "issues" git pour garder une trace des éléments à réaliser. Lorsque c'est fait, il faut le commit / merge sur la branche master avec un titre compréhensible ET clore l'issue en commentant que ca a été réaliser dans tel fichier avec tel règle.

Navré d'en arriver la, mais je prends la direction du projet puisque vous n'avez pas suivit les règles cette semaine non plus (une fois de plus je ne sais pas ce que vous faites de votre coté. Peut être que vous avez déjà terminé le projet sur vos pc. Le git est ma seule source d'information puisque je n'ai pas eu de mail.)

Le temps est assassin et les deadlines approchent très vite!

Bon courage

(cf le descriptif des fonctionnalisées de scheduleDay(P,X))

Le code du projet doit être séparé en plusieurs fichiers sinon il deviendra ingérable

A pars les annotations de merge et le test qui avait montré les problèmes de la méthode avec assert

A partir de maintenant, tester le code devient vraiment important.

La gestion des listes et la récursivité en folie qui vont arriver demandent de pouvoir facilement tester et surtout RE-tester les fonctionnalisées en place.

Tout à l'heure on a fait la fonction schedule qui créé plusieurs créneaux et vérifie que les contraintes de non multiplicité des profs et salles sont respectées.
Plutôt que de garder le nom schedule, qui n'aura plus de sens une fois schedule day en place, changez ce nom en test_A et en mettant une description précise des contraintes et fonctionnalisées testées en commentaire.

Un jour vous vous amuserez peut etre meme à faite test_X :- test_A(S), test_B(S), test_C(S) si B et C ne contiennent par exemple que une vérification d'un ensemble de contraintes.

Bref, en testant vous assurez 1 la compréhension des règles impliquées leurs utilisation (pour un néophyte du projet) et leurs fonctionnements (pour vous)

Un prof est en droit de demander à ne pas travailler à une certaine heure OU de travailler que à certaines heures

Pour le moment cette contrainte est absolue, un jour elle sera optionnelle.

Attention, un merge vers la branche master à été complètement raté, ce qui a donné un fichier avec des notes Git dedans signalant les conflits non gérés (promo.pl)

• [A] Faire une contrainte qui vérifie que si un groupe de TP a cours, alors aucune autre des parties de sa hiérarchie PBDP (Promo/Branche/TD/TP cette acronyme pourrait aller assez bien à la place du "groupTP" actuel a vous de voir :D ) n'a cours en meme temps. Cette contrainte est montante

• [B] Faire de meme pour les Promo. Cette contrainte est descendante

• [C] Faire de meme pour les branche et TD. Cette contrainte est montante descendante

Hint : faire une isAssociated(X,Y) qui vérifiera s'il y a un chemin unidirectionnel (montant ou descendant mais pas de monté puis descente) entre X et Y X et Y étant un élément de PBDP
En français ca veut dire vérifier :

• est ce que X = Y?
• est ce que X et y apparaissent dans la meme hiérarchie de PBDP

deux méthodes pour ca :

• la mauvaise : faire une regle pour chaque combinaison possible du genre isAssociated(Promo,Branch) :- PBDP(Promo,Branch,,). isAssociated(P,D) :- PBDP(P,,D,). etc
• la bonne : faire une règle belongTo(X,Y) qui dit qu'un TP appartient à un TD, qu'un TD appartient à une Branche et une branche à une promo. Puis augmenter belongTo en récursif (un TP appartient à une Branche si un TD appartient à la branche et le TP au TD) Pour faire ca voir les exercices très simples d'arbre généalogique . Et ensuite isAssociated(X,Y) sera unifié si belongTo(X,Y) ou alors belongTo(Y,X).

Pour un créneau donné il ne faut pas que le prof / les étudiants / la salle ne soient dans plusieurs cours en même temps.

Cette contrainte induit implicitement que le même cours ne peut pas avoir lieux plusieurs fois en même temps puisque le prof et les étudiants qui y participent ne peuvent l'être.

Cette question est en suspens pour le moment.