Conclusion
Tout le long de ce chapitre, nous avons
listé les besoins fonctionnels et non fonctionnels de notre projet
accompagnés de diagrammes des cas d'utilisations. Nous allons
détailler dans le chapitre suivant la conception de notre application
à travers a les diagrammes de séquences, les diagrammes
d'état transition ainsi que les diagrammes de classes.
Chapitre 5: Conception
Introduction:
Dans ce chapitre, nous allons présenter les diagrammes de
séquences qui décrivent les services du protocole
GPSR et surtout les services de la couche réseau. De
plus, nous allons présenter les différentes classes utiles pour
la partie implémentation.
1. Diagrammes de séquences
Diagramme d'interaction qui représente
les objets participant à une interaction particulière et les
messages qu'ils échangent organisé en séquences horaires.
Axé sur ce que fait un système et non sur la manière dont
il le fait, un diagramme de séquence définit la Logique d'une
instance particulière d'un CAS d'utilisation. En général,
dans un diagramme de séquence, la Dimension verticale représente
les heures (de haut en bas) et la Dimension horizontale représente les
différents objets.
1.1. Diagramme de séquences : Le scénario
de simulation
Figure 5.1. : Diagramme de
séquences : Le scénario de simulation
1.2.
Diagramme de séquences : Traitement lors de
réception d'un beacon
Figure
5.2. : Diagramme de séquences : Traitement lors de
réception d'un beacon
Lors de la réception du paquet beacon, une mise
à jour de la table de routage sera effectuée, Ces mises à
jour régulières permettent de communiquer les modifications de
topologie .Si le temps est dépassé et le noeud réceptrice
ne reçoit pas le beacon du noeud enregistré dans la table de
routage alors ce dernier sera supprimé.
1.3. Diagramme de
séquences : émission d'un message
à partir de la couche Application
Figure 5.3. : Diagramme de
séquences : émission d'un message à partir de la
couche Application
Ce diagramme explique les étapes à franchir pour
envoyer un message de données à partir du noeud local vers une
autre destinataire.
En premier temps, la couche application crée le
message, à ce qui concerne les données à transmettre et le
noeud destinataire .Puis l'interface supérieur passe le message au
Greedy mode pour déterminer s'il y a une possibilité pour le
transférer au plus proche voisin. Après un calcule de distance
séparant le noeud local avec l'ensemble de ses voisins deux cas
s'opposent :
ü Un transfert possible avec le Greedy
mode (il ya un voisin plus proche que les autres)
ü Il n y a pas un voisin a l'apporté qui le plus
proche voisin alors on doit passer au Perimeter mode.
A ce qui concerne le premier cas on termine par encapsuler le
message dans interface inferieure et puis son envoi.
Dans le deuxième cas, il se déroule l'algorithme
du perimeter mode .En effet, le module Perimetre mode consulte
la liste des voisins du table de routage et en utilisant la règle de la
main droite détermine le noeud prochain .Puis, il se déroule
l'encapsulation et l'envoi.
1.4. Diagramme de séquence : le traitement
d'un paquet de données lors de la réception
Figure 5.4. : Diagramme de
séquences : le traitement d'un paquet de données lors de la
réception
Ce diagramme de séquence décrit l'ensemble des
traitements effectués lors de la réception d'un paquet de
données. Après la décapsulation du paquet, l'interface
inferieur identifie le type de message reçu.
Ø Si c'est un Greedy-mode message, il va être
passé au Greedy-Mode. Après, une comparaison
entre l'adresse de la destination et l'adresse du noeud locale deux cas
possibles. Si le noeud locale est la destination, le message va être
repassé à l'interface supérieur puis à la couche
application. Sinon ,on va appliquer l'algorithme du Greedy-MODE en
déterminant le plus proche voisin dont on va lui transmettre le message
,en se basant sur la liste de voisin du Table du Routage.
Dans le cas ou on ne peut pas déterminer le plus proche voisin, on passe
à l'algorithme du Perimetre-MODE.
Si c'est un Perimetre-mode message, on fera le même
traitement si le message atteint la destination, sinon il y'aura d'abord, un
essai d'envoi en utilisant le Greedy-Mode. Dans le cas ou on ne peut pas
transmettre ce message avec l'algorithme du Greedy-Mode, le message va
être retransmis au noeud voisin en utilisant la règle de la main
droite.
2. Diagramme d'état transition:
2.1. Algorithme Greedy mode:
Figure 5.5. Diagramme
d'état transition pour greedy mode
2.2. Algorithme Perimeter mode:
Figure 5.6. Diagramme
d'état transition pour perimeter mode
Comme l'indique le figure 5.5, à
l'arrivé d'un paquet de donnée le Greedy-Mode vérifie si
le noeud local est la destination ou bien non. Si c'est la destination, le
paquet passera à la réception. Sinon le Greedy-Mode va effectuer
un relaie de ce paquet. Alors, il détermine le plus proche voisin qui
devrait être unique. Dans le cas d'un échec, il passera au
Perimetre-Mode décrit par le diagramme d'état de la figure
5.6. En effet, Perimetre-Mode applique la règle de la main droite
pour retransmettre le message. D'ailleurs, l'algorithme de la main droite
détermine le noeud adéquate en utilisant un calcule d'angle ayant
comme sommet le noeud locale, comme première arrête celle
formé par le noeud local et le noeud destination et comme
deuxième arrête le noeud locale et le noeud voisin.
3. Diagramme de classe :
Figure 5.7. Diagramme de classe
global
ü Interprétation des composants du
diagramme de classe :
· BasicLayer: c'est une classe
offerte par la Mobility FrameWork. Elle offre une abtraction simple permettant
de développer une couche réseau ou une couche MAC. Elle offre les
fonctionnalités de bases dont ont besoin les couches réseaux et
MAC comme le handlemessage() et le handleselfmessage() nécessaires aux
traitements des paquets.
· GPSRnetwLayer: c'est une
classe qui hérite de BasicLayer. Elle correspond au module simple
GPSRnetwLayer et constitue la couche réseau du noeud. Cette couche a
été implémentée selon la spécification du
protocole GPSR. Parmi les paramètres de cette classe on peut citer le
headerlength qui spécifie la longueur de l'entête du paquet et le
mynetwaddr qui est l'adresse réseau du noeud.
· BasicAppLayer: c'est une
classe offerte par la Mobility FrameWork. Elle est la classe
générique dont héritent toutes les couches applicatives
développées sous la Mobility FrameWork.
· ApplicationLayer: c'est une
classe héritée à partir de la BasicAppLayer. C'est une
couche applicative qui se contente d'envoyer des messages qui seront
encapsulés et routés par la GPSRnetwLayer.
· Cmessage: c'est une classe
offerte par OMNet++. Elle représente des messages, des paquets et
même des évènements. La plupart des messages et paquets
implémentés dans OMNet++ héritent de cette classe.
· GPSRPKT: c'est une classe qui
hérite de cmessage. Elle représente le paquet utilisé par
GPSRnetwLayer avec ses spécificités.
| 
