Rapport final de projet
Simulation d’un réseau Token Ring!
Préparé sous la direction de M. Miara Présenté par Erwan Charlier et Grégory Denize
Année Universitaire 2004 - 2005
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
Remerciements Nous tenons à remercier notre tuteur de projet, Monsieur André Miara, qui nous a guidé et orienté durant l’élaboration de notre projet. Nous souhaitons remercier aussi, Laurent Pasqualini et Jonathan Simeone, deux étudiants de notre classe, qui nous ont éclairé sur certains problèmes rencontrés en Delphi à la lumière de leur expérience.
Remerciements
Page 3 sur 82
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
Sommaire GLOSSAIRE ...................................................................................................................................5 TABLE DES FIGURES ET DES TABLEAUX..........................................................................13 1.
INTRODUCTION .................................................................................................................14
2.
PRESENTATION DU PROTOCOLE IEEE 802.5 ............................................................15 2.1. 2.2. 2.3. 2.4.
3.
PRINCIPE D'ECHANGE DU JETON ........................................................................................15 COMPOSITION DE LA TRAME .............................................................................................16 LA SUPERVISION DU RESEAU ............................................................................................17 HISTORIQUE DU TOKEN RING!. ......................................................................................18
MATERIELS ET METHODES...........................................................................................19 3.1. SITUATION DE DEPART......................................................................................................19 3.2. BESOINS DE L’UTILISATEUR ..............................................................................................19 3.3. CLARIFICATION DES BESOINS ...........................................................................................20 3.4. DEFINITION DES FONCTIONNALITES ..................................................................................20 3.5. DEFINITION DES EXIGENCES A RESPECTER ........................................................................22 3.6. SOLUTIONS POSSIBLES POUR ATTEINDRE LES OBJECTIFS ..................................................23 3.6.1. Animation Flash en ActionScript .............................................................................23 3.6.2. Développement en Java ...........................................................................................23 3.6.3. Développement en Pascal avec Delphi ....................................................................23 3.7. OUTILS ET METHODES POUR LA SOLUTION CHOISIE ..........................................................24 3.7.1. Choix d’une méthode d’analyse ...............................................................................24 3.7.2. Choix du langage .....................................................................................................24 3.8. LES DIFFERENTES ETAPES DE REALISATION ......................................................................26 3.9. LES PHASES DU DEVELOPPEMENT .....................................................................................29 3.9.1. Classes et Types .......................................................................................................29 3.9.2. Précisions sur les algorithmes employés et sur le fonctionnement général .............34
4.
RESULTATS .........................................................................................................................36 4.1. 4.2. 4.3. 4.4. 4.5.
LE MODE ANIMATION .......................................................................................................36 LE MODE PAS A PAS ..........................................................................................................37 LE MODE TEMPS REEL .......................................................................................................38 LES MACHINES..................................................................................................................39 LA TRAME ........................................................................................................................40
5.
DISCUSSION.........................................................................................................................41
6.
CONCLUSION ......................................................................................................................42
ANNEXES......................................................................................................................................43 A.
BIBLIOGRAPHIE ..................................................................................................................43 Articles & revues : .................................................................................................................43 Articles de livres :..................................................................................................................43 Document électronique..........................................................................................................43 B. DOSSIER D’ANALYSE ..........................................................................................................44 Diagramme des Use Case......................................................................................................44 Diagramme de Classes ..........................................................................................................45 C. DOSSIER DE PROGRAMMATION ...........................................................................................47 Classe TMachine ...................................................................................................................47 Classe TMoniteur ..................................................................................................................59 Classe Reseau ........................................................................................................................63 Classe Trame .........................................................................................................................71 D. SCHEMAS LEGENDES DES COMPOSANTS PRESENTS DANS LES FENETRES .............................77 E. CARNET DE SUIVI DU PROJET ...............................................................................................80
Sommaire
Page 4 sur 82
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
Glossaire
A ! ANSI (Acronyme, Anglais : American National Standards Institute) Fondé en 1918, organisme composé de plus de 1300 membres chargés d'officialiser les standards informatiques. ANSI C par exemple est une version du C qui a été approuvée par l'ANSI.
B ! Bit (Acronyme, anglais : contraction de Binary Digit) [SYST.] C'est l'unité binaire de quantité d'information qui peut représenter deux valeurs distinctes : 0 ou 1.
D ! Delphi [PROG.] Programme de développement de chez Borland, basé sur le Pascal et adapté pour une programmation événementielle.
Glossaire
Page 5 sur 82
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
E ! Ergonomie (n. f., Anglais : Ergonomics) Étude de la facilité et de la souplesse d'utilisation d'un système, ainsi que de sa bonne adaptation aux objectifs recherchés, en tenant compte du bien-être de l'utilisateur. Souvent utilisé en tant que mesure de ces qualités. Celui qui s'en occupe est un ergonome. En informatique elle concerne aussi bien le matériel (écran pivotant, inclinable, agréable, sans clignotement, clavier à teinte matte, à touches bien disposées, ordinateur rapide et silencieux...) que le logiciel (productif, bien conçu et adapté à la tâche, mode d'emploi intuitif, avec aide en ligne contextuelle...) qui doit être en adéquation avec le mode de travail des utilisateurs et les objectifs de l'entreprise. Elle intervient donc avant la conception logicielle d'un produit. Pour les interfaces graphiques, Macintosh ou Windows, elle comporte trois principes de base : cohérence entre les différentes applications, sobriété, élégance. Ce néologisme daterait de 1949.
F ! FDDI (Acronyme, Anglais : Fiber Distributed Data Interface) [COMM.] Norme ANSI pour les réseaux locaux rapides à 100 Mb/s. ! Flash Logiciel souvent utilisé pour la création de pages web. Il permet de construire des animations vectorielles complexes tout en limitant le temps de chargement des fichiers.
Glossaire
Page 6 sur 82
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
I ! IBM (Acronyme, Anglais : International Business Machines) Société fondée en 1924 par Thomas Watson Sr, dite "Big Blue" en référence au costume bleu de ses cadres, fabricant d'ordinateurs, a lancé en 1981 le premier PC équipé de Microsoft MS-Dos. ! IEEE (Acronyme /I-3-E/, Anglais : Institute of Electrical and Electronic Engineers) Organisme américain de normalisation.
J ! Java [PROG.] Langage de développement, produit par la société Sun et lancé le 23 mai 1995. Ecrit par James Gosling, il permet de créer des applications autonomes et de doter les documents html de nouvelles fonctionnalités : animations interactives, applications intégrées, modèles 3D, etc. Ce langage est orienté objet et comprend des éléments spécialement conçus pour la création d'applications multimédia. On écrit un programme java dans un texte source qui ressemble à C (langage) ou à C++, puis on le traduit à l'aide d'un compilateur afin de générer un programme utilisable directement dans une page html et appelé applet. Pour exécuter ensuite un applet, l'utilisateur doit disposer d'une machine virtuelle. Un applet est inclus sous forme de document html ou sous forme de hyperlink. Son nom officiel est HotJava et son logotype une tasse de café fumante. En argot américain, ce substantif désigne depuis longtemps le café (tout comme chez nous le « Kawa » arabe devenu « caoua ») ; selon l'American Slang de Robert L. Chapman, terme datant du milieu des années 1800, provenant du nom de l'île de Java d'où le café était exporté
Glossaire
Page 7 sur 82
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
L ! L4G Langage de 4eme génération. Langage de programmation de haut niveau conceptuel permettant une programmation rapide et efficace, ce type de langage est souvent utilisé pour l'interrogation de bases de données. ! Langage orienté objet (Anglais : object oriented language) Type de langage adapté à la programmation par objets. On distingue trois catégories de langages orientés objets : les langages de classes, les langages de cadres et les langages d'acteurs. ! Liste (n. f.) [PROG.] Structure de données classique, analogue à un tableau, mais en plus souple. Une liste se compose d'un premier élément appelé « Tête », et d'une liste formée du reste de ses éléments appelée « Queue ». La liste est dite « chaînée » quand elle contient des pointeurs vers d'autres listes ou vers elle-même.
M ! MAC (Acronyme, Anglais : Media Access Control) [COMM.] Part du modèle de données IEEE d'un réseau. La couche MAC implémente le protocole qui contrôle l'accès au réseau. Un MAC Ethernet utilise une méthode d'accès CSMA/CD. Un MAC Token Ring utilise une méthode d'accès Token.
Glossaire
Page 8 sur 82
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
! Manchester [COMM.] Méthode de codage d'un signal numérique, dans laquelle chaque bit est représenté par une transition : pour coder un 0 on passe de l'état « haut » à l'état « bas », et on fait l'inverse pour coder un 1. Le code de Manchester est dit « Différentiel » quand il y a un changement de polarité pour coder un 0 et pas de changement de polarité pour coder un 1, mais toujours une transition par bit. ! MERISE (Acronyme, Français : Méthode d'Etude et de Réalisation Informatique pour les Systèmes d'Entreprise) Acronyme désignant une méthode d'analyse, de conception et de développement de systèmes d'information. Autrement dit, MERISE propose une méthodologie pour la réalisation et la conduite de projets informatiques. ! Modula 2 Langage conçu en 1979 par Niklaus Wirth comme un langage devant combler les manques du Pascal, ce langage est surtout utilisé dans les universités.
O ! Octect (n. m. Anglais : Byte) [SYST.] Champ constitué de 8 bits. ! OSI (Acronyme, Anglais : Open Systems Interconnection) [COMM.] Architecture à 7 couches qui normalise les niveaux de service et les types d'interactions entre les ordinateurs qui échangent des informations à travers un réseau. Elle décrit le flux des données entre la connexion physique et le réseau d'une part et le programme de l'utilisateur final d'autre part.
Glossaire
Page 9 sur 82
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
P ! Pascal (n.m.) [PROG.] Langage créé en 1969 par le suisse Niklaus Wirth pour enseigner la programmation facilement, il a été appelé ainsi en l'honneur de Blaise Pascal, pour répondre aux critiques faites au Pascal son concepteur a créé un nouveau langage nommé Modula 2. ! Protocole (Anglais : Protocol). Description des formats de messages et règles selon lesquelles deux ordinateurs échangeront des données. Les protocoles décrivent également les détails de bas niveau sur la façon dont deux machines communiquent ou des échanges de haut niveau entre deux programmes.
R ! Réseau (n.m., Anglais : Network) Il permet la transmission de tout type de données, échangée sous forme numérique et exploitable par l'ensemble du système relié en réseau. Un réseau informatique peut être local (sa taille est relativement réduite et il relie, le plus souvent grâce à des câbles, plusieurs ordinateurs et périphériques à l'intérieur d'une entreprise) ou élargi (réseau longue distance). Pour administrer un réseau, un ou plusieurs ordinateurs ont le rôle de serveur.
Glossaire
Page 10 sur 82
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
S ! Sémaphore (n. m. Anglais : Semaphore) [PROG] Objet permettant de limiter l'accès à une ressource partagée par plusieurs threads.
T ! Tâche (n.f. Anglais : Thread) [PROG] Processus léger, correspondant à l'exécution d'un petit programme, ou d'une routine d'un programme plus gros, indépendamment de celui-ci (on parle alors de multithread). ! Token Ring! [COMM.] Définit les caractéristiques d'un réseau en relation avec la sous-couche MAC (OSI "liaison") et la couche OSI "physique" qui utilise une méthode de contention à jeton (token) sur une topologie en anneau.
Glossaire
Page 11 sur 82
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
U ! UML (Acronyme, Anglais : Unified Modelling Language) L'UML est le concept de modélisation objet. Son développement a débuté en 1994 et il a été normalisé par l'OMG début 1997. Grady Booch et Jim Rumbaugh ont décidé de travailler ensemble pour réaliser une unification des anciennes méthodes à objet. La méthode UML est très intuitive, plus simple et plus cohérente que les autres méthodes. Elle simplifie le processus complexe de conception d'un système informatique en définissant 9 points de vue (ou diagrammes) de modélisation .
Glossaire
Page 12 sur 82
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
Table des figures et des tableaux figure 1. figure 2. figure 3. figure 4. figure 5. figure 6. figure 7. figure 8. figure 9. figure 10. figure 11. figure 12. figure 13. figure 14. figure 15. figure 16. figure 17. figure 18. figure 19. figure 20. figure 21. figure 22. figure 23. figure 24. figure 25. figure 26.
Schéma d'émission de données avec un jeton. .....................................15 Composition d'une trame......................................................................16 Use Case des besoins utilisateurs. ........................................................19 Capture d’écran du Test Graphique .....................................................26 Capture d’écran de la Base opérationnelle...........................................27 Capture d’écran de l’Objectif n°1 ........................................................27 Capture d’écran de la version finale du logiciel...................................28 Diagramme de classe dans sa première version ...................................29 Fenêtre de contrôle d’une Machine......................................................30 Diagramme de classe de TMoniteur héritant de TMachine ...............31 Fenêtre de contrôle du Moniteur ........................................................31 Schéma de fonctionnement de la classe Réseau ................................32 Fenêtre avec indicateurs d’acheminement du message......................34 Capture d’écran de la fenêtre principale en mode Animation............36 Capture d’écran de la fenêtre principale en mode pas à pas ..............37 Capture d’écran de la fenêtre principale en mode Temps Réel..........38 Capture d’écran d’une fenêtre de contrôle Machine et Moniteur ......39 Capture d’écran de la fenêtre de contrôle de la Trame ......................40 Diagramme des Use Cases (Cas d’utilisation) ...................................44 Diagramme de classes sans la fenêtre principale ...............................45 Diagramme de classe de la fenêtre principale....................................46 Schéma légendé d’une fenetre d’une Machine ..................................77 Schéma légendé de la fenêtre de contrôle de la Trame ......................77 Schéma légendé du mode Animation.................................................78 Schéma légendé du mode Pas à pas ...................................................78 Schéma légendé du mode Temps Réel...............................................79
Table des figures et des tableaux
Page 13 sur 82
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
1. Introduction Dans le cadre de notre Diplôme Universitaire de Technologie en Informatique, nous devions réaliser un projet dont le thème est à choisir parmi ceux proposés par les enseignants du Département. Concernant le choix du sujet, il a fallu trouver un sujet qui correspondait à nos différents centres d’intérêts. La simulation d’un réseau Token Ring correspondait assez à ce que nous attendions d’un projet puisque cela consistait à créer un support de cours informatisé afin d’expliquer en classe aux étudiants le fonctionnement d’un réseau Token Ring. Il y avait aussi bien de l’analyse que de la programmation, des contraintes ergonomiques autant que des contraintes de développement. Nous verrons donc dans un premier temps la définition et le principe du Token Ring pour, dans un second temps, s’intéresser aux différentes étapes de l’élaboration de ce projet, puis nous terminerons avec une discussion sur les résultats obtenus.
Introduction
Page 14 sur 82
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
2. Présentation du protocole IEEE 802.5 Token Ring! est un réseau informatique local développé par IBM et présenté lors d'une démonstration, réalisé en octobre 1985, en reliant 260 PC avec une paire torsadé. Après cette démonstration Token Ring! fut adopté presque instantanément comme un standard. IBM déposa sa norme Token Ring! au IEEE pour qu'elle devienne un standard, connu sous le nom de IEEE 802.5.
2.1.
Principe d'échange du jeton
Quand une station A veut émettre vers une station C, elle attend que la trame permanente arrive à sa hauteur (Figure 1.1.). Puis la logique d'adaptation détermine si son jeton est libre ou non. S'il est libre, elle copie ses informations dans le train, en particulier les adresses du destinataire et de l'émetteur, positionne le jeton à l'état occupé et émet à nouveau la trame (Figure 1.2, Figure 1.3). Chacune des autres stations, lors des arrêts suivants, constatera soit que le jeton est occupé, soit que l'adresse de destination de la trame n'est pas la leur. Elles se contenteront de ré-émettre la trame sans modification. Lorsque celle-ci arrivera à la station réceptrice, elle recopiera les données de la trame, là aussi sans modification (le jeton, entre autres, restera à l'état occupé) (Figure 1.4). Ce n'est qu'au retour à la station émettrice, celle -ci constatant que les informations émises n'ont pas été altérées, que le jeton sera remis à l'état libre, c’est-à-dire avec TK = 0 (Figure 1.5).
figure 1.
Schéma d'émission de données avec un jeton.
Présentation du protocole 802.5
Page 15 sur 82
Simulation d’un réseau Token Ring
2.2.
Erwan Charlier & Grégory Denize
Composition de la trame
Le protocole de transport de l'anneau est relativement simple à appréhender. Il est basé sur le fait qu'un « train » de longueur variable circule en permanence sur l'anneau, train qui s'arrête à chacune des gares que constituent les stations connectées. Le train est toujours constitué de trois éléments, un en-tête, une zone centrale et une zone de fin (Fig 2.). L'en-tête de la trame est formé d'un délimiteur de début de trame (une configuration binaire bien particulière du code MANCHESTER), d'un octet AC très important puisqu'il contient le fameux jeton et de deux zones adresses, TO et FROM, susceptibles de désigner l'adresse d'une station appartenant à l'anneau.
figure 2.
Composition d'une trame.
Chaque zone adresse porte sur six octets, trois pour le numéro de l'anneau, trois pour le numéro de la station. L'octet FC, appelé aussi champ de contrôle du transport, est essentiel. Le bit TK est celui du jeton (TK = 0, jeton libre ; TK = 1, jeton occupé), les autres bits étant soit non utilisés à cet instant, soit affectés à des fonctions de monitorat.
Présentation du protocole 802.5
Page 16 sur 82
Simulation d’un réseau Token Ring
2.3.
Erwan Charlier & Grégory Denize
La supervision du réseau
Le nombre de postes connectés à l'anneau pouvant être très élevé, le débit de transmission de plusieurs Mbit/sec, le tout avec des stations relativement hétérogènes, il n'y a rien d'étonnant à ce que la fonction supervision du réseau soit particulièrement soignée. Cette supervision peut être décomposée en quatre niveaux, les uns portés par les adaptateurs, les autres par du logiciel exécuté par une station, dédiée ou non. Le premier niveau est constitué de diagnostics internes, générés en permanence par les adaptateurs. Il s'agit d'assurer qu'il n'y a pas d'anomalie de transmission, de détecter l'absence de signal, etc. Le second niveau est un test automatique de raccordement lors de l'insertion dans l'anneau, test qui va jusqu'à l'unité de raccordement. Si le test est positif, la station est effectivement insérée dans l'anneau. Le troisième niveau correspond à la fonction moniteur, chaque station de l'anneau étant susceptible à tout moment d'assurer cette tâche. Mais il n'y en a qu'une seule à chaque instant qui en est chargée. Cette station est dite à l'état de « moniteur actif », les autres restant en « moniteurs en attente ». La station moniteur a pour vocation de surveiller l'intégrité du jeton, de s'assurer qu'il n'est pas perdu ou qu'il parvient normalement à repasser à l'état libre (crainte du « jeton fou »). Une tâche si importante qu'elle justifie sa présence sur chaque carte d'adaptation, même s'il n'y en a qu'une d'activée à chaque instant. Si la station moniteur s'arrête, pour cause de panne ou de mise hors tension, un nouveau moniteur est élu automatiquement, de façon transparente pour les utilisateurs ou les exploitants de l'installation. Le dernier niveau de supervision est celui qu'assure un programme spécialisé, dit de gestionnaire du réseau, à acquérir indépendamment. Il surveille les erreurs permanentes et temporaires de l'anneau, avertit l'opérateur des anomalies qui exigent une action immédiate et identifie leurs causes probables, ainsi que leur origine. Il enregistre le tout dans un fichier « log » pour un examen ultérieur. Le gestionnaire de réseau affiche les postes de travail actifs de l'anneau et permet de déconnecter logiquement un poste sur demande de l'opérateur. Autres caractéristiques, ce programme permet de désigner les postes de travail par des noms symboliques, jusqu'au nombre de 260.
Présentation du protocole 802.5
Page 17 sur 82
Simulation d’un réseau Token Ring
2.4.
Erwan Charlier & Grégory Denize
Historique du Token Ring!.
Les produits Token Ring! opéraient dans un premier temps à 4Mbit/sec, puis en 1989, IBM multiplia par quatre la vitesse, avec une vitesse actuelle de 16Mbit/sec. En 1997, le High Speed Token Ring! Alliance (HSTRA) fut formé pour développer un "standard IEEE 802.5 dédié au transfert rapide allant de 100Mbit/sec à 1 Gigabit/sec". Les premiers membres de cette alliance fut 3Com, Bay Networks, IBM, Madge Networks, Olicom, the UNH Interoperability Lab, et Xylan. En 1998, le standard 802.5t devient disponible pour des opérations de Token Ring à 100 Mbit/sec. Ce standard a un champ d'application très réduit. Les premiers produits Token Ring! 100Mbit/sec furent introduits sur le marché par Olicom et IBM la même année. En 1985, IBM décida aussi de sortir le processeur 386 cadencé à 16Mhz qui améliora significativement la puissance du PC. Une autre firme américaine, Microsoft, qui allait devenir célèbre quelques années plus tard, décida de sortir en novembre une interface graphique pour utilisateurs : Windows version 1.0.
Présentation du protocole 802.5
Page 18 sur 82
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
3. Matériels et méthodes 3.1.
Situation de départ
Ce sujet étant reconduit depuis déjà quelques années par M. Miara pour les étudiants du Département, il y a donc une myriade de projets qui ont été réalisés, tous différents les uns des autres. Comme le voulait notre tuteur, nous avons donc commencé notre projet comme s’il n’y avait pas d’existant, au lieu de nous baser sur un ancien projet. Nous avons donc pu être totalement libres dans sa conception, et non pas influencés par une ancienne solution.
3.2.
Besoins de l’utilisateur
Notre tuteur de projet avait besoin d’un support de cours informatisé afin d’expliquer à ses élèves le fonctionnement d’un réseau Token Ring!. Le fait d’apprendre au travers d’un logiciel le fonctionnement d’une science est beaucoup plus ludique, mais laisse surtout une meilleure trace dans la mémoire de l’élève. Il lui fallait donc que le logiciel respecte le protocole 802.5 à la lettre afin de rendre la simulation la plus proche de la réalité, mais qu’il ait aussi une interface simple et conviviale, pouvant être utilisé par tous les élèves sans avoir à lire un manuel d’utilisation. Le Use Case (Fig. c) qui suit schématise les besoins auxquels le logiciel devra répondre.
figure 3.
Matériels et méthodes
Use Case des besoins utilisateurs.
Page 19 sur 82
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
3.3. Clarification des besoins Nous avons passé plus de deux séances à définir les objectifs (cf. Diagramme de Gantt) avec notre tuteur de projet afin de bien clarifier ses besoins. Le protocole 802.5 est un protocole assez complexe, il fallait donc savoir ce qui allait être implémenté dans la solution, ce qui pouvait intéresser les élèves durant leurs cours de réseaux, et ce qui ne le serait pas, car trop complexe à réaliser dans le temps imparti ou trop approfondi pour des cours de ce niveau. Il est bien évident que nous avons dû laisser de coté un grand nombre de fonctionnalités contenu dans le protocole, comme par exemple la trame de contrôle ou encore l’élection d’un moniteur. La solution devait donc remplir les trois principaux objectifs : 1.
L’échange de trames et de messages.
2.
La fonction de supervision du réseau avec le Moniteur.
3.
La gestion des priorités pour la capture et l’envoi du jeton.
3.4.
Définition des fonctionnalités
Le logiciel doit permettre à l’élève de réaliser les mêmes actions qu’il le pourrait dans la réalité : !
Démarrer le réseau.
Il faut que la solution lui permette, soit par un bouton, soit par un menu de démarrer le réseau comme il le ferait en vrai en reliant les appareils sur le secteur. !
Connecter / déconnecter une ou plusieurs machines.
Notre solution simule un réseau composé de 5 machines au maximum, il faut que l’utilisateur puisse de façon assez simple ajouter des machines quand il vient de démarrer le réseau. Il peut s’il le souhaite retirer des machines du réseau afin de faire sa simulation (ex : regarder le fonctionnement du protocole lorsque l’on envoie un message à une machine qui n’est plus sur le réseau) !
Envoyer un message d’une machine à l’autre
Il faut qu’il puisse, via l’interface graphique, envoyer un message à une machine du réseau depuis une autre machine. Il faut aussi que le logiciel tienne compte de la gestion des priorités (défini par le protocole) de capture du jeton et d’émission de trame. Enfin, la solution doit avertir visuellement l’utilisateur de l’arrivée des différents messages sur les stations du réseau.
Matériels et méthodes
Page 20 sur 82
Simulation d’un réseau Token Ring
!
Erwan Charlier & Grégory Denize
Avoir des informations sur la trame.
La solution doit montrer à l’utilisateur la trame circulant sur le réseau, mais aussi il doit savoir où elle se trouve à un instant T. Il faut aussi qu’il puisse savoir ce que la trame contient (l’adresse source et destination d’un message, la priorité, le message, et l’état des bits de contrôles comme l’accusé de réception, l’accusé de copie). !
Différents modes de simulation.
L’utilisateur doit pouvoir choisir entre différents modes de simulation. Il peut : - Soit avoir un mode animation avec possibilité de régler la vitesse de déplacement de la trame sur le réseau. - Soit un mode pas à pas avec lequel il peut choisir de faire avancer la trame quand il le souhaite, ce qui lui permet de visualiser les différents états des machines et de la trame et de mieux comprendre le fonctionnement du protocole - Soit un mode temps réel qui simule la vitesse réelle de déplacement de la trame sur le réseau, ce qui permet de se rapprocher un peu plus de la réalité.
Matériels et méthodes
Page 21 sur 82
Simulation d’un réseau Token Ring
3.5.
Erwan Charlier & Grégory Denize
Définition des exigences à respecter
- La portabilité n’est pas une préoccupation majeure, mais il faut y penser, puisque le parc informatique de l’IUT fonctionne avec les deux principaux acteurs du marché des systèmes d’exploitation : Linux et Microsoft Windows. - L’évolutivité du logiciel afin de rajouter à l’avenir des modules comme la gestion des priorités, l’élection du moniteur, etc… - L’utilisabilité de la solution doit consister en une interface claire, sans couleur criarde et doit être intuitive pour l’utilisateur. Il faut utiliser le sens iconographique pour que l’utilisateur comprenne tout de suite le sens des icônes.(exemple : une croix pour symboliser la déconnection d’une machine, un ‘’i’’ pour symboliser les informations disponibles sur la machine).
Matériels et méthodes
Page 22 sur 82
Simulation d’un réseau Token Ring
3.6.
Erwan Charlier & Grégory Denize
Solutions possibles pour atteindre les objectifs
3.6.1. Animation Flash en ActionScript Cette solution consistait à réaliser une animation avec Macromedia Flash, qui est un logiciel d’animation vectoriel dédié au multimédia (CD-ROM, Web Design). Macromedia livre avec Flash un langage de programmation très complet, permettant de faire autres choses que de la pure animation. Ce langage, l’ActionScript, est un langage de 4e génération (L4G), de type Objet. Il possède les caractéristiques communes à tous les langages (ex : les boucles for et while, les tests if then else). Il permet de faire des requêtes sur n’importe quelle base de données, d’incorporer du code dynamique (JSP, ASP, PHP) à l’animation. 3.6.2. Développement en Java Cette solution consistait à créer un logiciel avec des processus pour représenter chaque machine du réseau ainsi que pour le moniteur, le tout avec une interface graphique ergonomique. Java est un langage orienté objet, ce qui facilite le passage des diagrammes UML à la programmation. Il gère de façon relativement simple les threads (processus). 3.6.3. Développement en Pascal avec Delphi Cette solution consistait, comme la solution Java, à simuler au travers d’une interface graphique ergonomique un réseau Token Ring, où les machines pouvait être soit gérer par un tableau de pointeurs, soit par des processus. Il permet d’élaborer facilement une interface graphique.
Matériels et méthodes
Page 23 sur 82
Simulation d’un réseau Token Ring
3.7.
Erwan Charlier & Grégory Denize
Outils et méthodes pour la solution choisie
3.7.1.
Choix d’une méthode d’analyse
L’analyse nécessaire au développement de ce logiciel allait nous aider surtout pour choisir la structure des classes du logiciel et pour fixer les fonctionnalités du logiciel. Nous avions alors le choix d’utiliser la méthode systémique française Merise qui nous a été enseignée en première année à l’IUT, ou bien la méthode orientée objet UML (Unified Modeling Language) que nous allions apprendre pendant cette deuxième année d’informatique. Étant donné que nous avons décidé d’employer un développement orienté objet, utiliser la méthode UML pour notre analyse découlait alors de la même logique. Nous avons donc utilisé deux diagrammes parmi les neuf proposés par la méthode UML. Le diagramme de classes nous a permis naturellement d’élaborer les classes que nous allions programmer sous Delphi 7, en prévoyant les attributs et méthodes pour chaque classe, ainsi que les liens d’héritage et d’agrégation entre ces classes. De même, la conception d’un diagramme Use Case (cas d’utilisations) nous a permis de définir les actions possibles de l’utilisateur sur le logiciel, et donc d’avoir une vision globale des procédures que nous aurions à programmer. 3.7.2.
Choix du langage
L'objectif impliquait le développement d'un logiciel à part entière, et donc qu'il y ait interaction avec celui-ci. De plus, notre tuteur de stage ne nous avait pas contraint à utiliser un langage précis, donc les différentes solutions possibles étaient axées autour du choix du langage, et, compte tenu des langages que nous connaissions soit grâce à l'enseignement à l'IUT, soit par apprentissage externe, le choix reposait sur les trois langages suivants : • Développement en Java • Animation Flash avec programmation en langage Action Script • Développement en Pascal (Delphi) Bien entendu dès la première approche, opter pour le choix du langage Java paraissait la solution la plus logique : Java est un langage assez puissant pour traiter ce sujet, il est de plus assez bien répandu et il était donc intéressant et bénéfique, en tant qu’étudiants, de réaliser un projet avec celui-ci. Mais surtout, c’est ce langage que nous allions apprendre et utiliser à l’IUT tout au long de ce premier semestre. Nous avons donc fait ce choix.
Matériels et méthodes
Page 24 sur 82
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
Mais pendant la phase d’analyse qui précède la programmation, nous avons eu un premier aperçu de la collection d’outils que nous allions utiliser. Un problème s’est alors posé après environ deux semaines d’analyse : à l’heure ou ce rapport est rédigé nous avons les connaissances nécessaires pour développer un logiciel de l’envergure de ce projet de Simulation Token Ring en utilisant le langage Java, mais ce n’était pas le cas à l’époque car nous étions sur le point d’apprendre ce langage. Voyant la vitesse assez lente à laquelle nous progressions dans l’apprentissage de ce langage, il fallait se rendre à l’évidence : nous ne maîtrisions pas encore les outils et mécanismes proposés par Java et nécessaires au développement, en particulier la création de l’interface graphique et la gestion des processus, et donc nous avons remis notre choix en question en décidant de changer de langage. En effet l’avancement de la partie programmation était quasi nul, et donc prendre une telle décision plus tard nous aurait fait revenir sur nos pas, et donc perdre du temps. Nous avions l’option du langage Delphi qui miroitait dans la tête de chacun. Compte tenu de la complexité graphique et interactionnelle de ce projet, chacun de notre coté nous pensions que le choix langage évènementiel doté d’un développement semi graphique allait bien nous faciliter la tâche. Mais il ne fallait pas prendre une décision à la légère, et c’est à ce moment précis que nous avons réellement pensé aux animations Flash avec une programmation en langage Action Script. Ce choix aurait permis d’obtenir une qualité graphique sans équivalent, et les mécanismes de programmation dont nous avions besoin étaient, à première approche, proposés par ce langage. Cela dit, la qualité graphique de notre production n’était pas un axe principal du sujet, bien qu’il ne fallait pas négliger ce détail. Il devenait donc de plus en plus clair que d’utiliser Delphi correspondrait bien aux besoins et attentes que nous avions envers un langage de programmation. Nous avons alors opté pour le choix de Borland Delphi 7 Entreprise après avoir demandé à notre tuteur de projet, qui partage notre avis quant aux multiples problèmes graphiques que posait Java, et qui a donc approuvé ce choix.
Matériels et méthodes
Page 25 sur 82
Simulation d’un réseau Token Ring
3.8.
Erwan Charlier & Grégory Denize
Les différentes étapes de réalisation !
Test graphique
Nous avons tout d’abord testé comment faire tourner un jeton sur un cercle, afin de représenter graphiquement l’anneau à jeton. C’est aussi là que nous avons commencé à travailler sur l’aspect graphique que notre application allait avoir : le choix des couleurs, des symboles, de l’ergonomie des fenêtres.
figure 4.
Matériels et méthodes
Capture d’écran du Test Graphique
Page 26 sur 82
Simulation d’un réseau Token Ring
!
Erwan Charlier & Grégory Denize
Base opérationnelle
Dans cette étape, nous avons implémenté l’algorithme le plus simple du protocole 802.5, c’est-à-dire l’échange de trames et de messages entre les différentes machines du réseau qui constitue notre premier objectif. Cette solution été dépourvue d’interface graphique ergonomique.
figure 5.
!
Capture d’écran de la Base opérationnelle
Base solide avec interface graphique
Le premier objectif étant rempli par la base opérationnelle, il suffisait donc de réunir l’interface graphique ergonomique et l’algorithmique.
figure 6.
Matériels et méthodes
Capture d’écran de l’Objectif n°1
Page 27 sur 82
Simulation d’un réseau Token Ring
!
Erwan Charlier & Grégory Denize
Intégration du moniteur, des priorités et du contrôle de trame
Nous avons procédé comme un jeu de construction, une fois qu’un objectif était atteint, nous rajoutions petit à petit des briques au logiciel, comme cela, nous avions toujours une base qui fonctionnait pendant que nous développions les fonctionnalités suivantes. À l’objectif 1 s’est ajouté un moniteur pour surveiller le réseau, des priorités de capture de trame et une fenêtre de contrôle de la trame.
figure 7.
Matériels et méthodes
Capture d’écran de la version finale du logiciel
Page 28 sur 82
Simulation d’un réseau Token Ring
3.9.
Erwan Charlier & Grégory Denize
Les phases du développement
Dans cette partie, nous nous attarderons sur l’aspect technique de notre solution du point de vue des classes et types utilisés, mais nous apporterons aussi quelques précisions sur les algorithmes et sur le fonctionnement principal du logiciel. 3.9.1.
Classes et Types
Les explications fournies dans cette partie sont ciblées sur les grands concepts utilisés pour réaliser ce projet car on ne peut pas détailler chaque méthode, attribut, et algorithme présent dans le code de ce logiciel. Donc de manière globale, notre attention sera portée sur les quatre classes (et donc types) qui caractérisent l’implémentation choisie d’une part, et les deux classes dites « graphiques » qui sont séparées de l’algorithme permettant de respecter la norme 802.5 et qui servent à présenter correctement le logiciel de manière graphique d’autre part. ! Les classes utilisées pour respecter le protocole 802.5 :
" Le type TMachine : La première version de l’analyse conceptuelle a consisté surtout à créer le diagramme de classes. Au départ notre idée était centrée sur la différenciation entre une machine qui envoie un message, une qui reçoit un message, et enfin une qui est passive et ne fait que transmettre les messages. Nous avions donc un type Machine qui constituait la classe parente dont héritait trois autres classes, comme ceci :
figure 8.
Diagramme de classe dans sa première version
Chaque machine aurait alors été un pointeur qui référencerait un objet soit Emetteur, Relais ou Destinataire en fonction de l’état dans lequel la machine se trouvait, et ainsi il suffisait de changer l’objet référencé par ce pointeur pour faire transiter l’état de la machine (prévoyant bien sûr des méthodes qui permettraient de convertir une machine d’un état à un autre sans pertes d’informations).
Matériels et méthodes
Page 29 sur 82
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
Mais cette solution a vite été rejetée car une machine ne pouvait être, à un moment précis, que dans un seul état. Elle ne pouvait donc que soit recevoir un message, soit attendre un message, soit seulement transmettre les messages des autres, et ceci ne correspond bien évidemment pas à la réalité du fonctionnement d’un réseau. Nous avons alors décidé de faire une grande classe machine, nommée TMachine, qui comprendrait tous les attributs et méthodes nécessaires au fonctionnement d’une machine, ce qui après tout est la solution la plus logique. Il suffisait de placer des attributs servants d’indicateurs d’états dans lesquels la machine se trouvait sous formes de booléens en particulier. Par exemple un booléen nommé VeuxEnvoyerMessage permet d’indiquer qu’une machine désire envoyer un message. Puis, suite à des problèmes d’interactions entre l’interface graphique et un objet de type TMachine, nous avons poussé notre raisonnement jusqu’à encapsuler le rendu graphique et les composants graphiques associés à une machine dans la classe TMachine. En effet, le souci était que selon l’implémentation choisie, soit l’interface graphique pouvait agir sur la classe TMachine, soit l’inverse, mais jamais les deux en même temps. Ceci posait donc des problèmes conceptuels, compte tenu surtout du nombre de contrôles que l’interface graphique devait effectuer sur la classe TMachine. Delphi étant un langage événementiel fonctionnant avec des fiches associées à des contextes graphiques, il était alors plus logique d’utiliser une seule et même classe TMachine qui comprendrait les méthodes purement algorithmiques. Les rendus graphiques et les méthodes associées aux actions sur la fenêtre représentant une machine : une machine est alors implémentée sous la forme d’un seul et même objet, et correspond à une seule fenêtre dont l’apparence est la suivante :
figure 9.
Matériels et méthodes
Fenêtre de contrôle d’une Machine
Page 30 sur 82
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
" Le type TMoniteur : Toutes les machines étaient donc identiques : des objets produits par la classe TMachine. Toutes, sauf une qui devait jouer le rôle de moniteur du réseau. Son rôle est défini dans le protocole 802.5, et concrètement ce moniteur devait se comporter comme une machine du type TMachine mais en effectuant différemment quelques méthodes. Donc la solution de l’héritage tombait sous le sens : une classe TMoniteur hérite de la classe TMachine pour bénéficier du polymorphisme et donc modifier certaines de ses méthodes ou en ajouter sans avoir à redéfinir celles-ci :
figure 10.
Diagramme de classe de TMoniteur héritant de TMachine
Au niveau du rendu graphique, le moniteur est seulement différencié par la couleur de fond qui est orange pour bien marquer la différence, et les titres et descriptions de celui-ci :
figure 11.
Matériels et méthodes
Fenêtre de contrôle du Moniteur
Page 31 sur 82
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
" Le type Reseau : Le type Reseau caractérise la manière dont nous avons implémenté notre projet. En effet, lors de la première approche conceptuelle, nous avions prévu un type Reseau qui permettrait d’assurer la communication entre tous les objets de type TMachine et ceci par l’intermédiaire d’un objet de type Trame, qui est un objet instancié de la classe Trame dont nous détaillerons le développement plus loin. Au départ, la présence de cette classe était justifiée par le fait que nous n’avions pas implémenté les machines sous forme de processus et donc il fallait une seule tâche active qui « réveillerait » chaque machine, c'est-à-dire qui exécuterai la procédure de réception d’une trame sur chaque machine lorsque le tour de celle-ci serait venu. Donc concrètement les machines ne fonctionneraient pas de manière indépendante, en attendant qu’une trame arrive pour en renvoyer une à la machine qui suit sur le réseau comme on pourrait le penser. Non, avec cette implémentation l’objet Reseau contient les autres machines, l’unique trame, et déclanche tour à tour sur chaque machine la procédure qui permet de lire la trame du réseau. Ainsi c’est plutôt les machines qui tournent autour de la trame et non pas la trame qui circule de machines en machines. La classe Reseau possède un attribut nommé TableauMachinesInscrites qui est un tableau contenant des objets de type TMachine. Une autre implémentation envisagée aurait consisté à créer une liste simplement chaînée d’objets TMachine, mais cette idée a été abandonnée par manque de temps. Un objet Reseau est donc associé à un objet de type Trame, un tableau d’objets de types TMachine, mais aussi à un unique moniteur car il n’y a qu’un seul moniteur présent à un instant donné sur un réseau de type Token Ring. On peut donc schématiser la classe Reseau ainsi :
figure 12.
Matériels et méthodes
Schéma de fonctionnement de la classe Réseau
Page 32 sur 82
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
Ceci était donc censé être une implémentation provisoire en attendant de modifier la classe TMachine sous forme de processus indépendant. Mais hélas, nous avons rencontré des difficultés pour réaliser cette étape, en particulier dû au fait que le mécanisme des processus ne nous a été enseigné que tard dans le semestre, et de plus la gestion des processus en Delphi était assez différente que celle que nous connaissions vaguement en Java. Après plusieurs tests à ce sujet, nous avons dû renoncer à cette implémentation et garder le principe de la classe Reseau supervisant les machines.
" Le type Trame : Un objet Reseau contient un seul objet de type Trame. Cette objet Trame sert donc à représenter la trame qui circulerait sur le réseau physique, et donc cette trame possède des attributs proches des champs que possède une trame Token Ring dans la norme 802.5, mais avec des noms plus évocateurs. Cet objet Trame peut-être associé à un camion utile à la communication entre les objets TMachine du réseau comme le fait une trame Token Ring dans le protocole, mais la différence ici est, comme précisée ci-dessus, que ce sont les objet TMachine sollicités par l’objet Reseau qui accèdent à cet objet Trame à tour de rôle. !
Les classes « graphiques » utiles à l’aspect du logiciel :
Les deux classes suivantes ne sont instanciées qu’une seule fois dans le logiciel au lancement de celui-ci :
" La classe TPrincipale : C’est en fait ce qui est appelé en langage Delphi la « Forme Principale », et donc la fenêtre d’affichage principale, celle qui est crée et lancée en premier lieu lorsque le logiciel est exécuté. Cette classe contient donc une variable de type Reseau, qui est donc instancié de la classe Reseau. Ainsi sur la fenêtre correspondant à cette classe figure le cercle graphique représentant le réseau, les machines, la trame etc. Et par l’intermédiaire de cette fenêtre on peut notamment agir sur le mode de simulation du réseau et la connexion / déconnexion des machines.
" La classe TControle_Trame : C’est aussi une fenêtre qui est créée dès l’initialisation du logiciel. Elle sert à avoir un rendu graphique, un contrôle comme son nom l’indique, de la trame circulant virtuellement sur le réseau. On ne peut pas agir sur la trame par l’intermédiaire de cette fenêtre et il n’y a par conséquent aucun bouton. Il y a seulement des zones de textes où s’affichent les informations sur l’état de la trame. Ces informations sont rafraîchies à chaque fois qu’une machine accède à la trame par une méthode qui est incluse dans cette classe TControle_Trame. Cette méthode de rafraîchissement est alors appelée par l’objet Reseau qui, rappelons le, est le cerveau du fonctionnement du réseau.
Matériels et méthodes
Page 33 sur 82
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
3.9.2. Précisions sur les algorithmes employés et sur le fonctionnement général Dans cette partie, nous allons détailler le principe de certains algorithmes employés pour respecter la norme 802.5 et le fonctionnement du logiciel. !
Envoi de messages :
Il est important de savoir que dans l’implémentation choisie une machine ne peut envoyer qu’un seul message à la fois et surtout qu’un message est caractérisé par un texte à envoyer, et n’a besoin que d’une seule trame pour arriver à son destinataire. Un message = une trame : il n’y a donc pas de trames dites « intermédiaires ». Une machine ne peut envoyer qu’un seul message à la fois car la classe TMachine ne prévoit pas d’espace de stockage pour les futurs messages à envoyer après celui qui est en cours d’envoi. C’est pourquoi lorsqu’une machine a déjà un message en attente (caractérisé par la valeur vrai au booléen VeuxEnvoyerDonnees), on ne peut pas essayer d’envoyer un autre message tant que celui qui est en cours n’a pas été traité, et un message le signale alors à l’écran. !
Indicateurs d’acheminement du message :
Ce sont des sortes de diodes lumineuses, dans la fenêtre d’une machine, qui s’éclairent pour donner des informations sur l’acheminement du message que l’on vient d’envoyer :
figure 13.
Fenêtre avec indicateurs d’acheminement du message
Lorsqu’on appuie sur le bouton envoyer, cela signifie que la machine veut envoyer un message. Alors la led jaune (Attente) s’allume, les autres étant éteintes. On attend un résultat à notre action, c'est-à-dire si le destinataire a correctement reçu le message. Lorsque la trame passe par cette machine et que cette dernière arrive à capturer le jeton, elle envoie son message. À ce stade, seul la lumière jaune (Attente) est allumée. C’est seulement lorsque la procédure RecevoirTrame est sollicitée de nouveau au prochain tour de la trame que l’indicateur d’état va nous donner l’information sur l’acheminement du message. En effet dans la procédure RecevoirTrame, lorsque est sollicitée la partie de l’algorithme où l’adresse de la machine émettrice dans la trame est égale à l’adresse de la machine où est la trame actuellement, la machine libère le jeton. De plus elle contrôle le booléen DonneesRecopiees qui est contenu dans la trame : celui-ci est mis à faux lors de l’envoi du message, et mis à vrai par la machine destinataire seulement. Alors si celui-ci est encore à faux pendant cette phase de l’algorithme, cela signifie que le
Matériels et méthodes
Page 34 sur 82
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
message n’est pas parvenu à son destinataire, et donc c’est grâce à ce booléen que les diodes qui nous indiquent l’acheminement du message sont mis à jour : si le booléen DonneesRecopiees possède la valeur vrai, la diode verte (Reçu) s’éclaire, sinon c’est la diode rouge (Erreur) qui s’éclaire. Dans les deux cas, la diode jaune (Attente) s’éteint car l’information sur l état d’acheminement est arrivée, et on n’attend pas d’autres informations. !
Compteur de passage au moniteur :
Le protocole Token Ring prévoit qu’une trame qui parcourt plus d’une fois le tour du réseau soit supprimée par le moniteur. Cette fonctionnalité entre en jeu lorsque, en particulier, une machine envoie un message à une autre machine mais se déconnecte avant que la trame envoyée ne lui revienne : ainsi le jeton n’est pas libéré et si le moniteur n’était pas là, la trame continuerai à tourner sur l’anneau éternellement et le jeton ne serai jamais libéré, car la seule machine ayant les droits pour libérer ce jeton ne serai plus présente sur le réseau. Voilà donc entre autre l’utilité du moniteur. C’est pourquoi l’algorithme de réception d’une trame implémentée dans la classe Moniteur rajoute la prise en charge de l’incrémentation du champ CompteurMoniteur dans la classe Trame, ainsi que la libération du jeton lorsque cet entier CompteurMoniteur est supérieur à un. !
La gestion des priorités :
Toujours dans le souci de respecter la norme 802.5, nous avons implémenté la gestion des priorités en nous basant sur les documents fournis par notre tuteur de projet et sur des documents tirés d’Internet, notamment un document de TD (Travaux Dirigés) de Maîtrise de l’Université de Versailles St Quentin en Yvelines. Il est important de remarquer que lorsqu’une trame est supprimée car elle a parcouru plus d’une fois le tour de l’anneau, il y a perte des priorités que contenait le jeton avant sa suppression, car la nouvelle trame renvoyée par le moniteur possède comme priorité 1 et comme priorité réservée 1 également. Cette réinitialisation est effectuée afin de ne pas bloquer le réseau, pour qu’il n’y ait pas une trame circulant éternellement sur le réseau sans que personne ne puisse capturer le jeton à cause d’une priorité trop élevée sur le jeton. La seule conséquence négative de ce comportement est que la première machine qui se trouve après le moniteur et qui veut capturer le jeton pourra le faire, peut importe la priorité de cette machine. En effet il faut bien qu’une machine capture le jeton avant les autres, les machines suivantes pourront alors réserver leur priorité à nouveau, et cette fois-ci ces priorités seront respectées.
Matériels et méthodes
Page 35 sur 82
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
4. Résultats Nous verrons dans cette partie des captures d’écran de notre logiciel présentant ses différentes fonctions.
4.1.
Le mode animation
figure 14.
Capture d’écran de la fenêtre principale en mode Animation
Voici la fenêtre que l’utilisateur voit lorsqu’il lance le logiciel pour la première fois. Le choix des couleurs pastel s’est fait pour retirer le côté auster du gris, mais sans pour autant utiliser des couleurs criardes, qui dérangeraient l’œil, et donc la concentration de l’utilisateur. La disposition des boutons a aussi été étudiée pour que l’utilisateur accède rapidement aux fonctions principales du logiciel, sans qu’il ait à parcourir plusieurs menus pour démarrer le réseau par exemple. Les fonctions machines (connexion, déconnexion, informations) ont été placées sur la machine elle même. Lorsqu’il clique sur la croix, l’utilisateur déconnecte la machine du réseau. Lorsqu’il clique sur le « i », il accède à la fenêtre de contrôle de la machine (Figure 17). Les boutons de changement de mode (Animation, Pas à pas, Temps Réel) sont placés au centre de la fenêtre pour qu’il puisse être vu du premier coup d’œil. Enfin, dans ce mode, l’utilisateur à la possibilité de régler la vitesse de simulation du réseau, grâce à une réglette placée au centre du réseau.
Résultats
Page 36 sur 82
Simulation d’un réseau Token Ring
4.2.
Erwan Charlier & Grégory Denize
Le mode pas à pas
figure 15.
Capture d’écran de la fenêtre principale en mode pas à pas
Dans ce mode pas à pas, l’utilisateur a bien sûr accès aux fonctions machines comme décrites précédemment, mais il peut surtout faire passer manuellement la trame de machine en machine. Il peut le faire grâce à un bouton «Passer la trame à la machine suivante », et il peut contrôler juste en dessous où se trouve la trame, à quelle machine. L’utilisateur peut, grâce au bouton symboliser par une télécommande, afficher la fenêtre de contrôle de la trame (Figure 19) afin de voir ce que la trame contient et avoir les différentes informations dessus.
Résultats
Page 37 sur 82
Simulation d’un réseau Token Ring
4.3.
Erwan Charlier & Grégory Denize
Le mode temps réel
figure 16.
Capture d’écran de la fenêtre principale en mode Temps Réel
Ce mode a été rajouté pour rapprocher la simulation au plus près de la réalité. L’utilisateur envoie un message via la fenêtre de contrôle de machine (Figure 17) et voit le résultat instantanément, c’est à dire la fenêtre de la machine destinataire clignote tout de suite après que le message est été envoyé. Le bouton symbolisant une personne ayant mal à la tête permet d’arrêter le clignotement du cercle, nous avons prévu le cas où le clignotement pourrait gêner l’utilisateur.
Résultats
Page 38 sur 82
Simulation d’un réseau Token Ring
4.4.
Erwan Charlier & Grégory Denize
Les machines
figure 17.
Capture d’écran d’une fenêtre de contrôle Machine et Moniteur
Une fenêtre de contrôle d’une machine est divisée en deux parties : - La partie supérieure est destinée à afficher les messages que la machine reçoit, mais aussi les informations concernant la machine émettrice. C’est aussi dans cette partie de la fenêtre que l’on peut savoir si la machine souhaite le jeton au prochain tour. - La partie inférieure, à laquelle on peut accéder grâce aux boutons + et – situé en bas de la fenêtre, est quant à elle destinée à envoyer des messages aux autres machines. C’est là que l’utilisateur spécifie le numéro du destinataire, la priorité qu’il souhaite et enfin le corps de son message. Il peut savoir à tout moment l’état d’envoi de son message grâce aux diodes situées en dessous. La fenêtre du Moniteur possède les mêmes caractéristiques qu’une fenêtre de contrôle de Machine classique, seule sa couleur change pour savoir qu’on utilise le Moniteur. Les actions que le Moniteur réalise en tâche de fond ne sont pas symbolisées sur la fenêtre.
Résultats
Page 39 sur 82
Simulation d’un réseau Token Ring
4.5.
Erwan Charlier & Grégory Denize
La trame
figure 18.
Capture d’écran de la fenêtre de contrôle de la Trame
La fenêtre de contrôle de la Trame est de la même couleur que la trame, afin de garder une certaine homogénéité entre les couleurs et les objets symbolisés. Cette fenêtre apparaît lorsque l’utilisateur clique sur le bouton symbolisant une télécommande. Elle lui donne des informations sur l’état du jeton, sur les données contenu par la trame, c’est-à-dire le message avec l’adresse de l’émetteur et du destinataire. Elle permet aussi de savoir si les données ont été recopiées par la machine destinatrice. Enfin elle informe sur les priorités, sur celle du jeton et sur la priorité réservée, mais elle dispose aussi d’un compteur de trame pour savoir s’il n’y a pas de jeton « fou » sur le réseau (c’est un jeton qui ne trouve pas son destinataire, et qui boucle infiniment).
Résultats
Page 40 sur 82
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
5. Discussion Dans tous nos choix, le facteur temps a été décisif. En effet, la solution choisie a été retenue parmi plusieurs autres implémentations possibles sur lesquelles nous avions largement réfléchi, mais que nous avons dû oublier par manque de temps pour les réaliser. C’est donc surtout au niveau du futur de ce projet, si il était à reprendre, que la discussion aura lieu. Comme vu précédemment dans la partie « Développement », nous voulions opter pour une implémentation où chaque machine aurait été un processus indépendant. Nous étions très attachés à cette implémentation car elle était bien représentative de la réalité où chaque machine est, en effet, un objet indépendant qui attend de recevoir des informations et en communique dès qu’il y en a besoin. C’est donc par manque de temps et avec regret que nous avons du renoncer à cette solution, d’autant plus qu’une analyse assez poussée avait été effectuée dans cette optique de développement. Mais ce n’est pas le seul point sur lequel nous avons dû renoncer. La solution qui aurait employé des processus allait de paire avec le fait que les machines auraient été représentées par une liste simplement chaînée d’objets de type TMachine, et là aussi cette implémentation aurait été proche de la réalité, car un réseau de type Token Ring, comme son nom l’indique, possède une topologie en anneau et quoi de mieux qu’une liste simplement chaînée se refermant sur ellemême pourrait représenter un anneau ? Mais le manque de temps nous a contraint à utiliser un tableau d’objets de types TMachine au lieu d’une chaîne. Ce n’est pas seulement sur ces derniers problèmes que nous avons dû choisir une solution moins coûteuse en temps, mais il y a un points commun à toutes ces prises de décision : favoriser le respect du protocole Token Ring du point de vue graphique. En clair, le but était que la solution finale représente une simulation de réseau, donc bien que la solution optimale aurait été de créer des algorithmes les plus proches possibles de la réalité, il était donc important en optant pour une solution comprenant des algorithmes simplifiés que le résultat soit réaliste à son tour, et donc que ce résultat respecte le protocole, indépendamment du choix des algorithmes. C’est dans cette optique que nous avons avancé : privilégier le résultat, afin qu’une personne qui teste ce logiciel de simulation soit face aux mêmes comportements que si il était vraiment en présence d’un réseau de type Token Ring. Le manque de temps nous a aussi contraint à n’implémenter que certaines fonctionnalités d’un réseau Token Ring. Bien entendu, il était impossible de simuler tous les comportements d’un tel réseau avec le temps qui nous a été attribué, et ainsi nous avons dû laisser de côté de nombreux cas de figures, en particulier l’élection d’un nouveau moniteur et la gestion des trames de contrôle.
Discussion
Page 41 sur 82
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
6. Conclusion De manière générale, nous retiendrons que les objectifs fixés ont été atteints. Ils étaient centrés sur l’échange de trames et de messages, sur la fonction de supervision du réseau avec le moniteur et sur la gestion des priorités pour la capture et l’envoi du jeton, et grâce aux moyens mise en œuvre, nous avons effectivement réussi à implémenter ces fonctionnalités. Nous avons beaucoup réfléchi sur ce projet et nous avons dû laisser des travaux de côté, mais ceux-ci ne sont pas inutiles tout d’abord parce que nous sommes conscients que la réalisation d’un projet se déroule ainsi dans le monde professionnel, il y a beaucoup de solutions envisagées et étudiées mais une seule est retenue du fait du temps imparti. Mais aussi parce que ces solutions inexploitées dans le cadre de ce projet pourraient être développées par d’autres personnes si ce projet était repris dans l’avenir.
Conclusion
Page 42 sur 82
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
Annexes A. Bibliographie Articles & revues : - Bonin C. 1986, Tout connaître de l'anneau à jeton IBM. Temps Micro - Décision PC: n°20 p39-75 - Siméon V 1985, Marescot P. Comprendre la Télématique. Science & Vie Micro: n°10 p136-147 - Réseaux, Anneaux, Canaux. Dossier Education Amstrad France 1987 : n°11 143 - Évolution du Token Ring. 01 Informatique 1993 : 15 Octobre p ? Articles de livres : - Christ, Hesling. 1989, Fourniture de service de transport OSI en mode connexion utilisant le service réseau en mode sans connexion dans un système d'extrémité, sur un réseau local en anneau à jeton. In : Norme Z66-335 Réseaux locaux. Paris : AFNOR,; 1-29. - Jonathan Follows. 2000, What is Token Ring? In : Token Ring Solutions RedBook. IBM, ; 9-18. Document électronique Site de Cisco http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/tokenrng.htm Site de RAD http://www2.rad.com/networks/1996/toknring/toknring.htm#Mechanisem Laboratoire d'informatique de l’Université de Versailles St-Quentin en Yvelines http://www.prism.uvsq.fr/users/TDs/td_5_Maitrise-Isty2.htm
Annexes
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
B. Dossier d’analyse Diagramme des Use Case
figure 19.
Annexes
Diagramme des Use Cases (Cas d’utilisation)
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
Diagramme de Classes
figure 20.
Annexes
Diagramme de classes sans la fenêtre principale
Simulation d’un réseau Token Ring
figure 21.
Annexes
Erwan Charlier & Grégory Denize
Diagramme de classe de la fenêtre principale
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
C. Dossier de programmation Voici le code source des classes les plus importantes du projet, ne nous fournissons pas le code de la classe TPrincipale et TControle_Trame ici au vu de leurs tailles. Cependant toutes les sources sont disponibles sur le CD-ROM fourni. Classe TMachine unit U_Machine; interface uses Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, StdCtrls, ExtCtrls, Buttons, U_Trame ;
type TMachine = class(TForm) GroupBox1: TGroupBox; LAdresseRecues: TLabel; LDonneesRecues: TLabel; Titre1: TLabel; EAdresseRecue: TEdit; EDonneesRecues: TEdit; GroupBox2: TGroupBox; LDonneesAenvoyer: TLabel; LEnvoiMess: TLabel; LAdresseDest: TLabel; EDonneesAenvoyer: TEdit; BEnvoyerMsg: TButton; BitBtn1: TBitBtn; CercleErreur: TShape; CercleReception: TShape; Label1: TLabel; Label3: TLabel; Shape2: TShape; Label4: TLabel; TimerBlink: TTimer; CercleAttente: TShape; Label5: TLabel; LTexteVeuxJeton: TLabel; LVeuxJeton: TLabel; BMasqueEnvoie: TSpeedButton; BAfficheEnvoie: TSpeedButton; LPrioriteDesiree: TLabel;
Annexes
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
EPrioriteDesiree: TEdit; BAnnulerEnvoi: TButton; EAdresseDest: TEdit; procedure BitBtn1Click(Sender: TObject); procedure BEnvoyerMsgClick(Sender: TObject); procedure TimerBlinkTimer(Sender: TObject); procedure BAfficheEnvoieClick(Sender: TObject); procedure BMasqueEnvoieClick(Sender: TObject); procedure BAnnulerEnvoiClick(Sender: TObject); protected { Déclarations Protégées } Adresse : integer ;
// adresse de la machine VeutEnvoyerDonnees : boolean ;
// indicateur de volontée d'envoyer des données DonneesEnAttente : record msg : String ; // texte qui figurera dans le prochain message qui sera envoyé dest : integer ; // adresse du destinataire du prochain message
end ; Socket : ^Trame ;
{ pointe sur la Trame du reseau lorsque la machine possède cette Trame, ou pointe sur nil sinon } DonneesRecues : String ;
// buffer où est déposé le texte contenu dans le dernier message reçu SourceMsg : integer ;
// contient l'adresse de l'expéditeur du dernier message reçu CouleurFond : TColor ;
// couleur de la fenetre d'infos lorsque la machine est en situation normale
Annexes
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
PrioriteMachine : integer ;
// Priorite que la machine décidé pour l'envoi de son futur message PrioriteSauve : integer ;
// Ancienne priorite du Jeton Sauvegardée par la machine public { Déclarations Publiques } procedure Initialisation(adr : Integer) ; virtual ; procedure RecevoirTrame(T : Trame) ; virtual ; procedure RecopierDonnees ; procedure CapturerJeton ; procedure EnvoyerTrame ; procedure EnvoyerDonnees(msg : String; dest : integer; P : integer) ; procedure LibereJeton ; procedure DonneeRecopiees ; function getAdresse : integer ; function getDonnees : String ; function getAdresseSource : integer ; procedure Clignoter ;
end; var Machine: TMachine;
implementation {$R *.dfm} procedure TMachine.Initialisation(adr : integer) ;
{ Initialise la machine : c'est à dire que lorsque un objet de type machine est créé, l'appel de cette procedure permet de mettre les paramètres de la machine à des valeurs vierges. Cette procédure vient en complément de la procédure create car on ne peut faire ces initialisations dans la procedure create : en effet les objets mentionné sur la fiche graphique ne sont tous créés qu'à la fin
Annexes
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
seulement de la procedure create. D'ou la nécessecité d'appeler cette procedure Initialisation juste après la procédure create. } begin Adresse := adr ; // Attribution de l'adresse passée en paramètres VeutEnvoyerDonnees := false ; // on note qu'on ne veut pas envoyer de données Socket := nil ; // l'emplacement réservé à la réception u jeton est vide DonneesRecues := '' ; // pas de données reçues pour l'instant SourceMsg := 0 ;// message provient de la machine 0 : il n'y a pas de message! // initialisation du titre de la fenetre : Caption := 'Contrôle de la Machine ' + IntToStr(Adresse) ;
// initialisation du texte en haut de la fenetre : Titre1.Caption := 'Machine n° ' + IntToStr(adresse) ; CouleurFond := clMoneyGreen ; // réglage de la couleur de fond de la fenetre Titre1.Width := 148 ; // taille du titre du haut de la fenetre SetBounds(0,Adresse*70,256,144); // emplacement et taille de la fenetre { l'emplacement initial de la fentre varie en fonction de son adresse afin
que les fenetres ne se superposent pas à leur création on n'a pas encore envoyé de messages, donc le bouton d'annulation d'envoi n'est pas visible pour l'instant : } BAnnulerEnvoi.Visible := false ; PrioriteMachine := 1 ; // priorité initiale de la machine réglée à 1 PrioriteSauve := 1 ; // priorité réservée initiale de la machine réglée à 1 //pour que la fenetre reste en avant plan par rapport à la fenetre principale: FormStyle := fsStayOnTop ; end ; procedure TMachine.RecevoirTrame(T : Trame);
{ Cette procédure prévoit le comportement que la machine doit adopter lorsqu' elle reçoit une Trame, puis lorsqu'elle a fini ses opération, elle appelle la procedure EnvoyerTrame qui, virtuellement, envoie la trame à la
Annexes
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
machine suivante sur le reseau, mais qui concretement efface seulement la référence que détient le pointeur Socket, car ici c'est l'objet Reseau qui s'occuppe de faire passer la trame à la machine suivante. } begin new(Socket) ; // réservation d'un espace mémoire pour la variable Socket { placement de l'objet Trame passé en paramètre dans l'espace mémoire de la variable Socket : } Socket^ := T ; if Socket.getOccupe then // c'est à dire si le jeton n'est pas libre
begin
// si l'adresse de destination contenue dans la Trame est la meme que // l'adresse de la machine, c'est donc que le message nus est destiné : if Socket.getAdresseDestination = Adresse then begin RecopierDonnees ; // on recopie alors les données // on place le texte reçu dans la fenetre d'affichage prévu à cet effet : EDonneesRecues.Text := DonneesRecues ;
// on recopie l'adresse de l'emmetteur dans l'indicateur prévu à cet effet // sur la fenetre d'affichage : EAdresseRecue.Text := IntToStr(SourceMsg) ;
// on fait clignoter la machine pour signaler qu'on a reçu un message : Clignoter ;
// on signale dans la trame que le message a bien été recopié : Socket.RecopieDonneesOK ; end ;
// si l'adresse source contenue dans la Trame est la meme que // l'adresse de la machine, c'est donc que le message que cette machine
Annexes
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
// a envoyé précédement a fait le tout de l'anneau et est revenu : if Socket.getAdresseSource = Adresse then begin
// on allume l'indicateur rouge si le message envoyé n'a pas été recopié // par le destinataire, en vert sinon : if not Socket.getDonneesRecopiees then CercleErreur.Brush.Color := clRed else CercleReception.Brush.Color := clGreen ;
// on éteint l'indicateur jaune qui signifiait qu'on attendait un résultat // car on avait envoyé un message : CercleAttente.Brush.Color := clMoneyGreen ; LibereJeton ; // on libère le jeton car cette machine est l'expéditeur // on affecte au jeton la priorité qui était réservée avant la // capture de celui-ci : Socket.AffecterPriorite(Socket.getPrioriteReservee); end ; if VeutEnvoyerDonnees // si on veut envoyer des données then // on procède alors à la Réservation : begin
// si la priorite de la machine est supérieure à celle réservée // sur le jeton : if (PrioriteMachine > Socket.getPrioriteReservee) then begin
// on sauvegarde la prioritée réservée : PrioriteSauve := Socket.getPrioriteReservee ;
// on affecte notre priorité au jeton : Socket.AffecterReservation(PrioriteMachine) ; end ; end ; end else // c'est à dire si le jeton est libre begin if VeutEnvoyerDonnees // si on veut envoyer un message then begin
// si la priorité de la machine est suppérieure ou égale à celle du jeton:
Annexes
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
if (PrioriteMachine >= Socket.getPriorite) then begin CapturerJeton ; // on capture le Jeton // on affecte notre priorité au Jeton : Socket.AffecterPriorite(PrioriteMachine);
// on affecte la priorité qu'on avait sauvegardé à la priorité // réservée du jeton Socket.AffecterReservation(PrioriteSauve) ; PrioriteSauve := 1 ; // on définit notre priorité sauvegardée à 1 // on signale qu'on ne veut plus envoyer de message : VeutEnvoyerDonnees := false ;
// on cache le bouton d'annulation d'envoi car on ne peut plus annuler // à ce stade : BAnnulerEnvoi.Visible := false ;
// on affiche sur la fenetre qu'on ne veut plus envoyer de message : LVeuxJeton.Caption := 'Non';
//on crée un Jeton avec les paramètres expéditeur, destinataire et texte Socket.CreerJeton(Adresse,DonneesEnAttente.dest,DonneesEnAtten te.msg) ; end ; end ; end ;
// on envoi la trame, donc concretement on efface la référence // du pointeur Socket : EnvoyerTrame ;
end ; procedure TMachine.RecopierDonnees ;
{ Lorsque la trame reçue détient un message pour cette machine, cette procedure RecopierDonnees est appelée, recopiant ainsi les données reçues dans la variable DonneesRecues et l'adresse de la machine source dans la variable SourceMsg
Annexes
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
} begin DonneesRecues := Socket.LireTrame ; // recopie des données SourceMsg := Socket.getAdresseSource ; // recopie de l'adresse de l'expéditeur end ; procedure TMachine.CapturerJeton ;
{ Capture le jeton de la trame qui est référencée par le pointeur Socket, c'est à dire la trame qui vient de nous parvenir. } begin Socket.CapturerJeton ; // capture du jeton end ; procedure TMachine.EnvoyerTrame ;
{ Efface seulement l'adresse contenue dans le pointeur Socket, et donc efface le lien avec la Trame. Le nom "EnvoyerTrame" de cette procedure est choisi pour mieux comprendre le fonctionnement de l'algorithme global, mais concretement c'est l'objet reseau qui s'occuppe de transmettre la trame à la machine suivante et non pas la machine qui effectue la procedure EnvoyerTrame. } begin Socket := nil ; // effacement de l'adresse que pointe Socket end ; procedure TMachine.EnvoyerDonnees(msg : String; dest : integer; P : integer) ;
{ N'envoi pas directement les données, mais prépare la machine à vouloir envoyer des données lorsque la prochaine trame arrivera. Le booleen VeutEnvoyerDonnees sert de notification destinée à la procédure RecvoirTrame pour lui indiquer qu'elle devra, essayer d'envoyer le message préparé (donc placer sa priorité
Annexes
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
ou envoyer créer la trame de message directement si le jeton est libre). } begin
// on signale qu'on veut envoyer des données au prochain tour du reseau : VeutEnvoyerDonnees := true ;
// on affiche sur la fenetre qu'on veut envoyer un message : LVeuxJeton.Caption := 'Oui'; DonneesEnAttente.msg := msg ; // recopie du message passé en paramètre // recopie de la'adresse du destinataire passée en paramètres : DonneesEnAttente.dest := dest ; PrioriteMachine := P ;//recopie de la prioritée souhaitée passée en paramètres
end ; procedure TMachine.LibereJeton ;
{ Libère le jeton contenu par la trame que l'on vient de recevoir. } begin Socket.LibererJeton ; // libération du jeton end ; procedure TMachine.DonneeRecopiees ;
{ Modifie la trame pour indiquer que les données contenues dans cette trame reçue ont bien été recopiées par notre machine (dans le cas où notre machine est la destinataire bien entendu), afin d'indiquer à la machine émettrice que le message a bien été acheminé. C'est la procedure RecopieDonneesOK de la classe Trame qui s'occupe de modifier l'etat des variables de l'objet Trame en conséquence. } begin
Annexes
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
Socket.RecopieDonneesOK ; // notification de données bien recopiées end ; function TMachine.getAdresse : integer ;
{ Accesseur à la variable privée "Adresse" de la machine } begin result := Adresse ; // on renvoie l'adresse de la machine end ; function TMachine.getDonnees : String ;
{ Accesseur à la variable privée "Donnees" de la machine } begin result := DonneesRecues ; // on renvoie les données qu'ona reçu end ; function TMachine.getAdresseSource : integer ;
{ Accesseur à la variable privée "AdresseSource" de la machine } begin
// on renvoie l'adresse de l'expéditeur du dernier message reçu : result := SourceMsg ; end ; procedure TMachine.Clignoter ;
{ Fait clignoter la fenetre d'infos de la machine. Cette procédure est complétée par l'action effectuée lors de l'activation du timer TimerBlink. En effet cette procédure colore en vert la fenetre d'info et active TimerBlink Puis au premier decompte de TimerBlink, celui-ci remet la couleur de la fenetre d'infos à sa valeur standard et se désactive tout seul.
Annexes
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
} begin Color := clLime ; // coloration en vert de la fnetre TimerBlink.Enabled := true ; // activation du Timer TimerBlink end ;
////////////////////////////////////////////////////////////////// ///////////// // Procédures déclanchées par une action sur la feuille graphique : /////////// ////////////////////////////////////////////////////////////////// ///////////// procedure TMachine.BEnvoyerMsgClick(Sender: TObject);
// action du bouton envoyer message var msg : String ; begin
// affection du message à envoyer contenu dans la fenetre de saisie msg := EDonneesAenvoyer.Text ;
{ s'il rien n'a été entré dans la zone de saisie du message à envoyer, ou dans la zone de saisie de l'adresse du destinataire ou enfin dans la zone de saisie de la priorité : } if ((msg = '') or (EAdresseDest.Text = '') or (EPrioriteDesiree.Text = ''))
// alors on affiche un message d'erreur à l'écran pour le signaler : then ShowMessage('Veuillez remplir correctement le formulaire d''envoi') else // si il n'y a pas d'erreur de saisie : begin
// si le cercle d'attente est colorié en jaune, c'est qu'on a déjà // un message en attente if CercleAttente.Brush.Color = clYellow then
// alors on le signale avec un message d'erreur : ShowMessage('Vous avez déjà un message en attente')
Annexes
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
else // sinon on envoie le message : begin
// déclanchement de la procédure d'envoi de message : EnvoyerDonnees(msg,StrToInt(EAdresseDest.Text), StrToInt(EPrioriteDesiree.Text)) ;
// le cercle d'attente se colorie en jaune pour dire qu'on attend CercleAttente.Brush.Color := clYellow ;
// on éteint le voyant de réception de message : CercleReception.Brush.Color := clMoneyGreen ;
// on éteint le voyant d'erreurs : CercleErreur.Brush.Color := clMoneyGreen ;
// on affiche le bouton d'annulation d'envoi de messages : BAnnulerEnvoi.Visible := true ; end ; end ; end; procedure TMachine.BitBtn1Click(Sender: TObject);
// action du bouton situé à droite de la zone de réception du texte begin
{ effacement des zones de textes ou seront affichées les données reçues et l'adresse de l'expéditeur : } EDonneesRecues.Text := ' '; EAdresseRecue.Text := ' ' ; end; procedure TMachine.TimerBlinkTimer(Sender: TObject);
// action du Timer TimerBlink begin TimerBlink.Enabled := false ; // arret du Timer // la couleur de fond de la fenetre est remise à sa valeur par défaut : Color := CouleurFond ; end;
Annexes
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
procedure TMachine.BAfficheEnvoieClick(Sender: TObject);
// action du bouton "+" pour développer la fentre begin height := 346 ;//agrandissement de la fentre pour afficher les options d'envoi end; procedure TMachine.BMasqueEnvoieClick(Sender: TObject);
// action du bouton "-" pour réduire la fentre begin
// réduction de la taille de la fenetre pour cacher les options d'envoi height := 144 ; end; procedure TMachine.BAnnulerEnvoiClick(Sender: TObject);
// action du bouton annuler envoi begin BAnnulerEnvoi.Visible := false ; // on cache ce bouton VeutEnvoyerDonnees := false;//on signale qu'on ne veut plus envoyer de données // on indique sur la fentre qu'on ne veut plus capturer le jeton LVeuxJeton.Caption := 'Non' ; CercleAttente.Brush.Color := clMoneyGreen ; // on eteint le voyant d'attante end; end. // Fin de l'unité U_Machine
Classe TMoniteur unit U_Moniteur; interface uses Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, StdCtrls, ExtCtrls, Buttons, U_Trame, U_Machine ;
Annexes
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
type TMoniteur = Class(TMachine) public { Déclarations Publiques } procedure Initialisation(adr : integer) ; override ; function CreerJeton : Trame ; procedure RecevoirTrame(T : Trame); override ;
end ; implementation procedure TMoniteur.Initialisation(adr : integer) ; begin
{ memes insctruction que dans la classe TMachine : voir les explications dans cette classe : } Adresse := adr ; VeutEnvoyerDonnees := false ; Socket := nil ; DonneesRecues := '' ; SourceMsg := 0 ; Caption := 'Contrôle de la Machine ' + IntToStr(Adresse) ; Titre1.Caption := 'Machine n° ' + IntToStr(adresse) ; Titre1.Width := 148 ; SetBounds(0,Adresse*70,256,144); BAnnulerEnvoi.Visible := false ; PrioriteMachine := 1 ; PrioriteSauve := 1 ; FormStyle := fsStayOnTop ;
///////////////////////////////////////////////////// //////////// Fonctions du moniteur : //////////////// ///////////////////////////////////////////////////// // rajout de la mention "est Moniteur" dans le titre de la fenetre : Caption := Caption + ' : est Moniteur' ;
// rajout de la mention "Moniteur" dans le titre au debut de la fenetre : Titre1.Caption := Titre1.Caption + ' : Moniteur' ;
// Changement de couleur pour distinguer le moniteur : // Les titres en blanc : Titre1.Font.Color := clWhite; LEnvoiMess.Font.Color := clWhite;
//le fond de la fenetre et ce qui la compose en orange :
Annexes
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
CercleAttente.Brush.Color := $0058BEF5; CercleReception.Brush.Color := $0058BEF5; CercleErreur.Brush.Color := $0058BEF5; Shape2.Brush.Color := $0058BEF5; // la fenetre en orange CouleurFond := $0058BEF5 ; Color := $0058BEF5 ; end ; function TMoniteur.CreerJeton : Trame ;
// fonction qui crée et retourne une trame vierge var laTrame : Trame ; begin laTrame := Trame.create ; // création d'une trame vierge result := laTrame ; // renvoi de la trame crée end ; procedure TMoniteur.RecevoirTrame(T : Trame); begin new(Socket) Socket^
; :=
T
;
///////////////////////////////////////////////////// //////////// Fonctions du moniteur : //////////////// ///////////////////////////////////////////////////// // Retire les trames qui on fait plus d'un tour sur le reseau : // on incremente le compteur de passage devant le Moniteur : Socket.IncremanteCptMoniteur ;
// si la trame est passée plus d'une fois devant le moniteur : if Socket.getCompteurMoniteur > 1 then begin Socket.LibererJeton ; // on libere le Jeton // si la priorité du jeton est égale à la priorité réservée du jeton : if Socket.getPriorite = Socket.getPrioriteReservee then begin //Réinitialisation des Priorités avec perte des anciennes réservations Socket.AffecterPriorite(1); // on met la priorité du jeton à 1 Socket.AffecterReservation(1); // on met la priorité réservée du jeton à 1 end // Sinon affetaction au jeton de la derniere prioritée
Annexes
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
résevée else Socket.AffecterPriorite(Socket.getPrioriteReservee) ; end ;
////////////////////////////////////////////////////// //////////// Fonctions de la Machine : /////////////// /// Voir les Excplications dans la Classe TMachine /// ////////////////////////////////////////////////////// if Socket.getOccupe then // c'est à dire si le jeton n'est pas libre begin if Socket.getAdresseDestination = Adresse then begin RecopierDonnees ; EDonneesRecues.Text := DonneesRecues ; EAdresseRecue.Text := IntToStr(SourceMsg) ; Clignoter ; Socket.RecopieDonneesOK ; end ; if Socket.getAdresseSource = Adresse then begin if not Socket.getDonneesRecopiees then CercleErreur.Brush.Color := clRed else CercleReception.Brush.Color := clGreen ; CercleAttente.Brush.Color := clMoneyGreen ; LibereJeton ;
// if (Socket.getPriorite <> 1) then // passage/remise du jeton Socket.AffecterPriorite(Socket.getPrioriteReservee); end ; if VeutEnvoyerDonnees then // on procède alors à la Réservation : begin if (PrioriteMachine > Socket.getPrioriteReservee) then begin PrioriteSauve := Socket.getPrioriteReservee ; Socket.AffecterReservation(PrioriteMachine) ; end ; end ; end else // c'est à dire si le jeton est libre begin if VeutEnvoyerDonnees then begin
Annexes
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
if (PrioriteMachine >= Socket.getPriorite) then begin CapturerJeton ; Socket.AffecterPriorite(PrioriteMachine); Socket.AffecterReservation(PrioriteSauve) ; PrioriteSauve := 1 ; VeutEnvoyerDonnees := false ; BAnnulerEnvoi.Visible := false ; LVeuxJeton.Caption := 'Non'; Socket.CreerJeton(Adresse,DonneesEnAttente.dest,DonneesEnA ttente.msg) ; end ; end ; end ; EnvoyerTrame ;
end ; end. // Fin de l'unité U_Moniteur
Classe Reseau unit U_Reseau; interface uses U_Trame, U_Machine, U_Moniteur, U_Controle_Trame ;
type Reseau = class private { Déclarations Privées } TableauMachinesInscrites : array[1..30] of TMachine ;
{ Tableau contenant les machines inscrites Les positions du tableau coorespondent aux adresses des Machines } NombreMachinesPresentes : integer ;
{ Nombres de Machines présentes sur le réseau Attention! des machines peuvent êtres présentes mais nonconnectées !!! } laTrame : Trame ;
// La seule et unique trame qui circule sur le Reseau Indexeur : integer ;
{ Indique l'adresse de la Machine où la Trame est arretée
Annexes
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
actuellement En d'autres termes : à quelle machine est-ce le tour ? } leMoniteur : TMoniteur ;
// Le seul et unique Moniteur du Reseau public { Déclarations Publiques } constructor create ; procedure AjouterMachine ; overload ; procedure AjouterMachine(adr : integer) ; overload ; procedure AjouterMoniteur(adr : integer) ; procedure DesigneMoniteur ; procedure DeconnecterMachine(adr : integer) ; procedure ReconnecterMachine(adr : integer) ; procedure PasseSuivant ; procedure InitControleTrame ; procedure RebootIndexeur ; function Existe(Adr : integer) : boolean ; function getIndexeur : integer ; function getMachine(adresse : integer) : TMachine ; function getNombrebMachinesPresentes : integer ;
// presentes mais pas forcement actives !! function getMoniteur : TMoniteur ; function estMoniteur(Adr : integer) : boolean ;
end ; implementation constructor Reseau.create ;
{ Constructeur d'objets de la classe Reseau. Initialise les valeurs de celui-ci pour obtenir un réseau "vierge", c'est à dire ne contenant aucunes machines présentes, puis ajoute seulement une machine moniteur, crée la trame du réseau et positionne l'indexeur à 0. Ainsi au lancement du réseau la Trame passera en premier par la machine 1 qui est le moniteur. } begin NombreMachinesPresentes := 0 ; // il n'y a pas de machines présentes au depart DesigneMoniteur ; // création et désignation du moniteur actif // création et désignation de la trame circulante sur le reseau :
Annexes
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
laTrame := leMoniteur.CreerJeton ;
// positionnement de l'indexeur à la position 0, donc just'avant la machine 1 indexeur := 0 ; end ; procedure Reseau.AjouterMachine ;
{ Ajoute une machine en lui affectant l'adresse qui suit le nombre de machines qui étaient présentes juste avant sur le réseau, et initialise cette machine } begin
// on augmente de 1 le nombre de machines présentes sur le Reseau : NombreMachinesPresentes := NombreMachinesPresentes + 1 ;
// création d'une machine et inscription de cette machine sur le réseau TableauMachinesInscrites[NombreMachinesPresentes] := TMachine.create(Machine) ;
// initialisation de la machine précédemment ajoutée sur le réseau TableauMachinesInscrites[NombreMachinesPresentes].Initialisation (NombreMachinesPresentes); end ; procedure Reseau.AjouterMachine(adr : integer) ;
{ Procedure de surcharge de la procedure "AjouterMachine" sans paramètres précédente. Ici on ajoute une machine comme précédement sauf qu'on lui attribue l'adresse spécifiée par le paramètre adr spécifié en entrée. } begin
// création d'une machine et ajout à l'adresse passée en paramètres : TableauMachinesInscrites[adr] := TMachine.create(Machine) ;
// initialisation de la machine précédement crée :
Annexes
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
TableauMachinesInscrites[adr].Initialisation(adr);
// augmentation de 1 du nombre de machines présentes sur le Reseau : NombreMachinesPresentes := NombreMachinesPresentes + 1 ; end ; procedure Reseau.AjouterMoniteur(adr : integer) ;
{ Ajoute un moniteur sur le réseau en lui affectant l'adresse spécifié par l'entier adr, puis initialise ce moniteur. } begin
// création du Moniteur et inscription de celui-ci sur le réseau à l'adresse // passée en paramètres : TableauMachinesInscrites[adr] := TMoniteur.create(Machine) ;
// initialisation du moniteur précédement crée : TableauMachinesInscrites[adr].Initialisation(adr);
// augmentation de 1 du nombre de machines présentes sur le Reseau : NombreMachinesPresentes := NombreMachinesPresentes + 1 ; end ; procedure Reseau.DesigneMoniteur ;
{ Désigne l'unique moniteur actif du Réseau en affactant à la variable "leMoniteur" l'adresse de la machine qui joue le rôle de moniteur. Dans ce projet, le moniteur par défaut possédera toujours l'adresse 1. } begin AjouterMoniteur(1) ; // on ajoute le moniteur sur le reseau // on désigne ce Moniteur comme moniteur actif : leMoniteur := TMoniteur(TableauMachinesInscrites[1]) ; end ; procedure Reseau.DeconnecterMachine(adr : integer);
Annexes
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
{ Deconnection d'une machine en supprimant l'objet référencé par l'emplacement du tableau à la position spécifiée par l'entier adr et libération de l'espace mémoire. } begin
//suppression dans le tableau de la référence de la machine passé en paramètre TableauMachinesInscrites[adr] := nil ; TableauMachinesInscrites[adr].Free ; // libération de l'espace mémoire end ; procedure Reseau.ReconnecterMachine(adr : integer) ;
{ Reconnecte la machine ayant pour adresse l'entier adr précédement déconnectée, lui affecte la même adresse et réinitialise cette machine. } begin
// création de la machine et ajout à l'adresse passée en paramètres : TableauMachinesInscrites[adr] := TMachine.create(Machine) ;
// initialisation de la machine précédement crée : getMachine(adr).Initialisation(adr) ; end ; procedure Reseau.PasseSuivant ;
{ Virtuellement cette procédure simule le passage d'une trame d'une machine à la machine suivante sur le réseau.Concrètement dans ce projet le passage de trame à la machine suivante est effectué par le réseau qui lance la procédure "RecevoirTrame" de la machine qui suit celle qui vient d'effectuer toutes ses opérations. Le tour de la machine suivante est indiqué par l'indexeur précédement incrémenté. Une vérification sur l'existence de la machine est effectuée avant d'essayer de déclencher sa procédure 'RecevoirTrame".
Annexes
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
La procedure "Rafraichissment" de la classe "Controle_Trame" est également lancée afin de rafraichir la fenetre d'informations qui concerne la Trame circulant sur le Reseau. } begin indexeur := indexeur + 1 ; // incrémentation de l'indxeur
{ si l'indexeur est suppérieur au nombres de machines présentes sur le réseau, c'est que la trame a fait fait un tour complet. On remet donc cet indexeur à 1 pour que la trame revienne à la machine 1 : } if indexeur > NombreMachinesPresentes then indexeur := 1 ;
{ si la machine référencée par la position de l'indexeur existe, alors on déclenche la procédure RecevoirTrame de cette machine : } if Existe(indexeur) then TableauMachinesInscrites[indexeur].RecevoirTrame(laTrame) ;
// Rafraichissement de la fenetre de controle de la trame : Controle_Trame.Rafraichissement ; end ; procedure Reseau.InitControleTrame ;
{ Declanche simplement la procedure "Initialisation" de la classe Controle_Trame avec pour paramètre la Trame associée au réseau. Ceci sert à associer au reseau une fentre de controle de la trame circualante et d'initialiser cette fenetre en une seule procedure accessible par la classe Reseau. } begin
// initialisation de la fentre controle_trame : Controle_Trame.Initialiation(laTrame); end ; procedure Reseau.RebootIndexeur ;
{ Affecte la valeur Zero à la variable "Indexeur". L'utilité de
Annexes
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
cette procédure vient du fait que la variable "Indexeur" soit privée, et que cette opération sera utilisée lorsqu'on change de mode de simulation du reseau : la Trame reviendra alors juste avant la machine 1. } begin Indexeur := 0 ; // remise à Zero de l'indexeur end ; function Reseau.Existe(Adr : integer) : boolean ;
{ Teste l'existance et surtout la connectivité de la machine désignée par l'adresse Adr. Renvoie alors une valeur vrai si la machine existe, faux sinon. } begin
{ si la case du tableau référencée par l'entier Adr est null on renvoie faux, et vrai sinon : } if TableauMachinesInscrites[Adr] = nil then result := false else result := true ; end ; function Reseau.getIndexeur : integer ;
{ Accesseur à la variable privée "Indexeur" } begin result := Indexeur ; // on renvoie l'indexeur end ; function Reseau.getMachine(adresse : integer) : TMachine ;
{ Accesseur à la machine désignée par l'adresse entrée en paramètre. L'utilitée de cette fonction est due au fait que la variable "TableauMachinesInscrites" soit privée, rendant ainsi les machines inaccessibles. } begin
Annexes
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
//on renvoie la machine pointée par la case à l'emplacement adresse du tableau result := TableauMachinesInscrites[adresse] ; end ; function Reseau.getNombrebMachinesPresentes : integer ;
{ Accesseur à la variable privée "NombresMachinesPresentes". Attention! Des machines peuvent êtres présentes mais nonconnectées !!! } begin // on renvoie l'enitier NombreMachinesPresentes : result := NombreMachinesPresentes ; end ; function Reseau.getMoniteur : TMoniteur ;
{ Accesseur à la variable privée "leMoniteur" } begin result := leMoniteur ; // on renvoie le Moniteur actif du reseau end ; function Reseau.estMoniteur(Adr : integer) : boolean ;
{ Teste si la machine désignée par l'adresse Adr entrée en paramètre possède la fonction de moniteur du réseau. Renvoie alors vrai si cette machine est le moniteur, faux sinon. } begin if (TableauMachinesInscrites[Adr] = leMoniteur) then result := true else result := false ;
end ; end. // Fin de l'unité U_Reseau
Annexes
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
Classe Trame unit U_Trame; interface type Trame = class private { Déclarations Privées } Occupe : boolean ;
// Etat du Jeton : Libre ou Occupe Donnees : String ;
{ Donnees contenues dans la trame. Dans ce projet on se bornera à la simplification Donnees = Chaine de caractères } AdresseSource : integer ;
// Adresse de la machine qui émet la Trame : l'Emetteur AdresseDestination : integer ;
// Adresse de la machine qui doit recevoir la Trame : le Destinataire DonneesRecopiees : boolean ;
{ Indique si les données contenues dans la Trame ont été recopiées par la machine destinataire } Priorite : integer ;
// Priorité actuelle du Jeton PrioriteReservee : integer ;
// Priorité réservée par une machine pour le prochain jeton CompteurMoniteur : integer ;
// Compteur du nombre de passages par la machine Moniteur public { Déclarations Publiques } constructor create ; procedure CapturerJeton ; procedure LibererJeton ; procedure CreerJeton (aSource : integer ; aDest : integer ; data : String);
Annexes
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
procedure AffecterPriorite(P : integer) ; procedure AffecterReservation(R : integer) ; procedure IncremanteCptMoniteur ; procedure RecopieDonneesOK ; function LireTrame : String ; function getAdresseDestination : integer ; function getAdresseSource : integer ; function getOccupe : boolean ; function getDonneesRecopiees : boolean ;
//function getDonnees : String ; function getPriorite : integer ; function getPrioriteReservee : integer ; function getCompteurMoniteur : integer ; end ;
implementation constructor Trame.create ;
{ Constructeur d'objet de Type Trame. Celui-ci s'occupe également d'initialiser les variables de la trame à des valeur vierges (c'est à dire Jeton libre, pas de données contenues, priorité à 1, etc ...). } begin Occupe := false ; // le jeton n'est pas occupé à sa création Donnees := '' ; // il n'y a pas de données contenues dans le jeton AdresseSource := 0 ; // l'adresse de l'expéditeur est 0 car inexistante AdresseDestination := 0 ; // l'adresse du destinatire est 0 car inexistante // les données n'ont pas été recopiées car il n'y a pas de données : DonneesRecopiees := false ; Priorite := 1 ; // la priorité du jeton à sa création est de 1 PrioriteReservee := 1 ; // la priorité réservé du jeton à sa création est de 1 // le jeton qui vient d'etre créé n'est pas encore passé devant le moniteur : CompteurMoniteur := 0 ; end ; procedure Trame.CapturerJeton ;
{ Simule la capture du Jeton : celà se concrétise par
Annexes
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
l'affectation de la valeur vrai au booléen Occupe, qui indique donc que le Jeton est occupé. } begin Occupe := true ; // le jeton est définit comme occupé CompteurMoniteur := 0 ; // remise à zero du compteur au passsage de moniteur end ; procedure Trame.LibererJeton ;
{ La libération du jeton est en fait une réinitialisation des valeurs des variables de l'objet Trame : le Jeton n'est plus occupé, il n'y a plus de données contenues, le Compteur de passages au moniteur est remis à 0, etc ... } begin Occupe := false ; // le jeton n'est plus occupé Donnees := '' ; // effacement des données contenues dans le jeton AdresseSource := 0 ; // effacement de l'adresse de l'expéditeur AdresseDestination := 0 ; // effacement de l'adresse du destinataire // les données n'ont pas été recopiées car il n'y a pas de données : DonneesRecopiees := false ; CompteurMoniteur := 0 ; // remise à zero du compteur au passsage de moniteur end ;
procedure Trame.CreerJeton (aSource : integer ; aDest : integer ; data : String);
{ Définit un nouveau Jeton à partir des informations que sont : l'adresse de l'emetteur, l'adresse du destinataire et les données à envoyer En revanche le passage au status "Jeton Occupé" n'est pas effectué par cette procédure mais par la procédure "CapturerJeton" } begin
Annexes
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
AdresseSource := aSource ; // affectation de l'adresse de l'expéditeur AdresseDestination := ADest ; // affectation de l'adresse du destinataire Donnees := data ; // affectation des données // signalement que les données n'ont pas été recopiées : DonneesRecopiees := false ; end ; procedure Trame.AffecterPriorite(P : integer) ;
{ Affecte une priorité au Jeton à partir de l'entier P } begin Priorite := P ; // affectation de la priorité end ; procedure Trame.AffecterReservation(R : integer) ;
{ Affecte une priorité de réservation au Jeton à partir de l'entier R } begin PrioriteReservee := R ; // affectation de la priorité réservée end ; procedure Trame.IncremanteCptMoniteur ;
{ Incrémante de 1 le compteur de passages par la machine moniteur } begin
// incrémentation du compteur de passage devant le moniteur : CompteurMoniteur := CompteurMoniteur + 1 ; end ; procedure Trame.RecopieDonneesOK ;
{ Fait passer le booleen DonneesRecopiees à vrai pour indiquer que la machine destinatrice a bien recopiées les données (cette procédure doit donc etre eppelée par la machine destinatrice uniquement). } begin
Annexes
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
DonneesRecopiees := true ; // signal que les données ont bien été recopiées end ; function Trame.LireTrame : String ;
{ Accesseur à la variable privée "Donnees" } begin result := Donnees ; // ont renvoi les données end ; function Trame.getAdresseDestination : integer ;
{ Accesseur à la variable privée "AdresseDestination" } begin result := AdresseDestination ; // on renvoi l'adresse du destinataire end ; function Trame.getAdresseSource : integer ;
{ Accesseur à la variable privée "AdresseSource" } begin result := AdresseSource ; // on renvoi l'adresse de l'expéditeur end ; function Trame.getOccupe : boolean ;
{ Accesseur à la variable privée "Occupe" } begin result := Occupe ; // on renvoie la valeur du booleen Occupe end ; function Trame.getDonneesRecopiees : boolean ;
{ Accesseur à la variable privée "DonneesRecopiees" } begin
Annexes
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
result := DonneesRecopiees ; // renvoie la valeur du booleen DonneesRecopiees end ; function Trame.getPriorite : integer ;
{ Accesseur à la variable privée "Priorite" } begin result := Priorite ; // on renvoie la priorité du jeton end ; function Trame.getPrioriteReservee : integer ;
{ Accesseur à la variable privée "PrioriteReservee" } begin result := PrioriteReservee ; // on renvoie la priorité réservée du jeton end ; function Trame.getCompteurMoniteur : integer ;
{ Accesseur à la variable privée "CompteurMoniteur" } begin // on renvoie la valeur du Compteur de Passage devant le Moniteur : result := CompteurMoniteur ; end ; end. // Fin de l'unité U_Trame
Annexes
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
D. Schémas légendés des composants présents dans les fenêtres
figure 22.
figure 23.
Annexes
Schéma légendé d’une fenetre d’une Machine
Schéma légendé de la fenêtre de contrôle de la Trame
Simulation d’un réseau Token Ring
figure 24.
figure 25.
Annexes
Erwan Charlier & Grégory Denize
Schéma légendé du mode Animation
Schéma légendé du mode Pas à pas
Simulation d’un réseau Token Ring
figure 26.
Annexes
Erwan Charlier & Grégory Denize
Schéma légendé du mode Temps Réel
Simulation d’un réseau Token Ring
Erwan Charlier & Grégory Denize
E. Carnet de suivi du projet Plutôt que de fournir un carnet de bord papier, nous avons utiliser tout au long de notre projet un logiciel de suivi de projet, GanttProject. Ce logiciel est lui aussi un logiciel issu d’un projet réalisé par des étudiants de l’IUT de Marne la Vallée. Les auteurs de ce logiciel ayant quitté l’IUT mais continu le développement pour leur compte. C’est un logiciel Open Source, écrit en Java, permettant de réaliser des diagrammes de Gantt avec un détails pour chaque tâche. Il permet d’exporter un dossier de suivi avec la liste des différentes tâches, leurs enchaînements, mais aussi avec le diagramme de Gantt et un diagramme des ressources dans différents formats (XML, PNG, PDF ou JPG). Il permet même de créer un site Internet pour la consultation en ligne de l’avancement d’un projet. Vous pouvez librement le http://ganttproject.sourceforge.net/
Annexes
télécharger
à
l’adresse
suivante :
Simulation d’un réseau Token Ring
CD_ROM
Erwan Charlier & Grégory Denize
Résumé Ce rapport décrit la manière dont nous avons travaillée sur notre projet de seconde année de DUT Informatique. Notre projet, sous tutorat de M. Miara, consistait à développer un support de cours pour expliquer aux étudiants le principe de fonctionnement d’un réseau Token Ring. Nous avons utilisé une méthode d’analyse orienté objet (UML) et un langage événementiel pour mener à bien ce projet. L’analyse a été faite en commun, puis nous nous sommes séparées les différentes tâches à réaliser, et nous avons opté pour un développement en serie. Notre solution donne à l’utilisateur les mêmes fonctionnalités qu’il pourrait avoir avec un vrai réseau, comme par exemple la possibilité de connecter / déconnecter une machine, d’envoyer des messages entre les différentes machines et de contrôler leurs circulation sur le réseau. L’interface ergonomique lui permet une certaine aisance pour réaliser ces tâches, et lui permet surtout un rendu visuel des résultats. Par manque de temps, nous n’avons pas pu implémenter certaines fonctionnalités du protocole comme l’élection du moniteur, mais cela pourra être rajouter par la suite. Mots-clés: Simulation, pédagogique, Token Ring, Delphi, réseau, ergonomie.
Summary This document describes the work we carried out during our second year project at the IUT. Mr Miara tutors this project. The subject of our project is “Token Ring Simulation software”. It consisted in developing a piece of educational software, which explains the main principles of Token Ring protocol for network courses. To develop this software we used a factual programming language, Borland Delphi and UML (Unified Modelling Language) for analysis. We done the analysis together, and then, we separated the different tasks to each other. A working method based on a serial developing was used to achieve this project. Our software give to the user functionalities that he could do with a real network, with an ergonomic interface, like connect/disconnect a computer, send messages to the other computers, but we didn’t develop all the protocol functionalities (lack of time). In a nearest future, we will be able to integrate to this piece of software some new functionality like monitor’s election. Keywords: Simulation, educational, Token Ring, Delphi, network, ergonomics.