Projet Active Object

Transcription

1 Projet Active Object TAO Livrable de conception et validation Romain GAIDIER Enseignant : M. Noël PLOUZEAU, ISTIC / IRISA Pierre-François LEFRANC Master 2 Informatique parcours MIAGE Méthodes Informatiques Appliquées à la Gestion des Entreprises Université de Rennes 1,

2 Table des matières 1. Introduction Le projet Observer Spécifications Définition des trois algorithmes de diffusion Algorithme de diffusion atomique Algorithme de diffusion séquentielle Algorithme de diffusion par époque Architecture du projet Le dossier de sources : «src» Le fichier de configuration : «init.properties» Le dossier de JAVADOC : «javadoc» Les patrons de conception Observer Command Singleton Proxy Strategy Active Object Le diagramme de conception : Plateform Independant Model Le diagramme de conception : Plateform Specific Model Diagramme de séquence de notre implémentation Tests et validation Politique de test Interface graphique pour les tests Résultat des tests LEFRANC Pierre-François Page 2

3 3. Difficultés rencontrées Conclusion du projet LEFRANC Pierre-François Page 3

4 1. Introduction Le module de Techniques Avancées pour la conception par Objets (TAO) a pour but d offrir aux étudiants la compréhension de la mise en œuvre d architectures asynchrones, via l implémentation du patron de conception Active Object et l utilisation du langage Java. TAO permet en outre d associer les principaux patrons de conception vus au cours du module AOC à une architecture asynchrone. L objectif du projet était de réaliser un service de diffusion de données de capteur. La solution à construire devait s appuyer sur des mécanismes de programmation par «threads», le patron de conception observer ainsi que le patron de conception Active Object. Ce dernier nous a notamment permis de limiter la manipulation de «Threads» Java qui se révèle, le plus souvent, très fastidieuse. Pour cela, nous avons utilisé la méthode dite du «cycle en V». Nous avons commencé par analyser les besoins et la faisabilité du projet, puis rédigé les spécifications logicielles avant de réaliser la conception pour terminer par les tests et la validation. LEFRANC Pierre-François Page 4

5 2. Le projet Observer 2.1. Spécifications Le but de l application est de proposer à l utilisateur un programme permettant d envoyer des informations numériques pour ensuite les afficher sur différents afficheurs. Pour cela, nous devions mettre en place un système de capteur transmettant des valeurs à des canaux de diffusion. Ces derniers devaient se charger de créer des «Method Invocation» permettant l envoi des valeurs sur des afficheurs. Une des spécificités du projet est que ces canaux devaient posséder des délais de propagation aléatoires, simulant une latence. De plus, l application devait proposer un choix d algorithmes permettant différents types de diffusion de valeurs. Ces spécifications nous ont amené à mettre en place différents composants au niveau de l interface utilisateur : Un champ de saisi du nombre d afficheurs : «nombre d afficheurs», Un bouton marche : «Démarrer», Des boutons dits «radio» de sélection de l algorithme de diffusion : «Algorithme diffusion». Un écran d affichage des différents canaux et afficheurs est présent afin que l utilisateur puisse s assurer du bon fonctionnement de l application. Sur cet écran, on retrouve notamment l identifiant du canal, sa latence mais également la valeur de l afficheur ainsi que sa version. Les valeurs possibles de latence sont comprises entre 500 et millisecondes (inclus). L interface de ce projet est une interface SWING dont l interactivité est gérée grâce à des «listeners» qui détectent les actions de l utilisateur et réalisent les traitements idoines : il y a inversion du contrôle. Moteur du projet IHM SWING LEFRANC Pierre-François Page 5

6 2.2. Définition des trois algorithmes de diffusion Algorithme de diffusion atomique La diffusion atomique consiste à envoyer la donnée du capteur à tous ses observateurs en s assurant que cette dernière est affichée sur tous les afficheurs avant de se modifier. De plus, ces derniers ne doivent occulter aucune valeur. Cela nécessitait donc une action à mettre en place pour bloquer le capteur tant que tous les afficheurs n ont pas reçu leur valeur Algorithme de diffusion séquentielle La diffusion séquentielle ressemble trait pour trait à la diffusion atomique à l exception près que toutes les valeurs du capteur ne sont pas obligatoirement affichables. Cela se traduit par le fait que le capteur continue de fonctionner durant la transmission des valeurs. Ce qui a pour conséquence, le non affichage de certaines valeurs Algorithme de diffusion par époque La diffusion par époque consiste à ajouter un numéro de version à la valeur transmise. Il n existe aucune contrainte tant au niveau des afficheurs qu au niveau du capteur Architecture du projet Le dossier de sources : «src» Client Ce package permet de regrouper les «lanceurs» du projet. Il s agit du «main» de l application. Command Ce package permet de regrouper toutes les commandes de l application. IHM Ce package regroupe tous les composants nécessaires à l élaboration de l IHM ainsi que les «listeners SWING». Matériel Ce package regroupe tout le matériel de l application : une horloge, un fichier de configuration. Active Object Ce package regroupe l «executor» (ou Scheduler) ainsi que les «Method Invocation» du patron de conception active object. LEFRANC Pierre-François Page 6

7 Afficheur Ce package regroupe les afficheurs de l application permettant l affichage des valeurs et des versions. Canal Diffusion Ce package regroupe les canaux de diffusion qui transmettent les valeurs depuis le capteur jusqu à son afficheur via la création de «Method invocation». Capteur Ce package regroupe les classes du capteur qui permet de modifier la valeur à transmettre. Strategy Diffusion Ce package regroupe l ensemble des algorithmes de diffusion : atomique, séquentielle, par époque. Valeur Ce package regroupe la classe VersionValeur, objet qui est transmit depuis le capteur vers les afficheurs Le fichier de configuration : «init.properties» Ce fichier de configuration contient des propriétés qui spécifient des valeurs propres au fonctionnement du projet. Ces valeurs sont accédées par l application au cours de son fonctionnement et lors de son initialisation. Pour mettre en œuvre ce mécanisme nous avons utilisé la classe Java «Properties» qui permet de lire un fichier contenant une liste de propriétés sous la forme «<clef> = <valeur>». Les valeurs enregistrées sont les suivantes : La fréquence d incrémentation : fréquence d incrémentation de la valeur à transmettre. La valeur initiale : valeur initiale au démarrage de l application. Identifiant algorithme atomique : identifiant de l algorithme atomique permettant de l identifier dans certaines fonctions. Identifiant algorithme séquentiel : identifiant de l algorithme séquentiel permettant de l identifier dans certaines fonctions. Identifiant algorithme par époque : identifiant de l algorithme par époque permettant de l identifier dans certaines fonctions. LEFRANC Pierre-François Page 7

8 Le dossier de JAVADOC : «javadoc» Ce dossier contient l intégralité de la JAVADOC générée pour cette application Les patrons de conception Nous allons maintenant détailler les patrons de conception présents dans notre application au travers d extrait du diagramme de classe de conception spécifique à la plateforme Java (PSM) Observer Description Le patron de conception «observer/subject» est utilisé en programmation pour envoyer un signal à des modules qui jouent le rôle d'observateurs. En cas de notification, les observateurs effectuent alors l'action adéquate en fonction des informations qui parviennent depuis les modules qu'ils observent (les «Subject») Mise en œuvre Figure 1 : Diagramme de classe du patron de conception Observer Nous avons utilisé ce patron de conception afin de mettre à jour les afficheurs lors d un changement de valeur du capteur. LEFRANC Pierre-François Page 8

9 Pour cela, lors d un changement, l algorithme de diffusion, qui joue le rôle de Proxy (cf. paragraphe 2.4.4) sur le capteur, met à jour ses observateurs via la méthode «update» afin que ces derniers lancent les traitements aboutissant à la mise à jour des valeurs affichées. Ce patron de conception définit des rôles : Le Subject : Ce rôle est joué par l interface «Subject» qui est étendue par les interfaces «Capteur» et «AlgoDiffusion». L Observer : Ce rôle est joué par l interface «Observer» qui est étendue par l interface «Afficheur». Notons que, dans cette présentation du patron de conception, nous ne détaillons pas les traitements réalisés pour la mise à jour des Afficheurs suite à la modification de la valeur du capteur. Nous aborderons cela dans la suite de ce rapport Command Description Le patron de conception Command permet de séparer complètement le code initiateur de l action à celui de l action elle-même. En outre, il offre la possibilité de manipuler l action en ellemême sous forme d un objet du langage Mise en œuvre Figure 2 : Diagramme de classe du patron de conception Command LEFRANC Pierre-François Page 9

10 Command est utilisé dans notre application au niveau de la modification des valeurs du capteur. En effet, ces modifications sont réalisées par notre classe «HorlogeImpl» qui est en fait un «Timer» Java. Cette classe est capable d exécuter des actions à intervalle de temps régulier. Nous avons donc réifié ce concept d action dans une commande qui est ensuite exécutée par l horloge via un appel périodique de la méthode «execute» chargée de l incrémentation des valeurs du capteur. Ce patron de conception définit des rôles : Le Receiver : Ce rôle est joué par les classes implémentant l interface «AlgoDiffusion». L Invoker : Ce rôle est joué par l «HorlogeImpl». La Command : Ce rôle est joué par les classes implémentant l interface «Command» Singleton Description Le patron de conception a pour but de limiter l instanciation d une classe à un seul objet et de la rendre accessible à toutes les classes de l application. Il est utilisé lorsque l'on a besoin d'exactement un objet pour coordonner des opérations dans un système. Le modèle est parfois utilisé pour son efficacité, car il permet de s assurer de la présence de peu d'objets dans des systèmes limités en mémoire ou performances Mise en œuvre Figure 3 : Le patron de conception singleton Nous avons utilisé ce patron afin d assurer l unicité de certains objets tels que l horloge, le fichier de configuration et le «Scheduler» du patron de conception Active Object qui sont des attributs de l instance unique de la classe «Materiel». Grâce à cela, l application accède à ces éléments depuis n importe laquelle de ses classes. LEFRANC Pierre-François Page 10

11 Proxy Description Un proxy est une classe se substituant à une autre. Par convention et simplicité, le proxy implémente la même interface que la classe à laquelle il se substitue. L'utilisation de proxy ajoute une indirection à l'utilisation de la classe à substituer Mise en œuvre Figure 4 : Le patron de conception proxy Dans notre application, nous avons utilisé quatre patrons proxy. Dans un premier temps, nous l avons appliqué deux fois sur la classe «CanalImpl» pour appliquer le patron de conception Active Object qui doit comporter un proxy. De plus, nous avons fait le choix de placer l algorithme de diffusion comme un proxy sur le capteur, pour la commande et le canal. Ce choix nous a paru opportun car il nous a notamment permis de contrôler les accès à la valeur du capteur lors de la mise en place des différents algorithmes de diffusion. Ce patron de conception définit plusieurs rôles : Le proxy : Il représente la classe qui vient se substituer à la classe que l on veut «masquer». Le component (et concrete component): Il représente la classe que l on veut «masquer» via le proxy. Le client : Il représente la classe qui veut accéder à l objet masqué par le proxy. LEFRANC Pierre-François Page 11

12 Strategy Description Le patron stratégie est un patron de conception de type comportemental grâce auquel des algorithmes peuvent être sélectionnés à la volée au cours de l'exécution selon certaines conditions. Il est particulièrement utile pour des situations où il est nécessaire de permuter dynamiquement les algorithmes utilisés dans une application Mise en œuvre Figure 5 : Le patron de conception strategy Le patron de conception «strategy» définit les rôles suivants : Le context : Il représente la classe qui fait appel aux algorithmes : la «CommandIncrementer». La strategy (et concrete strategy) : Elle représente la ou les classes contenant les corps des algorithmes que l on souhaite modifier dynamiquement : les classes implémentant l interface «AlgoDiffusion». Dans ce projet, nous devions définir trois stratégies de diffusion pour les valeurs du capteur (cf. paragraphe 2.2). Lorsque l horloge notifie l algorithme du besoin de modifier la valeur du capteur. Ce dernier est modifié et l algorithme de diffusion exécuté. LEFRANC Pierre-François Page 12

13 La mise en œuvre de ces algorithmes est la suivante : Algorithme de diffusion séquentielle : nous avons mis en place un mécanisme de copie de la valeur du capteur. C est cette copie qui est envoyée aux afficheurs quelque soit la valeur réelle du capteur. Ensuite, nous avons utilisé un entier qui stocke à tout moment le nombre de diffusions en cours. Tant qu il en existe une (i.e. tant que l entier ne vaut pas zéro), aucune nouvelle valeur n est envoyée aux canaux. Algorithme de diffusion atomique : nous avons mis en place un système similaire à la diffusion séquentielle au niveau de l entier indiquant le nombre de diffusions en cours. Cependant, cet algorithme nécessitant un blocage du capteur lorsqu une valeur est en cours de diffusion, nous avons fait un appel à la méthode «setetat» du capteur avec le paramètre «false» dans le but de le bloquer. Lorsque tous les afficheurs ont obtenu la valeur, le capteur est débloqué, se modifie, et l opération est répétée. Algorithme de diffusion par époque : nous avons mis en place un objet stockant la valeur du capteur et lui associant une version (un entier). Plus cet entier est élevé, plus la version de la valeur est récente. Concernant la diffusion proprement dite, cet algorithme n a aucune contrainte : les valeurs sont envoyées aux afficheurs anarchiquement et à chaque modification du capteur Active Object Description Le patron de conception Active Object permet de découpler les méthodes d'exécution des méthodes d invocation pour améliorer la concurrence et simplifier l'accès synchronisé d un objet qui réside dans son propre thread de contrôle. Le principe est de pouvoir faire communiquer les objets entre eux de manières à ce que les messages échangés soient asynchrones. Sa grande force est de permettre au développeur de limiter la programmation parallèle classique, à l aide de «Threads» Java par exemple. En effet, ce patron de conception est capable de gérer de manière automatique les actions asynchrones sans que le développeur n ait à se soucier des éventuels problèmes de synchronisation et d accès concurrent sur une même variable. Il en résulte que l ordre d'exécution de méthodes peut différer de leur ordre d invocation par exemple Mise en œuvre Dans notre projet, nous avons choisi d utiliser une implémentation du patron de conception fournie par Sun dans la bibliothèque Java standard. Cette mise en œuvre dispose d un planificateur intégré (le «Scheduler») et se révèle être très performante. LEFRANC Pierre-François Page 13

14 Figure 6 : Structure statique du patron de conception Active Object Ce patron de conception définit plusieurs rôles : Client : Dans notre application, le patron est utilisé deux fois (une fois pour l appel de la «Method Invocation update» et une fois pour l apelle de la «Method Invocation getvalue») et certaines classes n ont pas le même rôle selon le cas. Ainsi, les classes implémentant l interface «AlgoDiffusion» et celles implémentant «Afficheur» sont les «Client». Servant : Ce sont les classes qui mettent en œuvre les services appelés lors de l exécution des «Method Invocation», c'est-à-dire celles implémentant «AlgoDiffusion» et «Afficheur». Future : Ce rôle est géré par la bibliothèque standard Java. Il représente l objet retourné après l appel des services par les «Method Invocation» Scheduler : Il planifie l appel des «Method Invocation» de manière asynchrone, c est la classe «Scheduler» dans notre cas. Activation Queue : Ce rôle est géré par la bibliothèque standard Java, c est la file d attente où sont placées les «Method Invocation» avant leur appel. Method Invocation : Le concept de méthode est encapsulé dans un objet qui représente les «Method Invocation» du patron. Elles sont chargées de réaliser l appel du service à leur exécution via leur méthode «Call». Ce rôle est joué par les classes implémentant l interface «Method Invocation» de notre implémentation. Proxy : Un proxy standard, ce rôle est joué par les classes implémentant l interface «Canal». LEFRANC Pierre-François Page 14

15 Figure 7 : Notre mise en œuvre d'active Object On remarque que nous avons fait le choix d associer le «Scheduler» à notre patron de conception singleton (cf. paragraphe 2.4.3). Comme indiqué sur cette figure, la gestion de l «Activation Queue» et des «Futures» est réalisée par la bibliothèque Java fournie par Sun. LEFRANC Pierre-François Page 15

16 2.5. Le diagramme de conception : Plateform Independant Model Figure 8 : Diagramme de classe du PIM Le «Platform Independent Model» aussi appelé PIM constitue un modèle UML d'analyse de l'application possédant les caractéristiques suivantes : Complet fonctionnellement Indépendant de la cible technique Validé par simulation LEFRANC Pierre-François Page 16

17 2.6. Le diagramme de conception : Plateform Specific Model Figure 9 : Diagramme de classe du PSM Le «Platform Specific Model», aussi appelé PSM représente un modèle de conception détaillée de l'application. Il possède les caractéristiques suivantes : Dépendant de la cible technique (langages de programmation et OS notamment) Généré depuis le PIM (cf. paragraphe 2.5), par des règles de transformation spécifiques à une plateforme cible. LEFRANC Pierre-François Page 17

18 2.7. Diagramme de séquence de notre implémentation Du fait que cette page ne soit pas très lisible, nous vous joignons l image originale (diag_sequence.jpg) dans le rendu de notre projet. LEFRANC Pierre-François Page 18

19 2.8. Tests et validation Après la phase de conception, nous nous sommes lancés dans le développement de l application. Cette phase est relativement courte puisque le travail d analyse et de conception permettent de guider pas à pas les développements. Une fois ces développements terminés, nous avons débuté la phase de tests de notre application Politique de test Pour réaliser la phase de tests, nous nous sommes orientés, dans un premier temps vers une relecture du code, c'est-à-dire une approche «boite blanche». Cette relecture nous a, dans un premier temps, permis d alléger notre code et de factoriser des traitements. Grâce à ces tests, nous avons pu vérifier que chacun de nos composants Java jouait le rôle que nous voulions qu il joue. Cette première étape de test nous a donc servi de point d entrée dans notre phase de tests. Dans un second temps, nous nous sommes orientés vers des tests visuels. En effet, les traitements Active Object sont réalisés par les classes de la librairie Java (ScheduledExecutorService et Callable). Il en est de même pour l Horloge qui étend un timer Java Interface graphique pour les tests Dans le but de s assurer du bon fonctionnement des classes métiers, nous avons conçu une IHM utilisant les librairies SWING. Cette dernière permet : de s assurer du bon fonctionnement de l horloge grâce à l affichage de la valeur du capteur, de voir la latence des canaux, de tester les différents algorithmes de diffusion, de s assurer que les afficheurs respectent les spécifications énoncées paragraphe 2.2. LEFRANC Pierre-François Page 19

20 Figure 10 : Présentation de notre interface utilisateur Résultat des tests Après plusieurs séries de tests, l application est totalement fonctionnelle et respecte les spécifications demandées. 3. Difficultés rencontrées Les principales difficultés rencontrées sur le projet son intervenues lors des phases d analye. En effet, cette phase est la plus importante dans tout projet informatique et peut parfois représenter plus de 50% du temps passé. Dans un premier temps, il nous a fallu saisir les différentes subtilités des algorithmes de diffusion pour ensuite pouvoir les formaliser dans le langage Java. Ensuite, nous avons mis en place les différents patrons de conception et avons dû nous attacher à bien repérer leur rôle dans le projet. Pour ce qui est des patrons de conception Observer, Proxy, Singleton, Command, Strategy, leur mise en œuvre nous est apparue naturelle grâce, notamment, aux travaux réalisés dans le module d AOC. Concernant Active Object, il nous a fallu nous documenter et analyser son fonctionnement au travers de multiples diagrammes de séquences. En outre, nous avons dû étudier les implémentations proposées dans la librairie Java standard dans le but de sélectionner la plus adaptée à notre projet. Une fois ces difficultés dépassées, les phases de développements et de tests ont été réalisées sans véritables difficultés. LEFRANC Pierre-François Page 20

21 4. Conclusion du projet Ce projet qui intervient dans notre dernière année de Master Informatique a renforcé notre vision et notre compréhension des patrons de conception, notamment par la découverte du patron Active Object. La réalisation de ce projet fait suite à la réalisation, en Master 2, d un métronome. Nous avons donc pu réutiliser une méthodologie de travail acquise au premier semestre en améliorant cette dernière. Ces améliorations sont passées par la rédaction d un solide livret de conception qui a optimisé le temps de développement et de tests de l application. Au cours du projet, nous avons pu mettre en œuvre la méthode de programmation dite du «cycle en V» que nous aurons à utiliser au cours de notre stage de fin d études. Cette dernière s est d ailleurs fortement rapprochée de ce qui se fait dans le monde professionnel. En outre, au travers de l analyse, la conception, le développement et la validation d une application simple, nous avons mis en place quelques patrons de conception parmi les nombreux existants. Cependant, le réel objectif était de comprendre et maitrisé un nouveau patron : Active Object. Ce dernier nous est apparu plus complexe que les autres du fait qu il définisse un grand nombre de rôles (cf. paragraphe 2.4.6). Au final, nous avons correctement implémenté Active Object, ce qui nous a permis de gérer le parallélisme de manière beaucoup moins fastidieuse qu en usant de méthodes vues dans notre cursus : les Threads. Pour conclure, ce projet de TAO a été pour nous une véritable ouverture sur le monde de la programmation parallèle, monde qui représente certainement l avenir du développement en tirant parti des architectures multi-cœurs. LEFRANC Pierre-François Page 21