Differences

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

--- 2014_2015:s3:concprogobjet:td:td6 [2014/11/02 21:17]
blay [Capteur Passif Réactif (Simple)]
+++ 2014_2015:s3:concprogobjet:td:td6 [2014/11/28 22:47]
blay [Refactoring et Pattern Composite]
@@ Line 40: / Line 40: @@
 ===== Capteurs Passifs =====
-Les capteurs "passifs" sont des capteurs qu'il faut interroger pour obtenir la valeur correspondant par exemple à une température ou un éclairage.  A un capteur passif nous associons un capteur physique qui 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.
+Les capteurs "passifs" sont des capteurs qu'il faut interroger pour obtenir la valeur correspondant par exemple à une température ou un éclairage.  A un capteur passif nous associons un {{:2014_2015:s3:concprogobjet:td:capteurphysique.zip|capteur physique}} qui 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.
@@ Line 47: / Line 47: @@
    - Définir la classe CapteurPassif en lui associant un capteurPhysique.
+Voici les codes dont vous avez besoin :
+   *{{:2014_2015:s3:concprogobjet:td:capteurphysique.zip|}}
+   *{{:2014_2015:s3:concprogobjet:td:fichiero.zip|}}
 ===== Pièce équipée =====
@@ Line 91: / Line 94: @@
-QUESTION :
+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 :
@@ Line 170: / Line 173: @@
-Vous pouvez faire le choix de continuer à tester avec EasyMock ou de faire les tests en créant les bouchons etc.
+QUESTION (30mn) :
+   * Vous pouvez faire le choix de continuer à tester avec EasyMock ou de faire les tests en créant les bouchons etc.
 ===== Pièce numérique "intelligente" =====
-L'objectif est à présent de définir des pièces intelligentes comme contenant des capteurs passifs et des capteurs passifs réactifs. Lorsque l'un de ces derniers capteurs a sa valeur modifiée, la pièce est notifiée du changement et le update consiste à ré-afficher les valeurs de tous les capteurs.
+L'objectif est à présent de définir des pièces intelligentes qui lorsque l'un de ses capteurs "Observable" a sa valeur modifiée, la pièce est notifiée du changement et le update consiste à ré-afficher les valeurs de tous les capteurs.
-Question : Vous devez définir une "SmartPiece" sans modifier une Piece.
+QUESTION (10mn) :
+    * Vous devez définir une "SmartPiece" sans modifier une Piece.
@@ Line 184: / Line 189: @@
 Lorsque l'on ajoute un capteur à une pièce de la maison on veut que le tableau de bord de la maison prenne automatiquement en compte cette évolution.
-Question : Modifier vos classes pour prendre en compte cette nouvelle exigence, si vous ne l'aviez pas déjà fait.
+QUESTION :
+    * Modifier vos classes pour prendre en compte cette nouvelle exigence, si vous ne l'aviez pas déjà fait.
 Si vous le voulez, vous êtes autorisé à cette étape à utiliser les classes java ''java.util.Observable'' et ''java.util.Observer''.
-===== Capteurs Réactifs =====
+===== Capteurs actifs =====
 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.
@@ Line 194: / Line 200: @@
 Voici les éléments de code dont vous avez besoin pour le définir :
    *  Ce code vous permet de le déclarer comme pouvant s'exécuter "dans une thread à part" : <code Java>
-public class CapteurReactif  ... implements... Runnable{
+public class CapteurActif  ... implements... Runnable{
 </code>
@@ Line 220: / Line 226: @@
-QUESTION (15mn) :
+QUESTION (30mn) :
-     * Définir les capteurs réactifs
+     * Définir les capteurs actifs
-<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
-- afficher les valeurs des capteurs passifs
-- 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
-- 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 ?
-===== 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 =====
+===== Refactoring et Pattern Composite =====
-  * //Objectifs  : refactoring, incrémentalité et agilité// : Le bus est maintenant composée de boîtes à messages :
+On vient de réaliser que des dispositifs peuvent être associés directement à la maison et pas forcément aux pièces.
-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.
+Proposer une modélisation qui préserve l'ensemble de vos "tests" mais vous permet de prendre en compte cet aspect.
---!>
-</html>

Cours au département INFO - IUT - UNS

User Tools

Site Tools

Differences

Page Tools