Cours au département INFO - IUT - UNS

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.



====== Digital Home : application des DP ======

Objectifs de ce TD : 
  - Appréhender une petite application dans sa totalité
  - Savoir utiliser un patron "State"
  - Savoir utiliser un patron "Observer" et "Composite"

Les temps indiqués sont là pour vous aider. Il s'agit des temps maximum.



===== Cadre général =====

Un "maison numérique" est équipée de "dispositifs" dont les //capteurs// qui sont des composants qui permettent de relever des mesures.

Les "capteurs" sont soit associés à la maison (par exemple, un thermostat central), soit associés à une partie de la maison (par exemple, un capteur de consommation électrique à l'étage, un détecteur de fumée dans l'espace enfant), aux pièces (interrupteurs, thermomètre, ...).

Un tableau de contrôle permet de visualiser les valeurs relevées par tous les capteurs de la maison.




Notre objectif est de permettre de : 
   - créer des maisons numériques auxquelles on peut ajouter des dispositifs,
   - visualiser les valeurs des différents dispositifs contenus dans la maison.

Les capteurs physiques sont des dispositifs qui présentent une grande variabilité. Nous allons les gérer via des composants logiciels.

QUESTION (15 mn): 
  * Analyser le problème sur papier (préparation à l'examen). 
        * Vous devez maintenant savoir seuls ce dont vous avez besoin pour analyser un problème.
        * Vous devez vérifier que vous savez faire les diagrammes sans outil.
        * Représentez le scénario suivant sous la forme d'un diagramme de séquence en conception : 
           - L'utilisateur sélectionne sur l'écran du tableau de bord, "Mise à jour"
           - Le tableau de bord recherche tous les capteurs de la maison et demande à chacun sa valeur courante,
           - Les capteurs logiciels interrogent les capteurs physiques pour récupérer leur valeur,
           - Le tableau de bord demande l'affichage à son écran de toutes les valeurs des capteurs pièce par pièce. Pour cela, il lui envoie une chaine de caractères qui correspond à l'affichage à produire.


  




===== Capteurs Physiques =====

<html>
<img src="http://i2.cdscdn.com/pdt2/9/1/1/1/700x700/zub3700825912911/rw/zublin-detecteur-mouvement-ext.jpg" width="120" /> Détecteur de mouvement
<br/>
<img src="http://www.wikidebrouillard.org/images/3/36/Temp%26Humi.jpg" width="120" /> 
Capteur de température et humidité
</html>

Hélas nous ne disposons pas de "capteurs physiques"...
Faisons comme si nous avions ces capteurs en les simulant par des  ''capteurs physiques'' dont le code vous est donné. Il s'agit d'un "composant" très simple qui lit et écrit une valeur dans un fichier. Il vous sert de "bouchon" puisque nous ne disposons pas d'un vrai capteur physique auquel nous connecter.

QUESTION (5 mn): 
  * Récupérer le code "bouchon" du {{:2017_2018:s3:concprogobjet:td:physicalsensor.jar|capteur Physique}}. **VOUS n'avez pas le droit de le modifier !!** ; vérifiez que les tests passent bien avant de passer à la suite.
<note tip>Attention de manière générale on ne fait pas des tests sur des "string" pour tester l'état des objets. 

On ne lève pas des Throwable mais des exceptions dédiées qui expriment clairement l'exception détectée (http://www.wikijava.org/wiki/10_best_practices_with_Exceptions#Throw_only_Exceptions) </note>
===== Capteurs logiciels =====

Les capteurs "logiciels" sont des capteurs qu'il faut interroger pour obtenir la valeur correspondant par exemple à une température ou un éclairage.  A un capteur logiciel nous associons un capteur physique.
A votre convenance un capteur logiciel peut modifier la valeur lue dans le capteur physique pour lui associer une unité //e.g. getValue pour un capteur de température retournera la valeur plus "°C", "18 °C".//

Attention, un capteur logiciel renvoie des valeurs sous la forme d'une String.
S'il y a une erreur d'accès  au capteur physique quelqu'elle soit, on doit avoir en réponse "bad value".

QUESTION (15 mn): 
   - Mettez à jour votre diagramme de classe si besoin.
   - Définir la classe ''Capteurlogiciel'' en lui associant un ''CapteurPhysique''. 
   - Tester vos capteurs logiciels.


===== Capteurs logiciels à état =====



Certains capteurs peuvent changer d'état.
  * Dans l'état "Off", lorsque on lui demande ses données, il répond "Off".
  * Dans l'état "On", lorsque on lui demande ses données, il demande au capteur physique qui lui est associé. 
  * Dans l'état "Lazy", lorsque on lui demande ses données, il ne demande la valeur au capteur physique que s'il ne l'a pas déjà ou que la valeur qu'il a sauvegardé date de plus de x temps. De cette manière on souhaite faire des économies d'énergie.

Un tel capteur change d'état sur ordre : "on", "off", "lazy".


Pour obtenir le temps courant: 
<code java>
long startTime = System.currentTimeMillis();
</code>
Exemple de code pour tester l'état "Lazy" :
<code java>
public class StateLazyTest {

	StateLazy sl;
	Sensor ps = ....;
	
	@Before
	public void setUp() throws Exception {
		ps.setValue("18");
		sl = new StateLazy(ps);
	}

	@Test
	public void test() throws NonAccessibleSensorException, MalFormatteeCapteurException, InterruptedException {
		String v = sl.getValue();
		assertEquals("18",v);
		ps.setValue("20");
		assertEquals("Lasy access : value non modified", "18", sl.getValue());
	    Thread.sleep(150);
		assertEquals("wake up : value modified", "20",  sl.getValue() );
		assertEquals("value modified", "20",  sl.getValue() );
	}
</code>

QUESTION (15 mn): 
   - Mettez à jour votre diagramme de classe si besoin en identifiant bien les éléments de design pattern.
   - Définissez la classe ''CapteurOnOffLazy''
   - Testez votre classe, voici des exemples si cela peut vous aider.
<code java>
	@Before
	public void setUp() throws Exception {
		  ps = new PhysicalSensor("mySensorLux");
	      sOnOffLazy = new SensorOnOff(ps);
	      sOnOffLazy.setValue("18");
	}

	@After
	public void tearDown() throws Exception {
	}

	@Test
	public void testStateInit() {
		assertEquals("Off at the beginning","off",sOnOffLazy.getValue());
	}
	
	@Test
	public void testStateOn() throws IOException, NonAccessibleSensorException {
		sOnOffLazy.on();
		assertEquals("On","18",sOnOffLazy.getValue());
		sOnOffLazy.setValue("20");
		assertEquals("On","20",sOnOffLazy.getValue());
	}
	
	@Test
	public void testStateOnOff() throws IOException, NonAccessibleSensorException {
		sOnOffLazy.on();
		assertEquals("On","18",sOnOffLazy.getValue());
		sOnOffLazy.off();
		assertEquals("off",sOnOffLazy.getValue());
	}
	
	
	
	
	@Test
	public void testStateLazy() throws IOException, NonAccessibleSensorException, InterruptedException {
		sOnOffLazy.lazy();
		assertEquals("18",sOnOffLazy.getValue());
		sOnOffLazy.setValue("20");
		assertEquals("Lasy access : value non modified", "18", sOnOffLazy.getValue());
	    Thread.sleep(150);
		assertEquals("wake up : value modified", "20",  sOnOffLazy.getValue() );
		assertEquals("value modified", "20",  sOnOffLazy.getValue() );
	}
	
</code>


QUESTION (10 mn): //(Facultatif)//
   * On veut définir des capteurs à un seul bouton (appel de la méthode press).
      * L'état de départ est off. 
      * Dans l'état //Off//, si on appuie une fois (2 appels à off), on est //On//. 
      * Dans l'état //On// si on appuie 2 fois (2 appels à on) on est //Lazy//. 
      * Dans l'état //Lazy// si on appuie 2 fois (2 appels à lasy) on est //Off//.
   - Mettez à jour votre diagramme de classe si besoin.
   - Définir la classe ''CapteurOneButton''



===== Pièce équipée =====

Une pièce est équipée de capteurs.
On peut ajouter des capteurs à la pièce.
On peut obtenir tous les capteurs de la pièce.

QUESTION (10 mn): 
   - Complétez ou corrigez si besoin votre diagramme de classe.
   - Implémentez la classe ''Piece''
   - Créez un jeu de tests vous permettant de tester votre classe ''Piece''. 

Exemple de l'appel d'affichage suite à l'appel à ''toString'' sur une pièce:
<code>
Salon
	thermometre:19.0	humidite:12.7	lumiere:120.0
</code>

===== Maison numérique =====

Une maison numérique est une composition de parties dont certains parties sont elles-même des compositions de parties (l'étage est composé de la partie enfant et du bureau) et d'autres sont des pièces (bureaux, chambres, ..).

Il doit être possible d'interroger une partie de la maison pour connaitre tous les capteurs qu'elle contient : Pour une pièce, les capteurs qui lui sont associés, pour une partie composite, ses propres capteurs (par exemple, le thermostat de l'étage) + les capteurs des parties qui la compose.



Voici la maison que vous devez modéliser : 
  - Un RDC, un étage et un extérieur.
  - Un étage avec 2 chambres, chacune avec son thermometre et un thermostat global à l'étage 
  - etc.
{{ :2015_2016:s3:concprogobjet:td:maisonnumerique.png?direct&300 |}}

QUESTION (25 mn): 
  * Modélisez la classe ''MaisonNumerique'' et **tout** ce qui est nécessaire pour répondre aux exigences.
  * Avez-vous utilisé un ou des DP? Si oui, annotez vos classes avec des "stéréotypes" permettant d'identifier les différents rôles joués par vos classes.
  * Implémentez et testez la.
  * Implémentez la maison donnée ci-après, et vérifiez que vous êtes bien capable de la représenter.

<note tip>Oui oui, l'énoncé n'est pas mâché... Il est possible que vous deviez réécrire des codes, mais maintenant ce n'est plus un problème n'est-ce pas? 

Posez bien votre nouveau modèle sur papier avant d'implémenter.
</note>



Voici une nouvelle maison, décrite un peu différemment.

<code>
maison = new Maison();
rdc = new PartieMaison("RDC");
cuisine = new Piece("Cusine");
sam = new Piece("Salle e manger");

parentalPart = new PartieMaison("Partie Parentale");
chambreParents = new Piece("parents");
sdbParent = new Piece("salle de bain des parents");
parentalPart.addLieu(chambreParents);
parentalPart.addLieu(sdbParent);
parentalPart.addSensor(thermostatParental);

rdc.addLieu(cuisine);
rdc.addLieu(sam);
rdc.addLieu(parentalPart);


etage = new PartieMaison("Etage");
chambre1 = new Piece("Chambre1");
chambre2 = new Piece("Chambre2");
etage.addLieu(chambre2);
etage.addLieu(chambre1);

exterieur = new PartieMaison("Exterieur");
exterieur.addSensor(externeDetecteurLumiere);
maison.addLieu(rdc);
maison.addLieu(etage);
maison.addLieu(exterieur);

</code>
===== Tableaux de Contrôle =====

Un  tableau de contrôle permet de visualiser les capteurs associés aux lieux qu'il surveille.
Pour cela, à chaque fois que l'on ajoute un capteur aux lieux surveillés, il ré-affiche la valeur de tous les capteurs.
Attention, si je surveille le RDC, je surveille tous les capteurs du RDC pas seulement ceux qui sont en dehors des pièces!

Dans notre exemple, nous avons mis un tableau de contrôle au RDC et un à l'étage et un pour toute la maison.
On ajoute un thermomètre dans la cuisine et on ajoute un de capteur de luminosité à l'étage, ainsi qu'un capteur de présence à l'extérieur. On vérifie que nos tableaux de bord se sont bien mis à jour.

** TB  MAISON ** 
<code>
Thermostat RDC : 20
Thermometre SAM : 20
Thermostat Etage : 18
ThermometreChambre1 : 18.5
ThermometreChambre2 : 19.5
Luminosite : 100
Luminosité Etage : 80
Presence : true
Thermometre Cuisine : 19
</code>

**TB  RDC ** 
<code>
Thermostat RDC : 20
Thermometre SAM : 20
Thermometre Cuisine : 19
</code>

**TB  ETAGE ** 
<code>
Thermostat Etage : 18
ThermometreChambre1 : 18.5
ThermometreChambre2 : 19.5
Luminosité Etage : 80
</code>


<note>Attention, ce n'est pas "facile", mais c'est à votre niveau ! </note>

==== Optionnel ====

Pour s'amuser... évidemment dès que la valeur d'un des capteurs surveillé par un tableau de contrôle change de valeur, le tableau de bord se réaffiche...

Placer bien vos lignes de codes et vous n'avez presque rien à faire!!

<html>
<!-- 
===== Capteur Passif Réactif (Simple) =====

Un capteur Passif réactif est un capteur passif mais qui peut être observé. Lorsque sa valeur est modifiée par un setValeur, il notifie les observeurs du changement de valeur.


<note important>Nous n'utiliserons pas les classes prédéfinies en java comme Observer et Observable pour bien comprendre l'intérêt de ce pattern et l'adapter à notre cas d'étude.</note>



QUESTION (30mn) : 
  * Définir la classe ''CapteurPassifReactif'' comme une extension de la classe ''CapteurPassif''.
  * Vous rendez ses instances observables en respectant le pattern ci-après : 
        * Un observeur d'un ''CapteurPassifReactif'' doit pouvoir recevoir des messages ''update(String message)'' : Nous aurons des ''ObserveurDeCapteur''
        * On peut enregistrer des ''ObserveurDeCapteur'' dans un ''CapteurPassifReactif'' et en enlever;
        * A chaque appel au ''setValeur'' d'un ''CapteurPassifReactif'' tous les observeurs sont notifiés par un ''update'' et la nouvelle valeur du capteur en paramètre.

Nous n'avons pas encore défini d'observeur d'un capteur. Cependant nous voulons vérifier que les notifications sont bien prévues. 

--!>
</html>
<html>
<!-- 

===== Test d'intégration et Capteur Passif Réactif =====

Ces tests sont basés sur http://easymock.org/


Il s'agit de vérifier que lorsque que la valeur du capteur réactif est modifiée, la méthode //update// des observeurs est bien appelée.

Pour cela voici un extrait de code qui doit vous aider.

{{:2014_2015:s3:concprogobjet:td:easymock-3.2.zip|voici l'archive dont vous avez besoin}}


<code java>

import java.io.IOException;

import org.easymock.EasyMockRunner;
import org.easymock.EasyMockSupport;
import org.easymock.Mock;

import org.junit.Test;
import org.junit.runner.RunWith;
import org.junit.After;
import org.junit.Before;

@RunWith(EasyMockRunner.class)
public class CapteurPassifReactifTest extends EasyMockSupport {
	CapteurPassifReactif cpTemporaire ;
	
    @Mock
    private ObserverDeCapteur observeur; 
    @Mock
    private ObserverDeCapteur observeur2; 

    @Before
    public void setUp() throws Exception {
       cpTemporaire = new CapteurPassifReactif(new CapteurPhysique("cp1"));		
	}

     @After
     public void tearDown() throws Exception {
		cpTemporaire.unregister(observeur);
	}
	
    //tests integration
    @Test
    public void testCapteurSetValeur() throws IOException, NonAccessibleCapteurException {
	observeur.update("12.2"); //Appel attendu
	replayAll(); //Memoriser
	cpTemporaire.register(observeur);
	cpTemporaire.setValeur(12.2);
        verifyAll(); //Verification
    }
	
	
    //tests integration
    @Test
     public void testCapteurSetValeurMultipleObserveurs() throws IOException, NonAccessibleCapteurException {
	observeur2.update("12.2");//
	observeur.update("12.2"); //Appel attendu
	replayAll(); //Memoriser
	cpTemporaire.register(observeur);
	cpTemporaire.register(observeur2);
	cpTemporaire.setValeur(12.2);
        verifyAll(); //Verification
    }
	
</code>


QUESTION (30mn) : 
   * Vous pouvez faire le choix de continuer à tester avec EasyMock ou de faire les tests en créant les bouchons etc.

--!>
</html>




===== Capteurs actifs (Facultatifs) =====

Un capteur actif est associé à un capteur physique. Il scrute régulièrement la valeur physique du capteur physique qui lui est associé et notifie ses observeurs chaque fois qu'il détecte un changement.

A présent les tableaux de bord sont mis à jour à chaque fois qu'un capteur actif d'un lieu sous surveillance est mis à jour.

Voici les éléments de code dont vous avez besoin pour définir un capteur actif: 
   *  Ce code vous permet de le déclarer comme pouvant s'exécuter "dans une thread à part" : <code Java>
public class CapteurActif  ... implements... Runnable{
</code>

   * Ce code est une méthode de votre CapteurActif qui explicite la boucle qui va lire le composant physique: <code java> public void run() {
		System.out.println("Run lancé");
		while (!stop) {
			try {
				Thread.sleep(2000);
				if (!(valeurCourante.equals(getValeur())))  {
					setValeurCourante(getValeur());
				}
			} catch (InterruptedException e) {
				// TODO Auto-generated catch block
				e.printStackTrace();
			}
		}
	}
</code>
  * Le code suivant vous permet de "lancer" votre capteur :
<code java>
CapteurActif cpTemporaire = new CapteurActif(new CapteurPhysique("cp1"));	
Thread threadCP= new Thread(cpTemporaire);
threadCP.start();
</code>


QUESTION (30mn) :  
     * Définir les capteurs actifs et les connecter aux tableaux de bord.




==== Un peu de recul sur l'application  ====
<note warning>C'est juste des remarques.</note>

  - Si la maison est équipée de 10 capteurs et que chaque capteur est mis à jour toutes les secondes, .... votre tableau de bord se réaffiche 10 fois par seconde... 
  - Si maintenant vous réfléchissez au niveau de la ville... Les tableaux de bord ne sont pas directement "connectés" aux capteurs... d'autres approches par exemple avec des "files d'évènements" qui doivent vous rappeler le bus du 1e TD seront préférables... 


===== Robots =====

Dans notre maison nous plaçons des petits robots.

Nous avons des robots "surveillant". En mode repos, le robot surveillant attend que quelqu'un lui demande de passer en mode contrôle.
En mode contrôle, il interroge toutes les pièces et envoie toutes les valeurs relevées sur un "bus dédié" en précisant l'heure et le lieu des relevés. Une fois qu'il a fait le tour de toutes les pièces de la maison, il passe en mode surveillance.
En mode surveillance, il ne surveille que certains capteurs  (par exemple, un détecteur de fumée et un détecteur de présence) et déclenche son alarme  (capteur dédié) quand ils changent de valeur. Il passe alors en mode Alerte. Il ne peut sortir de cet état que si on le fait passer en mode repos ou si les capteurs qu'il surveille ont retrouvé leur valeur initiale (par exemple le détecteur de fumée est sur non et le détecteur de présence aussi), il retourne alors en mode Surveillance.
{{ :2015_2016:s3:concprogobjet:td:state_machine_diagram_robots.jpg?direct&300 |}}


==== Pour ceux qui ont fini le reste et ont du temps.. ====

Nous avons un drone qui est équipé de plusieurs capteurs.
En mode contrôle, il se déplace dans les pièces et envoie toutes les valeurs relevées à un bus dédié en précisant l'heure et le lieu des relevés. Une fois qu'il a fait le tour de toutes les pièces de la maison, il passe en mode surveillance. Vous simulerez les relevés de mesure en fonction des lieux comme bon vous semble En mode surveillance, il contrôle régulièrement l'état de son capteur de détection de présence et s'il passe à "présence détecté", il met la valeur de l'alarme (capteur propre au drône) à en marche et passe en mode Alerte. Il ne peut sortir de cet état que en lui donnant l'ordre de passer en mode contrôle. 

===== Rendu =====

<box round rgb(150,290,190) rgb(198,226,150) 75%|Rendu en fonction du groupe de TD : 15 décembre 2017  > 
  *  [[http://jalon.unice.fr/cours/blay/Cours-blay-20150930110548/BoiteDepot-blay-20161122213044309075?mode_etudiant=true&tab=deposit|Dépôt sur Jalon]] pour Mme Blay-Fornarino avec une archive à vos Noms, qui contient : 
  * Un document contenant 
             * votre **modèle de classe final** intégré dans un document pour que nous n'ayons pas à ouvrir différents modèles dans différentes versions de l'outil,
             * des explications sur les raisons de ce modèle (dont vous êtes très fiers) et les leçons apprises.
  * Les codes et les tests. 
</box>




<html>
<!-- 
==== Capteurs actifs automatiques ====
On définit ces capteurs par extension des précédents.

Un boucle interne lancée au ... va lire dans un fichier régulièrement et fait un setValeur().
 
QUESTION (15mn) :  
      * Etendre votre diagramme de classe en conception pour lui ajouter la classe "CapteurReactifAutomatique"
      * Implémenter la.
      * La tester.  

Leur donner la boucle de lecture dans un fichier par thread.


==== Capteurs actifs automatiques intelligents ====
Ne notifier que si la valeur a changé.


==== Pièce numérique ====

Une pièce est à présent composée d'un ensemble de capteurs passifs et de capteurs actifs.

Creer un pièce, créer les capteurs assiociés puis 
1- afficher les valeurs des capteurs passifs
2- afficher les valeurs des capteurs actifs à chaque notification de changement de valeur

Uniformiser pour les voir tous de la meme facon en ajoutant un boucle devant tut capteur passif etc...

Monter au niveau de la maison




==== Capteurs actifs : Test d'intégration ====

On veut vérifier que notre composant fonctionne bien en intégration, c'est à dire qu'il notifie bien les composants à l'écoute. 

Pour cela on définit

lecture dans un fichier régulièrement et notifie à chaque lecture.

Leur donner la boucle de lecture dans un fichier par thread.

??? Extension : setFrequence de lecture.

??? Extension : notifie que si changement de valeur de lecture.

==== Capteurs actifs "en boucle" ====



===== Capteurs Actifs =====

Fournir les interfaces


Un bus avec des boites sur lesquels on emet des messages

MyHighWay definit un service permettant 
1- d

=> get messages(troncon)
=> emettre un message (Troncon, contenu)

Un conducteur a la consommation de sa voiture, il demande a un service extérieur la consomation de son modele de voiture et



Un service externe "J'aime" "j'aimePas" avec un sujet...

Un message sur Twitter?

On veut connecter un lecteur de flux RSS à notre bus.
Ainsi on veut faire une boite qui est connecté au flux.
On va vous fournir une classe qui fait cela en respectant l'interface suivante.

On veut que vous étendiez les boites de messages pour ne retourner que des messages qui contiennent un mot clef.

Vous devez tester en vérifiant que : 
- le système n'affiche rien s'il n'y a pas de message, ou qu'aucn message ne contient le mot, dans ce cas, on veut que vous retourniez un message qui diot "pas de messages dans le flux"
- qui permet de connaitre le nombre de messages dans le flux

etc...



https://mbf-iut.i3s.unice.fr/doku.php?id=2013_2014:lp:idse:gl:td:testsmockup

http://www.iut.unice.fr/actualite/breves-rss/


https://www.facebook.com/feeds/page.php?format=rss20&id=100000515639166

rss reader


====== 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|
^Temporel|Il 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 lire|Peut être mis à jour| Est automatiquement détruit quand il est périmé|
^ Intelligent|Il connait son créateur|N'est proposé qu'à ceux qui ne l'ont pas encore lu| Ne peut pas être mis à jour|Ne 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**
  - Proposer un modèle de classes en conception
  - Vérifier que tous les scénarios sont "faisables"...
  - Vérifier les propriétés vues en cours 
  - Implémenter et tester votre code sur les scénarios donnés.
  - 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.
  - 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 :
     - "Accident " conduit à poster le message dans la boite "URGENCE"
     - "Danger " conduit à poster le message dans la boite "URGENCE"
     - "photo " conduit à poster le message dans la boite "SNAPCHAT"

**A FAIRE**
    - Qui crée les messages?
    - Qui est responsable de filtrer les mots clefs? 
    - Quel est la complexité du filtrage?
    - 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 ?





===== 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.

--!>
</html>
http://java-design-patterns.com/blog/controlling-access-with-proxy-pattern/


https://github.com/iluwatar/java-design-patterns/tree/master/composite
Cours au département INFO - IUT - UNS

User Tools

Site Tools

Page Tools
