Differences

This shows you the differences between two versions of the page.

--- 2014_2015:s3:concprogobjet:td:corrections:td3 [2014/09/05 18:05] – [Responsabilités] blay
+++ 2014_2015:s3:concprogobjet:td:corrections:td3 [2014/10/05 08:30] (current) – [Responsabilités et Couplages] blay
@@ Line 8: / Line 8: @@
-  * Il manque bcp de choses dans les IHMs en particulier l'interface de saisie des messages.
+<note warning>A ne pas diffuser ce n'est pas vraiment une bonne solution.
-On peut leur donner en TD pour les aider.
+C'est encore une fois un peu moins simple que souhaité comme exercice.
+</note>
+  * Il manque bcp de choses dans les IHMs en particulier l'interface de saisie des messages. On peut leur donner en TD pour les aider.
    * Pas malin de faire plusieurs fenêtres
-   *
+   * Cette version met l'accent sur un "registre de bus"... pas du tout optimal dans son implémentation.
+**Diagrammes**
-  * Quels modèles utilisés vous pour circonscrire le problème ?
+Pour ma part j'ai eu besoin de use cases, séquences et classes.
+Attention les images des Diagrammes ont été faites alors que le modèle n'était pas consolidé dans le diagramme de classes, je n'ai pas le courage pour l'instant de tout reprendre. En particulier il manque des multiplicités qui refusent de s'afficher...
-Pour ma part j'ai eu besoin de use cases, séquences et classes
+Pour la 1ere heure je n'ai pas du tout inclus les IHM ni les contrôleurs. J'ai juste cherché à ce qu'ils positionnent les méthodes dans les bonnes classes, en particulier, je ne veux pas :
+  - Que les relations entre les classes soient représentées comme des attributs, c'est des associations et il faut insister sur la navigation et les rôles. La question du choix de la structure pour gérer des listes ils peuvent se la poser mais je ne veux pas voir dans les diagrammes messages : ArrayList par exemple.
+  -
 {{ :2014_2015:s3:concprogobjet:td:corrections:uccreerbusv2.png?direct&300 |}}
@@ Line 23: / Line 29: @@
 {{ :2014_2015:s3:concprogobjet:td:corrections:sequenceselectboite.png?direct&300 |}}
+Pour lire les messages
 {{ :2014_2015:s3:concprogobjet:td:corrections:liremessages2.png?direct&300 |}}
+Pour créer un message
+{{ :2014_2015:s3:concprogobjet:td:corrections:creerunmessagev2.png?direct&300 |}}
+Diagramme de classes ....
+{{ :2014_2015:s3:concprogobjet:td:corrections:busconceptionv2.png?direct&300 |}}
-===== Responsabilités et Couplages =====
-Je n'ai pas encore fait les codes juste les modèles
+VOICI LES CODES, ATTENTION ILS NE SONT PAS VRAIMENT EN ADEQUATION AVEC LE MODELE..
-{{ :2014_2015:s3:concprogobjet:td:corrections:consommationparvoiture.png?direct&200 |}}
+{{:2014_2015:s3:concprogobjet:td:corrections:codesbusv2.zip|Code du Bus}}
+{{{{:2014_2015:s3:concprogobjet:td:corrections:codestestbusv2.zip|}}|Code du test Bus}}
+  * Responsabilités
+      * creer un bus : Le registre de bus : j'ai besoin de pouvoir retrouver un bus à partir de son nom par la suite, donc je préfère tout lui déléger. J'utilise une HashMap.
+      * creer une boite : c'est le bus parce que je vais vouloir retrouver la boite à partir du bus..
+      * creer un message : c'est la boite pour l'instant mais vu l'interface cela part du registre -> bus -> boite.... Pas optimal en terme de parcours mais facilite le couplage faible sauf que....
+      * La lecture des messages ... en remontant les messages au regsitre, celui ci les connait... Je ne vois pas comment faire autrement si ce n'est en ne donnant pas cette fonctionnalité au registre... C'est le controleur au niveau au dessus qui du coup aurait tout le travail..
+      * MAIS dans mes diagrammes j'use bcp de la délégation en essayant de faire que le controleur ne connaisse pas tout.. Les hésitations se voient il faudrait que je choisisse plus clairement un modèle!
+      *