wiki:Diagramme

AREVIINTERACTOR


Diagramme UML

Voici comment nous avons réalisé notre bibliothèque AReViIntercator. Cette représentation tient compte des différents spécifications fonctionnelles ainsi que des choix que nous avons fait par rapport au cahier des charges. Spécifications Fonctionnelles


Représentation d'un périphérique

Nous avons réalisé une classe Périphérique, contenant un identifiant _id sous forme d'un entier généré automatiquement grâce à la variable _number qui est static et qui s'incrémente à la création de chaque Peripherique, l'identifiant du périphérique physique _serialNumber sous forme d'une chaine de caractères, un type _type sous forme d'une chaîne de caractère, un flag permettant de savoir si le périphérique est utilisé _used sous forme d'un booléen et une liste d'actionneurs _actuator qui sont de la classe Actuator. La méthode update() permet à la classe Peripherique de demander à tous ses Actuator de faire leur mise à jour (méthode update() dans la classe Actuator).

La classe Actuator est abstraite car nos actionneurs peuvent être des boutons, des axes mais aussi des boutons virtuels ou des axes virtuels. Il faut donc que chacun des actionneurs fasse leurs mises à jour selon leur type. Mais tous ces actionneurs ont un nom représenté par la variable _name et sont soient stables soient instables, c'est pourquoi nous avons fait une variable _stable qui est un booléen.
Les axes sont représentés par la classe Axis, qui comprend deux valeurs _value et _oldValue, qui représentent la position sur l'axe à un instant donné et celle à l'instant d'avant, il y a aussi deux bornes, représentées par la classe Borne, qui sont utilisées pour les axes bornées. Lors d'une mise à jour des valeurs de l'axe, la méthode valueChanged(), qui permet de savoir si la nouvelle valeur de l'axe est différente de l'ancienne, est appelée.
Les boutons sont eux représenté grâce à leurs états : _state. Lors d'une mise à jour de l'état, la méthode _update() vérifie si l'état actuel du bouton est le même que celui stocké dans notre variable, si ce n'est pas le cas alors _state est mis à jour.

Nous avons aussi créé les classe VirtualAxis et VirtualButton, qui représente des axes ou boutons virtuels. Par exemple, lors de l'étude du P5Glove, nous avons vu que les doigts du gant, qui sont des axes, sont utilisés comme des boutons : c'est ce que nous appelons des VirtualButton. De même pour les VirtualAxis, qui sont des boutons qui sont utilisés pour se déplacer sur des axes, par exemple les touches directionnelles sur un clavier. Dans notre application nous n'avons pas utilisé ces classes, mais elles seront utiles pour continuer ce projet.


Création et gestion d'évènements

Les évènements sont créés par les actionneurs lors d'une mise à jour ( update() ) si les valeurs de leurs paramètres ont changé. Les axes font appellent à la méthode createAxisEvent() et les boutons à la méthode createButtonEvent().

Les Event contiennent un identifiant _id, qui est généré automatiquement grâce à la variable _number qui est static et qui s'incrémente à la création de chaque évènement. Le _peripheriqueId et le _peripheriqueType, nous renseigne sur le périphérique auquel appartient l'évènement. _user et _date nous permettent de savoir quel est l'utilisateur qui a utilisé le périphérique et donc créé l'évènement et quand est ce qu'il a été créé. Pour savoir à quel type d'évènement nous avons à faire, nous utilisons la variable _type, qui est une énumération de type TypeEvt. Les types d'évènements sont les suivants : DISCONNECT, CONNECT, BUTTON_CHANGE, AXIS_CHANGE.
Les classes AxisEvent et ButtonEvent spécialisent la classe Event en y ajoutant les informations utiles contenues dans les classes Axis et Button (les états et les valeurs).

Lors de cette création, les évènements sont ajoutés à l'EventManager, grâce à la méthode addEvent() dans celui-ci. L'EventManager va permettre de gérer ces évènements, ils sont stockés dans une liste.

L'EventManager connait tous les Périphériques et leurs évènements et il les gère en demandant un update général avec sa methode peripheriqueLoop, en les ajoutant et en les retirant de sa liste une fois qu'ils on était donnée à la simulation.


Communication entre la bibliothèque et la simulation

La communication entre la bibliothèque et la simulation se fait grâce à la classe EventManager. Tous les périphériques utilisés par la simulation sont stockés dans celle-ci ainsi que tous les évènements envoyés par ces périphériques. C'est la simulation qui va aller chercher dans l'EventManager les évènements du périphérique dont elle a besoin.
Nous avons mis sur le diagramme une classe Subcriber et une classe Filtre que nous n'avons pas utilisées, mais cela va permettre par la suite aux personnes continuant le projet d'utiliser un filtre permettant d'envoyer à la simulation seulement les évènements dont elle aura besoin.

La classe PeripheriqueManager n'est pas utiliser pour le moment, mais elle servira à ce que la simulation fasse connaître à la bibliothèque les périphériques dont elle a besoin en changeant la variable _used de Peripherique. Elle va aussi permettre à la simulation de connaître les utilisateurs. On pourra ainsi lier un utilisateur à un périphérique et savoir les actions qu'il a fait avec.


Utilisation de la librairie

Pour utiliser la librairie il faut ajouter dans vos configurations :

 export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$HOME/Dev/trunk/AReViInteractor/lib/

Retour au Wiki

Attachments