Phase 3 : Intégration et affichage de la base de données

Nous avons extrait pour vous les données des vols. Les données sont déjà présentes dans une base de données SQLite (la même que celle utilisée dans le TP!). Cette base de données comporte les tables suivantes :

airline

CREATE TABLE airline(iata_airline TEXT PRIMARY KEY, name TEXT);

Cette table stock les données concernant les compagnies aériennes. Elle est constitué de deux colonnes. iata_airline L'identificateur unique de la compagnie et name le nom de la compagnie.

airport

CREATE TABLE airport(iata_code TEXT PRIMARY KEY,
                      name TEXT,
                      latitude_deg REAL,
                      longitude_deg REAL,
                      iso_country TEXT
                      FOREIGN KEY (iso_country) REFERENCES country(iso_country),
                     );

La table airport reprend les données relatives aux aéroports. iata_code est un identificateur unique pour l'aéroport. name est le nom de l'aéroport. latitude_deg et longitude_deg désigne les coordonnées de l'aéroport. iso_country est une clef étrangère se rapportant à la table country.

country

CREATE TABLE country(iso_country TEXT PRIMARY KEY, name TEXT);

La table country stock les différents pays. Elle comprend deux colonnes, iso_country l'identificateur unique du pays et name le nom du pays.

aircraft

CREATE TABLE aircraft(iata_aircraft TEXT PRIMARY KEY, name TEXT, aircraft_type TEXT);

La table aircraft comprends les appareils. Elle est constituée de trois colonnes, iata_aircraft l'identificateur de l'appareil, name le nom de l'appareil et aircraft_type le type de l'appareil.

flight

CREATE TABLE flight(flight_id INTEGER PRIMARY KEY,
                    iata_airline TEXT,
                    iata_aircraft TEXT,
                    iata_flight TEXT,
                    flight_date TEXT,
                    iata_departure TEXT,
                    iata_arrival TEXT,
                    departure_time TEXT,
                    departure_delay INTEGER DEFAULT(0),
                    arrival_time TEXT,
                    arrival_delay INTEGER DEFAULT(0),
                    UNIQUE(flight_date, iata_departure, iata_arrival, departure_time, arrival_time),
                    FOREIGN KEY (iata_airline) REFERENCES airline(iata_airline),
                    FOREIGN KEY (iata_aircraft) REFERENCES aircraft(iata_aircraft),
                    FOREIGN KEY (iata_departure) REFERENCES airport(iata_code),
                    FOREIGN KEY (iata_arrival) REFERENCES airport(iata_code)
                    );

Cette dernière table est la plus conséquente, elle regroupe les informations concernant les vols et possède plusieurs clefs étrangères.

  • fight_id est l'identificateur unique pour le vol

  • iata_aircraft est l'identificateur unique pour l'appareil

  • iata_flight est un identificateur pour le vol, mais celui-ci n'est pas unique

  • flight_date la date du vol

  • iata_departure l'aéroport de départ

  • iata_arrival l'aéroport d'arrivée

  • departure_time l'heure de décollage.

  • departure_delay le retard au décollage

  • arrival_time l'heure d'arrivée

  • arrival_delay le retard à l'atterrissage

L'objectif de cette phase est d'implémenter quelques fonctionnalités basées sur le SQL dans votre site. Il faudra, comme en TP, intégrer la base de donnée à votre site mais cette fois dans votre "vrai" projet.

Rappels:

  • Chaque groupe DOIT réaliser son travail en utilisant la Forge UCLouvain et en particulier le répertoire qui vous a été assigné par votre tuteur et le gestionnaire de version Git.

  • Votre site ne doit jamais être "down". Cela signifie que le code se trouvant sur la branche main doit toujours être fonctionnel.

  • Toute modification du code (excepté les corrections triviales) doit se faire à travers une merge request, qui a été reviewée par un membre du groupe.

  • Pensez à organiser votre GitLab proprement et utilisez des messages de commit clairs (effectuez des commits régulièrement).

Taches

Nous vous demandons d'intégrer le schéma dans votre site Flask.

Commencez par remplacer tous les modèles "statiques" (avec des listes pythons) par des requêtes SQL.

Vous devrez créer un menu, qui permettra d'accéder aux pages de votre site.

Il comportera au moins les pages suivantes :

  • Une page d'accueil. Pas de changement

  • Une seule page qui présente l'équipe. Pas de changement

  • La page "Calculateur" sur le site qui, comme dans la phase 2 permet de:

    • calculer la distance entre deux coordonnées GPS Pas de changement

    • de sélectionner deux aéroports dans des listes déroulantes et d'en afficher la distance. Cependant les modèles statiques seront remplacés par des requêtes SQL, la liste des aéroports vient donc de la base de données.

  • La page "Emissions" qui permettra comme dans la phase 2 de:

    • calculer les émissions de CO2 d'un vol pour lequel on donne sa distance et le type d'avion Pas de changement

    • de sélectionner deux aéroports et un modèle d'avion, et d'en afficher les émissions de CO2. Ici aussi, les listes déroulantes seront alimentées par des requêtes SQL. La distance entre les deux aéroports sera calculée à l'aide de leurs coordonnées GPS, qui sont disponibles dans la base de données.

    • de comparer les émissions de ce vol avec d'autres émissions connues (par exemple, la quantité de CO2 émise par une voiture pour faire 100km, ou par un humain en respirant pendant une journée, les émissions de la Wallonie en un jour, ...). La comparaison apparaîtra comme un tableau trié, avec le vol classé entre la catégorie supérieure et inférieure. Pas de changement

  • Une page qui présente des statistiques. En utilisant des requêtes SQL pour effectuer les opérations mathématiques telles que des sommes ou des comptages :

    • Le nombre d'entrées par table, selon le schéma fourni ci-dessus.

    • Le nombre de vols par aéroports de destination.

    • Le nombre de vols par compagnie aérienne.

  • Une page de requête qui permet de choisir un aéroport dans un menu déroulant.

    • Après sélection la page affiche le nombre de vols par type d'appareil.

    • Pour l'aéroport choisi, affiche le nombre de vols par jours de la semaine (lundi, mardi, ...).

L'affichage des deux dernières pages utilisera toujours le nom textuel complet et pas les codes ISO ou IATA. Par exemple il faut afficher "Belgium" et pas "BE". Liège Airport et pas LGG. En utilisant évidemment les jointures appropriées.

Vous avez environ deux semaines pour terminer cette phase après la phase précédente. La deadline précise est donnée sur Moodle. Le site doit être en ligne et fonctionnel avec la dernière version du code. Vous devez également faire un tag git, qui va marquer le dernier commit comme celui du code final. Pour cela, utilisez git tag phase3 && git push phase3. Vérifiez que ce tag est disponible sur l'interface de la Forge.

Il n'y a pas de rapport dans cette phase qui compte pour 10 points.

Critères d'évaluation

Site :

  • Le site fonctionne et est en ligne

  • Le design est réfléchi, le site est navigable, élégant, épuré

  • Le site est résistant à l'utilisateur : il n'y a pas de crash, d'injections SQL, ... Présenter un site avec une faille de sécurité mènera à un malus conséquent.

Documentation du code :

  • Le code est commenté

SQL :

  • Les requêtes SQL sont correctes.

  • Les requêtes SQL sont élégantes, directes et efficaces. Elles ne retournent pas de données qui ne seront pas utilisées par le contrôleur.

Testing:

  • Toutes les nouvelles fonctionnalités sont testées dans plusieurs cas

  • Le coverage est suffisant

  • Le site présente des tests d'intégration sur les routes

Git :

  • L'ensemble des modifications importantes ont été faites en utilisant des merge requests.

  • Les merge requests ont fait l'objet de reviews systématiques.

  • Le git ne contient pas de fichiers binaires, le VENV ou autres fichiers inutiles.

Code :

  • Le code est correct.

  • Le code est structuré.

  • L'architecture MVC est respectée.

  • Les templates HTML sont propres. Les données paramétrables sont passées par l'application, et pas codées en dure.

Il n'y a pas lieu d'évaluer le travail de groupe. Il n'y aura pas de dynamo. Le suivi sera fait par les tuteurs et assistants, ainsi que par les merge requests. En cas de problème, n'hésitez pas à contacter votre tuteur ou les assistants. A la suite de la phase 2, certains groupes seront remaniés ce qui pourrait ralentir le début de la phase 3. Nous vous demandons de ne pas attendre la fin de la phase 2 pour commencer à travailler sur la phase 3, même si vous n'avez pas encore tous les membres du groupe.

Pour rappel, la phase 3 dans son ensemble compte pour 10% de la note finale. Les deadlines sont données sur Moodle.