Conception : Un peu de conception pour commencer

Un peu de conception avant de commencer. L'idée n'étant pas de détailler au maximum le système (quelque chose rendu obsolète au bout de 2 jours), mais au contraire de poser quelques bases de départ.


Je récupère une version 30 jours d'essai d'Enterprise Architect (Logiciel de modélisation : UML Compliant)


Après quelques clics, un premier modèle de classes apparait  :

Notre serveur Web aura un servlet de démarrage qu'on appelera StartupServlet qui étend Servlet.
Ce dernier aura pour rôle de démarrer tous les managers, nous nommerons Managers les classes surveillant l'outil (Ex: AlarmeManager, SystemManager, )
Ces managers seront intégrés dans le package managers.


Ps: il sera possible par la suite d'intégrer d'autres managers au moyen de plugin.


Tous les managers hériteront d'un abstractManager mettant à disposition plusieurs méthodes d'accès aux futures Unités, Médiateurs, Journal de bord ou autres objets. La méthode run() est concrète, ne fera que boucler indéfiniment sur doTraitement() qui elle est abstraite, obligeant ainsi ces fils à l'implémenter concrètement. Un manager est unique au sein de la JVM, utilisation du Design Pattern Singleton, on accèdera à ce manager à l'aide de son nom de classe puis getInstance();

A noter que le démarrage des managers se fait en asynchrone, un manager sera assimilé à un thread (méthodes fournies par l'abstract)

Tout ça, c'est bien beau, mais nos Managers vont devoir manipuler des objets ou faire interagir des objets entre eux.


Qui dit objet, dit donc objet physiquement existant (bon quelques abstract permettront de s'affranchir de quelques méthodes ou attributs redondant). Mais le principe reste le même.


On trouvera donc dans notre système 2 types d'objets :


                1) Les unités : unités physiques domotiques, un capteur, une sonde, un interrupteur, un composant électronique, .... 
                On trouvera comme exemple : une sonde OREGON THN132, un AW12 X10, un Carillon Chacon, ....


                2) Les médiateurs (objet assurant la communication entre les unités et ce que j'appelle le support de transmission (Radio 433Mhz, CPL, infrarouge, optique , ....). Ex de médiateurs que l'on utilisera : RFXCOM Ethernet, CM15USB, Arduino Ethernet, ...)
       
Chaque médiateurs connait exactement la liste de ses unités gérées. Par contre pour des raisons de redondance cyclique, les unités ne voient pas leur médiateurs.


L'AbstractMediator fournira des SerialStreamReader (Lecture sur port série) ou HttpReader (Reader sur Http) ou encore NetworkReader (Lecture sur socket ip) ou usb, afin de faciliter les lectures/écritures au sein du support de transmission.

Quelques méthodes : 
        
        addUnit, Ajoute une unité dans le médiator.
        removeUnit , supprime une unité du médiator.
        onMessageReceive, le décodage du message reçu.
        onMessageSend, en cas de transmission de message
        messageToUnit, routage du message reçu vers la bonne unit !
        reset, et oui tout arrive, il faudra parfois "reseter" notre médiator, s'il se sent pas bien :(.
        
        dans les utilitaires d'accès (Serial, Socket, et interface USB qu'on implémentera en fonction des librairies dispo sous linux ou windows (d'où l'interface).


       Exemple ici d'un RFXCOM en ethernet.


Pour les unités, on retrouve le même principe, une abstract permettant de préciser les attributs commun et par dérivation une classe par type d'objet avec ses attributs qui lui sont propre : 

Vouala, pour cette première partie de conception, on y reviendra plus tard.