---
# System prepended metadata

title: '[Projet NF18] - Réunion 1 (29/03)'

---

# [Projet NF18] - Réunion 1 (29/03)

## UML d'Anaïs
![]![](https://i.imgur.com/UkogJtM.png)



* Attributs `placemax`, `classe1`, `classe2`et `vitessemax` à mettre en méthode de la classe `TypeTrain` ? (le type conditionne ces attributs)
* Est-ce que la classe `calendrier`associée à la classe `Train` suffit-elle ? 
* Est-ce que les liens entre la classe d'association `Trajet` et la classe `Arrêt` sont suffisants pour traduire le fait que l'on peut programmer le même trajet périodiquement, sauf à certaines excpetions ?
* Le cours recommande de ne pas associer des classes d'association => comment traduire le lien entre un trajet et un billet ? Il faudrait qu'un trajet ne soit pas une classe d'association ?

## UML de Sacha
![](https://i.imgur.com/M6xw6Q9.jpg)
## UML de Lucas
![](https://i.imgur.com/f2WUwZx.png)

## Questions à poser
* Comment éviter de faire du Trajet une classe d'association, pour pouvoir l'associer sans problème avec la classe Billet ?
* Associations entre Train, Ligne et Gare : 
    * Séparer en 2 associations : une entre Train et Gare + une entre Gare et Ligne (cf Sacha)
    * OU une seule association entre Ligne et Gare, dans ce cas les trains sont reliés aux gares à travers les lignes => plus simple, mais respecte l'énoncé ou non ? (cf Anaïs)
    * Réponses : on peut supprimer la classe d'association et en faire une vraie classe. On utilise une association entre Train et Trajet + une association entre Ligne et Trajet.
* Sur Train : comment traduire l'héritage sur les types de trains ?
    * 3 propositions pour le type de train, laquelle ? 
    * Sinon, garder un attribut type dans la classe et passer par des méthodes ?
* Classe calendrier avec héritage ?

## Séance 6/04
### A rendre pour la semaine prochaine
* UML
* Note de clarification : appropriation/réécriture du sujet.
* Notation des rendus /3. 
    * 3 : tout est bon ou quelques petites erreurs 
    * 2 : plusieurs erreurs
    * 1 : des erreurs importantes / rendu incomplet
    * 0 : aucun rendu

## Idées
* Transformer la classe Arrêt en 2 classes d'association : une entre Train et Gare, une entre Ligne et Gare. Entre Ligne et Gare : attribut rang seulement. Entre Train et Gare : attributs rang, horaire de départ et d'arrivée. Si les horaires sont NULL, le train ne s'arrête pas à la gare associée. Migrer nb_arrets de Ligne vers Train, laisser nb_traverse dans Ligne. S'assurer de la cohérence entre Train et Ligne (une association entre les 2 ?) pour savoir quels gares traverse un train, y compris celles où il ne s'arrête pas.
* place comme clé de Trajet (Trajet composé par Train donc on ne peut pas avoir 2 personnes à la même place dans le même train ?)
* prix comme méthode de Billet au lieu d'attribut ? (donné directement d'après l'énoncé donc vaut mieux laisser en méthode :smile: )
* Dans ExceptionnelC : pourquoi avoir laissé un booléen except ?
* Passer le moyen de paiement d'un billet en attribut de la classe d'association entre Billet et Voyageur, sinon on doit enregistrer 2 fois le même voyageur qui paie avec 2 moyens de paiement différents.
* Clé de la relation Voyageur ? (nom,prénom,tél) ? Inclure le numéro de carte dans la clé dans le cas d'un voyageur régulier ?
* Sur ExceptionnelC : jour_debut <= jour_fin, si le calendrier ne concerne qu'un jour

* Arité de Ligne--Arrêt : 1..* côté Ligne ? Question des correspondances (un arrêt peut se situer sur plusieurs lignes, sinon pas de correspondance possible)
* Arité de Train--Calendrier : un calendrier ne peut pas correspondre à plusieurs trains ?
* Truc embêtant : aucun lien entre la classe d'association Horaire et la classe Calendrier, donc on peut implémenter des horaires de départ et d'arrivée qui n'ont rien à voir avec les horaires du calendrier...

## Dernières remarques UML
* Voyageur : rajouter la clé artificielle.
* Remettre le numéro de carte comme clé dans voyageur régulier ?
* Association Arrêt-Trajet : supprimer les attributs arret_depart et arret_arrivee, transformer en 2 associations entre Arrêt et Trajet : une association départ, une association arrivée ?
* Mettre les contraintes en toutes lettres pour qu'elles soient plus explictes
* Supprimer l'attribut nb_arrets de Ligne : on peut retrouver le nombre d'arrêts traversés par un train en faisant un COUNT sur une table avec tous les arrêts auxquels s'arrête un train. Et le nombre d'arrêts d'une ligne n'a pas trop de sens, puisque 2 trains qui circulent sur la même ligne peuvent ne pas s'arrêter aux mêmes arrêts.
* Comment préciser que pour un trajet dans un train, 2 personnes ne peuvent pas être assises à la même place ?
* Utilité de l'attribut Ajout dans ExceptionnelC ? On ajoute un calendrier qui correspond à un certain jour, on ne va pas créer une instance d'ExceptionnelC pour dire qu'on supprime un train à un certain horaire un certain jour.
* Youcef a dit qu'il valait mieux faire des classes à part pour les hôtels, taxis, transports.
* (Laurine) Il manque des noms d'associations entre horaire et arrêt et horaire et train
* (Laurine) Train-horaire-arrêt ->transformation de la classe association : pourquoi un horaire peut avoir plusieurs arrêt ? Dans ce cas un train est lié à un horaire qui a plusieurs arrêt non désservi par ce même train ? Dans ce cas on doit enlever la note arret.code=train.code + bool arrêt sera problématique est lié à plusieurs train, certains qui passent, d'autres qui s'arrêtent à cet arrêt
* On pourrait relier un horaire à un unique train et à un unique arrêt (comme c'était le cas avec la classe association) et dire que le train s'arrête à cet arrêt si depart<>arrivéee
* Je sais qu'en vrai un horaire peut être lié à plusieurs train et arrêt mais je trouve que ça pose problème dans notre modélisation
* Comme ça on pourrait faire la contrainte arret.code=train.code facilement ce qui n'est pas le cas ici car un horaire à plusieurs arrêt et plusieurs train