ALP-projet

Getting started

Diagramme de classe UML :

Stratégies de diffusions :

Nous avons ajouté dans l'interface AlgoDiffusion la fonction getValue(), cette fonction permet de retourner une valeur du capteur gardé en mémoire par l'algorithme de diffusion. La valeur gardée en mémoire est gérée différemment en fonction de la stratégie de diffusion. On a donc aussi ajouté à l'interface Capteur la focntion getValueDiffusion() permettant de récupérer la valeur de l'algo de diffusion.

- Diffusion Atomique :

La diffusion atomique permet que tous les afficheurs affichent toutes les valeurs du capteur, ils affichent donc les mêmes valeurs. Le capteur change de valeur toutes les 500 ms alors que les canaux prennent entre 2s et 3s pour passer à la valeur suivante, les afficheurs prennent donc du retard. Si les capteurs tournent 1h, les afficheurs auront jusqu'à 5h de retard et au mieux 3h de retard.

On doit donc enregistrer les valeurs du capteur dans une file d'attente Queue<Integer> values. Alors getValue() de l'aglo de diffusion n'a qu'à faire un peek() sur cette file d'attente. À chaque appel de execute() on rajoute la valeur. Pour que les canaux soient synchronisés, on a une liste List<Future<?>> futures qui stocke les Future en cours de traitement (cette liste a donc au maxium comme taille le nombre de canaux). À chaque appel de execute(), on retire de la liste les Future terminés, quand la liste est vide alors ils sont tous terminés, on retire l'élément à la file d'attente, et on relance des nouveaux Future en faisant un update() sur chaque canal.

- Diffusion Sequencielle :

Ici, il faut simplement que les afficheurs aient des valeurs synchronisées et que les valeurs soient dans l'ordre chronologique. On n'a donc pas besoin d'afficher toutes les valeurs du capteur.

On a donc simplement besoin d'une valeur int value permettant de garder en mémoire une valeur du capteur commune pour tous les afficheurs. C'est cette valeur qui est retournée dans le getValue(). On a encore une liste List<Future<?>> futures qui a le même fonctionnement que pour Atomique, à la différence qu'il remplace simplement value par la nouvelle valeur quand futures est vide.

- Diffusion Epoque :

Cette dernière stratégie est la plus simple, les afficheurs doivent juste afficher chacune des valeurs dans l'ordre chronologique. Il n'y a donc pas de synchronisation entre les afficheurs, et pas non plus besoin d'afficher toutes les valeurs.

Il nous reste donc plus que futures, mais cette fois en tant que tableau de taille fixe Future<?>[] futures (nombre de canaux). On n'a pas besoin d'attendre que tous les Future soient finis pour passer à la suite, dès qu'un Future est fini, on relance directement un update() sur le canal associé. La fonction getValue() retourne donc directement la valeur courante du capteur sans rien sauvegarder au préalable.

Tests :

- Tests :

L'exécution dans chaque test on environ la même forme :

on initialise les afficheurs, le Sceduler, le capteur, l'algo de diffusion, les canaux
on lance le tick avec le scheduler.
on laisse tourner pendant quelques secondes (5s pour la stratégie atomique, et 10s pour les 2 autres)
on attend les potentiels derniers Future (25s pour la stratégie atomique, et 3s pour les 2 autres)
affichage des résulat des afficheur pour debug

ps : Pour l'ago de diffusion atomique une constante TEST_TIME est au début du test pour modifier la durée totale du test (1/6 de run + 5/6 d'attente)

Dans l'afficheur, nous avons ajouté une liste ArrayList<Integer> vals permettant de sauvegarder les valeurs affichées, qui sera utilisée ensuite par l'oracle.

- Oracle

Notre capteur envoie des valeurs de 1 en 1 à chaque ticket en commençant par 1

- Diffusion Atomique

On a deux oracles :

Un qui vérifie que les éléments sont strictement croissants de 1 en 1 en commençant par 1
Et un second qui vérifie que tous les canaux ont les mêmes éléments entre eux.

- Diffusion Sequencielle