User Tools

Site Tools


2014_2015:s3:concprogobjet:td:td3

This is an old revision of the document!


TD3 : Soyons Pragmatique !

Objectifs : Travailler sur de petits exemples différents points d'un développement pragmatique.

Responsabilités

Le bus est maintenant composé de boîtes à messages.

  • Un agent peut créer un bus.
  • Un agent peut créer des boîtes à messages associées à un bus.
  • Des producteurs envoient des messages vers un bus et éventuellement vers une boîte de messages spécifique du bus.
  • Un consommateur peut demander à lire des messages qui se trouvent dans une boîte sur un bus
  • Un consommateur peut demander à lire tous les messages qui se trouvent sur le bus.
  • Une boîte ne peut pas être associée à plusieurs bus. Un bus peut évidemment avoir plusieurs boîtes.

Voici les interfaces graphiques telles que le maitre d'ouvrage les a imaginées. Vous pouvez proposer une autre approche de l'interface mais l'essentiel pour ce TD est que les interfaces soient couvertes et que vous puissiez “prouver” à votre “client” que vous avez bien compris son problème et que vous allez y répondre.

Pour vous aider vous pouvez dans un premier temps, ne pas tenir compte de la boîte de messages par défaut et n'en tenir compte qu'à la fin du TD en identifiant bien les impacts sur le modèle et sur le code, en particulier avec les responsabilités qui en résultent.
  1. Quels modèles utilisez-vous pour analyser le problème ?
  2. Dans vos diagrammes de séquences, faîtes bien apparaître les interfaces graphiques et les contrôleurs mais dans les diagrammes de classe concentrez vous uniquement sur la partie métier dans un premier temps.
  3. Qui est capable de retrouver un bus à partir de son nom ? une boite de messages? (pattern expert)
  4. Qui est responsable de créer un bus? une boite de message? pourquoi? (Pattern créateur)
  5. Qui est responsable de créer un message ? pourquoi? (Pattern créateur)
  6. Avez-vous des relations bi-directionnelles? Si oui, avez-vous décidé de qui est le “maître” et de qui est l'“esclave”?
  7. A partir de maintenant, on s'intéresse au scénario suivant, sans tenir compte de l'interface graphique, est-ce que vous pouvez l'implémenter, revenez sur votre code si besoin (Vous pouvez vous aider des tuyaux donnés plus bas si besoin):
    1. Je crée un bus “NiceInformation”, et une boite “Circulation” sur ce bus.
    2. Je poste un message “Embouteillage” dans la boite Circulation.
    3. Je poste un message “Nouveau rond point” dans la boite Circulation.
    4. Je lis les messages qui se trouvent dans la boite circulation, i.e. je récupère les messages puis je les affiche.
    5. Je pose un message “SoireeIUT” sur le bus “NiceInformation”
    6. je demande à effacer le message “Embouteillage”.
    7. J'attends 2s (Thread.sleep(2000));
    8. Je pose un message “SoireeIntegrationIUT” sur le bus “NiceInformation”
    9. J'attends 2s (Thread.sleep(2000));
    10. Je demande à effacer tous les messages postés depuis plus de 4s.
  8. Regardez vos codes, et vérifiez que vous avez bien respecté la loi de Demeter. Si ce n'est pas le cas, corrigez vos codes.
  9. Comment avez-vous géré la boîte par défaut? (Avez-vous pensé à définir des constantes?)
  10. On tient compte de l'interface à présent. Schématisez en particulier dans un diagramme de séquence, le ou les contrôleurs mis en place en fonction de vos choix et mettez à jour si besoin la partie métier de votre code. On ne vous demande pas d'implémenter l'interface graphique.
    1. Quel objet peut jouer le rôle de contrôleur “Facade” éventuellement?
    2. Quels contrôleurs “cas d'utilisation” créeriez sinon?
    3. Utilisez-vous bien le principe de délégation?
  11. Et si maintenant, on veut afficher les messages en fonction de l'ordre d'arrivée? Que modifiez-vous? Est-ce que vous auriez pu éviter certains changements si vous aviez utilisé des interfaces?

A la fin de cette séance (au plus tard en fin de semaine)

  • Dans votre répertoire de projet, sous TD3, se trouvent:
    1. Un document contenant
      • votre modèle final (Tout le monde n'aboutit pas au même modèle, c'est certain)
      • des explications sur les raisons de ce modèle, les choix que vous avez faits et les leçons apprises.
    2. optionnel : les codes et les tests.

Dans cet exercice nous évaluons votre capacité à concevoir les bons modèles et la “bonne” architecture relativement à vos objectifs. Des modèles incomplets sont évidemment considérés comme faux au regard de ces objectifs.

Tuyaux

Vous avez besoin dans ce TD de manipuler des collections et des dates, voici quelques tuyaux que vous pourriez retrouver sur le Web et qui sont extraits des codes que nous avons mis en oeuvre pour ce TD. Vous pouvez évidemment avoir d'autres solutions :

  • Pour parcourir une ArrayList (le for qui suit)
  • Pour pouvoir effacer dans une liste que l'on parcourt, il faut d'abord en faire une copie
ArrayList<Message> messagesContenus = new ArrayList<Message>(messages);
        for (Message m : messagesContenus) {
            if (m.perime(i)) {
                m.detruire();
                messages.remove(m);
            }
  • Une manière “facile” pour savoir si un message est périmé de plus de x secondes :
  public boolean estPerime(int second){
        Date d = new Date();
        long ms = d.getTime();
        ms = ms - second*1000;
        d.setTime(ms);
        return this.dateEmission.before(d);
    }
  • Si vous avez utilisé des HashMap vous avez peut être besoin de récupérer la liste des objets contenus comme par exemple :
    public void detruireMessages(int i) {
       for (Boite b : boites.values()) {
           b.detruire(i);
       }

Responsabilités et Couplages

On distingue deux formes de consommation pour un même modèle de voiture :

  • la consommation moyenne sur route ou urbaine exemples
  • la consommation en fonction de la vitesse qui suit la règle suivante 1), elle ne prétend pas être vraie
 C(v) = 2(d/v) + K v^2 avec t en heures, d en km et k un coefficient variable en fonction des voitures. 

Si une voiture roule à 150 km/h sa consommation est donc en litre au 100km de :

 C(150) = 2(100/150) + K * 150^2 pour la Cl 

Avec un coefficient de 3,85*10^-4, C(150) = 9.99583333333; C(64) = 4,7 litres au 100km

Essayez de ne pas tricher, répondez aux questions une par une.
  1. Pour certains modèles de voitures, nous disposons de ces informations. Quelle modélisation proposez-vous pour répondre à des questions comme :
    • quelle est la consommation moyenne du modèle Clio sur Route (rep. 6,3)? urbaine(rep. 8,1)?
    • quelle est la consommation moyenne d'une Clio à 150km/h? (mettons que le coefficient est de 3,85*10^-4 et donc une réponse de quasi 10, … ce qui n'est pas du tout la réalité!!! ).
  2. Réfléchissez à l'implémentation sur papier au moins.
  3. On intègre à présent la consommation “Mixte”, qu'est-ce qui change dans votre modèle? dans votre code?
  4. On vient d'établir une formule 2) qui, pour certains modèles de voitures, à partir des données connues en circulation urbaine ou sur route permet de déterminer le coefficient K, selon la formule suivante : Au dessus de 100 on prend en compte la consommation sur route que l'on multiplie par 10^-4, entre 100 et 50, la consommation mixte et en dessous urbaine. Quelle modèlisation proposez-vous ? Quel est le couplage entre vos classes? Avez-vous bien supporté l'extension?
  5. Comment est-il possible de créer un modèle de voiture? Quel est le diagramme de séquence associé (sur papier a minima)? Quel est le code?
  6. En fait, pour certains modèles de voiture (par exemple, les Renaults), les consommations moyennes sont obtenues par des requêtes à un service externe qui, en fonction des informations sur le modèle (on se limite au nom et à l'année, par exemple Clio 2 et 2000), nous renvoie une chaine de caractères au format JSON, par exemple {“consommation”: {“route” : “6.3”, “urbaine” : “8.1” } }, Intégrer ce type de “calcul” de la consommation dans votre modélisation, quel est l'impact?
  7. Que retenez-vous?

A la fin de cette séance (au plus tard en fin de semaine)

  • Dans votre répertoire de projet, sous TD2, se trouvent:
    1. Un document contenant
      • votre modèle final (Tout le monde n'aboutit pas au même modèle, c'est certain)
      • des explications sur les raisons de ce modèle (dont vous êtes très fiers) et les leçons apprises.
    2. Les codes et les tests. Pensez bien que le service externe ne doit pas être implémenté. Une fonction qui pour l'instant retourne à chaque fois la même chaine de caractère convient très bien, et vous considérerez aussi la transformation d'une chaine de caractère JSON en “autre chose” comme donnée.

2)
C'est possible, mais je ne l'ai pas trouvé…
2014_2015/s3/concprogobjet/td/td3.1412066543.txt.gz · Last modified: 2014/09/30 10:42 by blay