le readme du rendu
UML final
UML simplifié
- Lecture et compréhension du projet
- Debut d'un diagramme UML
- Mise en place du Git
- Avancement sur l'UML
- Mise en place d'un pattern decorateur pour les vélos
- Mise en place d'un pattern visitor entre les travaileurs et les vélos
- première étape : Vélos/Vehicules, états des Véhicules et réparateurs
- Les états des véhicules: les vehicules peuvent avoir plusieurs "casse" simultanéments, empêchant le pattern state
- Les emplacement de stoquage de vehicules: comme certains vélos peuvent être élécrtiques, on doit pouvoir les recharger. Princice qui s'appliquerai d'une manière similaire aux travailleurs
- Appliquer un pattern composite sur les états des véhicules
- Les travailleurs et les emplacement de véhicules implémentes la même interface
- début de documentation pour les classes de véhicules et de vélos
- Le passage entre travailleurs et emplacement de véhicules devrait se faire avec un pattern adaptater
- Le pattern composite sur les états de véhicules n'est pas assez clair
- Ecriture d'une version simplifier des états du vélo, avec un simple pattern state
- Conservation temporaire de l'interface entre les travailleurs et les emplacements de véhicules
- Faire une documentation et un squelette simplifié des véhicules, travailleurs et états de véhicules
- Commencer des classes de tests
- Si possible faire une implémentation de ces classes simplifiés
- Appliquer le pattern adapter entre les travailleurs et les emplacements
- Réfléchir plus profondément au états du véhicules ou réfléchir à la modélisation des stations et du centre de controle
- semaine de DS : aucune avancée
- création et documentation de chacunes de classes
- création des classes de testes
- implémentation des classes
- la classes ElectricalBike, devrait dans ce cas heriter de deux classes de testes
- solution prise: elle herite de la classe de teste de BikeFrame, et recode les testes de ElectricalVehicle
- ils sont fortements dépendants de la methode isUsable
- solution prise: création de classes intermediaire VehicleUsableState et VehicleUnusableState
- actuellement un vehicule ne peut pas avoir plusieurs états simultanéments.
- Due aux methodes updateDurability et updateBattery, qui sont lancées à chaque utilisation de setDurability et setBattery, l'états peut se mettre à jour en fonction de certaines caractéristiques du vélo. Ce qui permet d'atteindre la solution suivante: A toute création d'états on lance toute les methodes updates, qui permettent de verifier que l'état crée est défini bien celui du vehicule.
- Cependant le problème de cette solution, est que nous ne connaissons que un seuls des problème que le vehicule possède, et de plus un état inutilisable ne doit pas faire d'update vers un autre état inutilisable. Sinon la modélisation du constructeurs des états pourrais crée une boucle infinie.
- les emplacements s'adapte par eux même vers la classe worker, qui est un comportement qui me semble étrange.
- modélisations du reste du projet
- appliquer le pattern composite aux états des vehicules
- modélisation des stations
- modélisation du centre de control
- ajout d'un observer sur les état des véhicules et sur les stations
- suppresion de l'adapteur entre les emplacements et les acteurs, car celui-ci ne pouvait pas suivre le pattern adapter du au pattern visitor entre les emplacements et les véhicules
- mise en place d'une classe commune entre les worker et les emplacements
- UML avant modification
- UML après modification
- Aucun commentaire particulier
- un code couleur est mis sur l'uml pour permettre une meilleur organisation, celui ci est expliquer au dessus de la classe ControlCenter
- UML du code actuel
- test et implémentation des modifications sur les états des vehicules
- test et implémentation de la classes des stations
- début de test pour la classe du centre de control
- fin des test de control center et des methodes de réallocation
- implémentions ce ces classes
Cette classe permet d'appliquer tout les effets exterieurs sur le centre de contrôle.
- Comme par exemple le vol des vélos.
- Elle permet aussi de faire découler le temps.
- Et de plus elle renvoie une trace des information importante, à l'aide d'un displayer que l'on lui procure à sa création.
Création d'un main simple, permettant d'obtenir des information clés sur le projet
- Ajout d'un identifiant autogénéré pour les vehicules pour permettre une de les différentiés simplement
- Modification des notifications aux observeurs d'états de vehicules, pour que la notification se fasse au bon moment
- Implémentation d'une methode equals dans les vehicules pour qu'un vehicule soit égal à une décoration de lui même
ajouter certaines fonctionnalités :
- essayer de mettre en place le pattern composite sur les états
- ajouter une autre methode de réallocation
- ajouter un centre de control avec des workers limités, pour avoir un résultat plus réaliste
- les vehicules peuvent maintenants avoir plusieurs problèmes simultanéments
- petites améliorations du programme
- ecriture du readme de rendu
- ecriture d'un uml simplifié