User Tools

Site Tools


2014_2015:s3:concprogobjet:td:td5

This is an old revision of the document!


Réutilisation

Nous voulons gérer un réseau routier. Un réseau Routier est composée de PointRoute et d'Arcs Routiers. On veut savoir pour un réseau routier les chemins possibles entre deux points routes.

La modélisation initiale imaginée est celle du diagramme ci-dessous.

Voici le jeu de données à utiliser :

Et les tests :

Voici les réponses obtenues :

Pour cela on vous donne les classes suivantes :

  1. Le package grapheX duquel ont été extraits les classes utiles à notre problème; ce package a été récupéré sur le web à l'“X”
  2. Le package parcours a été créé pour vous simplifier la tâche

Les 2 diagrammes suivants ont été obtenus par reverse Engineering:

  1. Imaginer comment vous pourriez définir un réseau routier comme un graphe : quels sont les sommets? quels sont les arcs? etc. Compléter/Modifier le diagramme de classe avec ces informations.
  2. Dessiner le diagramme de séquence qui à partir d'un réseau vous permet d'obtenir tous les chemins entre deux points routes ordonnées sur la distance entre les noeuds.
  3. Ecrivez les tests et les codes correspondants.

Polymorphisme

Le bus supporte à présent différents types de messages : Rémanent, Ephemere, Fondamental, Protegé, Intelligent …

Chacun de ces types de messages répond aux exigences suivantes concernant leur cycle de vie.

Création Lecture MiseAJour Destruction
Rémanent Il connait son créateur Peut être mis à jour par son créateur Ne peut être détruit que pas son créateur
Ephemere Est automatiquement retiré de sa boîte dès qu'il est lu Ne peut pas être mis à jour Ne peut être détruit que s'il n'est plus dans une boite
TemporelIl connait la date où il a été créé et sa durée Il ne peut être lu que s'il n'est pas périmé. S'il est périmé, il est détruit lorsque l'on demande à le lirePeut être mis à jour Est automatiquement détruit quand il est périmé
IntelligentIl connait son créateurN'est proposé qu'à ceux qui ne l'ont pas encore lu Ne peut pas être mis à jourNe peut être détruit que si il a été lu au moins une fois
Re-armable Il peut être réactivé Il disparait en lecture au bout d'un temps donné, il doit alors être réactivé et s'il n'est pas re-armé, au bout d'un certain temps il est détruit

A FAIRE

  1. Proposer un modèle de classes en conception
  2. Vérifier que tous les scénarios sont “faisables”…
  3. Vérifier les propriétés vues en cours
  4. Implémenter et tester votre code sur les scénarios donnés.
  5. Vérifier que tous vos scénarios précédents sont toujours fonctionnels, en utilisant les tests. Si ce n'est pas le cas, mettez vos codes à jour pour satisfaire les tests.
  6. Quel impact sur le calcul du nombre de messages dans une boîte ?

Proposer un modele d'IHM de reception des messages pour les aider à comprendre… ou les laisser faire? ou la leur donner et les laisser la connecter?

Responsabilités

En fonction des mots clefs qui constituent le contenu des messages, ils sont automatiquement associés à une boîte de message. Si aucune correspondance n'est détectée une boîte “Divers” est utilisée.

Exemples :

  1. “Accident ” conduit à poster le message dans la boite “URGENCE”
  2. “Danger ” conduit à poster le message dans la boite “URGENCE”
  3. “photo ” conduit à poster le message dans la boite “SNAPCHAT”

A FAIRE

  1. Qui crée les messages?
  2. Qui est responsable de filtrer les mots clefs?
  3. Quel est la complexité du filtrage?
  4. Déterminer le couplage de vos classes

Abstraction

Si maintenant, on veut créer une nouvelle boîte qui reçoit les messages contenant contenant “photo”, que faut-il faire pour que votre système le prenne en compte?

Si maintenant on veut que tout message dans la boite SNAPCHAT soit ephemere ?

Estimation de performance

Une route est définie par des Tronçons. Un tronçon est défini par deux Positions et une longueur. Une Position est définie par un nom.

Calculer le plus cours chemin entre deux positions. Déterminer la complexité de votre algorithme.

⇒ Outils de recherche de code dupliqué?

Suites prévues pour ce projet

  • Objectifs : refactoring, incrémentalité et agilité : Le bus est maintenant composée de boîtes à messages :

Le bus gère des “boîtes à message”. Plusieurs producteurs peuvent émettre des messages vers une même boîte, plusieurs consommateurs peuvent lire les messages dans une boite. Dans le scénario de base, la voiture A a choisi d'émettre son message vers la queue “Etat Des Routes”. Les consommateurs déclarent les boîtes qui les intéressent. Ils peuvent lire les messages qui les intéressent sur une boîte donnée ou obtenir tous les messages qui les intéressent indépendamment des boîtes. Plusieurs types de messages? Qui est responsable de créer les messages? Qui connait les boîtes de messages ?

  • Objectifs : Apprentissage d'une famille courante de patterns (fabrique, builder) mais uniquement par l'usage, la formalisation se fera en S4: Les messages pouvant être de différentes natures, un bus devient “porteur” d'une fabrique à messages.
  • Objectifs : Prise en compte des IHMs et mise en place du pattern MVC à tous les niveaux : Définir les interfaces graphiques qui nous permettraient d'accéder “simplement” à un bus pour émettre, lire et effacer des messages uniquement.
  • Objectifs : Prise en considération des responsabilités uniques : Routage en fonction des messages : La voiture A emet un message et le bus décide de la ou des boîtes à messages concernées.
  • Objectifs : mise en oeuvre du pattern DAO + différents modèles de persistance + intégration par les interfaces + travail en équipe : Les messages seront rendus persistants. Pour certaines boîtes les messages sont persistants, pour d'autres non :
  • Il est assez surprenant d'effacer les messages au bout d'un certain temps alors que certains consommateurs ne les ont pas lu et de redonner le même message au même consommateur qui l'a déjà lu. Que feriez-vous pour : a) ne pas redonner le même message au même consommateur; b) donner les messages aux consommateurs qui ne les ont pas encore lu? quel écueil( le bus ne connait pas ses consommateurs!) ? quelle solution envisageriez-vous (un consommateur se déclare, une file d'attente par consommateur, et le message est détuit lorsque plus aucune file n'y fait référence)?

- Il sera possible de définir différentes formes de souscription.

Nous n'aborderons, hélas, pas les aspects distribués.

2014_2015/s3/concprogobjet/td/td5.1413044603.txt.gz · Last modified: 2014/10/11 18:23 by blay