SYNTHESE PROJET RESEAUX -...

Cheung HI Stephanie Ienac 05L

Claudel Emilie Janvier 2008

SYNTHESE PROJET RESEAUX

Version 3.1

Développement et déploiement d’une application distribuée d’administration pour le parc de machines de la subdivision ELR.

Encadrants : GARCIA Fabien

LARRIEU Nicolas

Rapport réseau version 3.1 Emilie Claudel

Stéphanie Cheung Hi

2

Remerciements :

Nous tenons simplement à remercier nos encadrants, MM Fabien Garcia et Nicolas

Larrieu, pour leur patience, leur disponibilité, et leurs précieux conseils.



3

Table des matières

Avant Propos…………………………………………………………………………5

I/ Introduction…………………………………………………………………………6

I°) Objectifs du projet ……………………………………………………………………….6

2°) Problématique…………………………………………………………………………...6

II/ Généralités………………………………………………………………………...7

1°) Généralités ………………………………………………………………………………7

a/ le protocole tcp/ip…………………………………………………………7

b/ plan d’adressage: l’unicast et le multicast …………………………….9

2°) Notre projet dans le cadre d’une application répartie……………………………….9

3°) Architecture réseau……………………………………………………………………10

a/ le modèle peer to peer………………………………………………….10

b/ le modèle client/serveur………………………………………………...10

4°) l’API socket……………………………………………………………………………..12

5°) Les structures ………………………………………………………………………….13

6°) Les listes chaînées…………………………………………………………………….13

III/ La conception de l’application……………………………………………….14

1°) Cahier des charges……………………………………………………………………14

2°) Analyse de la conception……………………………………………………………..15

a/ La structure générale……………………………………….……..……15

b/ Protocoles, flux de données…………………………………………..18

3°) Schémas fonctionnels…………………………………………………………………22

4°) Fonctionnalités…………………………………………………………………………25

5°) Un exemple concret……………………………………………………………….…..36

6°) Plan de test……………………………………………………………………………..38

7°) Conclusion sur la conception…………………………………………………………40



4

IV/ Le développement de l’application…………………………………………41

1°) Choix techniques……………………………………………………………………..41

2°) Tests réalisés…………………………………………………………………………45

3°) Conclusion sur le développement………………………………………………….46

V/ Déploiement et bilan…………………………………………………………..47

VI/ Conclusion générale………………………………………………………….47

ANNEXES : Bibliographie.…………………………………………………………………..48

Gestion de projet………………………………………………………………49



5

Avant Propos

Jusqu’à présent, la gestion de la salle G17, salle dédiée à la réalisation de TPs réseaux pour les différentes formations de l’ENAC, est pour un administrateur une tâche fastidieuse et coûteuse en temps. En effet, la gestion de chacun des postes de la salle nécessite que l’administrateur réseau intervienne sur chacun de ces postes et rentre manuellement des commandes soit pour les mettre dans la configuration désirée soit pour vérifier leur mise à jour.

Ainsi, il a été décidé cette année de confier l’élaboration d’un logiciel d’administration à distance des différents postes de la salle G17 à des étudiants IENAC 05L dans le cadre de leur projet. L’objectif principal de ce projet, est donc de permettre à l’administrateur de la salle un gain de temps et une meilleure vision globale des différentes configurations dans lesquelles se trouvent les machines.

De ce fait, l’objet de ce rapport est donc d’exposer la démarche qui a été la notre durant toute la durée de ce projet, mais également de fournir à terme le logiciel d’administration à distance ainsi que son guide d’utilisation.



6

I/ Introduction

I°) Objectifs du projet

Le projet consiste donc dans sa première partie à étudier les différents modules destinés à la réalisation d’applications réparties répondant aux besoins forts de l’administrateur en terme de gestion de configuration et de supervision du réseau dans son ensemble. Ainsi, à l’issue de cette étude, une documentation détaillée des différents modules sera élaborée et servira de support pour toute la partie développement du logiciel.

La deuxième phase aura alors pour objet de déployer le logiciel sur le poste administrateur de la salle G17 et de vérifier les performances du logiciel dans son environnement opérationnel.

Une fois ces opérations réalisées, il ne nous restera donc plus qu’à procéder à la rédaction du guide d’utilisation du logiciel et à livrer ce logiciel d’administration réseau aux clients en question.

Nous n’aurons pas le temps de développer intégralement l’application, la conception devra donc être la plus précise et détaillée possible afin de faciliter le travail du groupe d’élèves suivant.

2°) Problématique

La salle G17 étant une salle souvent utilisée par des promotions différentes, il faut que son administration soit la plus aisée et rapide possible. L’objet de notre étude sera donc de concevoir une application d’administration à distance d’une salle réseau.



7

II/ Généralités

Lors de notre projet, nous avons utilisé des notions sur les réseaux que nous présenterons ici dans un premier temps.

1°) Généralités

Un réseau informatique permet l’échange d’informations entre des systèmes informatiques. Il doit permettre la coopération entre applications informatiques sans avoir à tenir compte de l’hétérogénéité des moyens et des techniques de transmission.

a/ le protocole tcp/ip

TCP/IP est une famille de protocole permettant l’interconnexion des réseaux sur une base planétaire.

La couche réseau (3) est réalisée par le protocole IP, qui gère l’acheminement des paquets pour les couches supérieures sans connexion, sans garantir d’ordre ni de bon acheminement. On identifie la machine cible par son adresse IP.

La couche transport (4) peut être assurée par deux protocoles : TCP et UDP qui fixent les caractéristiques de la communication.

- TCP fournit une communication en mode connecté, fiable avec acquittements, contrôle d’erreurs, contrôle de flux et l’ordre des paquets est assuré.

- UDP fournit une communication en mode non connecté, sa,s contrôle de flux, sans acquittement, l’ordre des messages n’étant pas assuré.

On identifie un service particulier sur une machine distance par un numéro de port.

TCP/IP

Media

IP

TCP UDP

Applications

(http, smtp, pop…)

1-2

3

4

5-7



8

TCP :

UDP :

Machine A Machine B

Syn

Syn ack

Ack

data

ack

Fin

Fin

Ack

Ack

Ouverture active

Ouverture passive

Ouverture réussie

Fermeture active

Fermeture passive Confirmation de déconnexion

Confirmation de déconnexion

Ouverture d’une connexion

Transmission de données

Fermeture d’une connexion

Machine A Machine B

data

data

requête

réponse



9

b/ plan d’adressage: l’unicast et le multicast

Dans le protocole TCP/IP, le routage des segments d’une machine émettrice vers une machine destinatrice se fait en utilisant des adresses IP.

Il existe plusieurs types de communication :

- l’unicast : vers un seul destinataire

- le broadcast : vers tous

- l’anycast : de un à un parmi plusieurs

- le multicast : vers le abonnés.

Une machine écoute sur son adresse IP, en broadcast, et sur l’adresse multicast de son groupe.

Une adresse multicast est une adresse de classe D (224.0.0.0 ->239.255.255.255)

2°) Notre projet dans le cadre d’une application répartie

Dans le cadre de ce projet, nous envisageons le mécanisme d’application répartie, en terme de répartition des données sur les différents postes via un modèle client/serveur.

L’utilisation de machines en réseau étant maintenant classique, il est intéressant de pouvoir utiliser les ressources disponibles à travers le réseau et de pouvoir agir à distance sur les machines.

La distribution permettra d’apporter de la transparence à l’utilisateur lors de l’accès aux ressources disponibles sur le réseau. Cela, lui masquera par exemple tous les problèmes d’accès au réseau

Cela permettra également de répartir et stocker les données de manière plus équitable sur les différents postes du réseau et donc de ne pas consommer toutes les ressources mémoire d’une seule CPU.

Pour cela (pour pouvoir avoir accès à ces données à distance et ainsi gérer les applications de manière répartie), il est possible d’utiliser un modèle client serveur, basé sur des communications utilisant les sockets.

Une application informatique est dite répartie lorsqu’elle met en jeu des parties qui s’exécutent sur plusieurs machines reliées par un système de communication.

Ainsi, la construction de notre application repose sur :

• l’identification des éléments fonctionnels de l’application pour les regrouper ensuite au sein d’unité

• l’estimation de l’interaction entre ces unités

• la définition du schéma d’organisation.



10

3°) Architecture réseau :

On se place dans le contexte d’applications réparties, les machines sont donc

interconnectées sans mémoire commune.

Il existe plusieurs types d’architectures d’applications réseau.

On peut par exemple citer :

- le modèle peer to peer

- le modèle client/serveur

a/ le modèle peer to peer

Le modèle peer to peer, c’est à dire pair à pair, est un moyen de partage des ressources par échange direct, aucune donnée n’étant stockée sur un serveur. Ces architectures peuvent être centralisées à un ou plusieurs serveurs qui servent simplement d’index, ou décentralisées, c’est à dire que les machines communiquent directement entre elles.

b/ le modèle client/serveur

Le modèle client/serveur est un modèle de conception d’applications distribuées, il dirige la façon dont elles vont interagir entre elles. Ce sont des applications dont le rôle n’est pas symétrique, il y a d’un côté les requêtes, et de l’autre les réponses.

Le serveur est un programme offrant un service, il traite les requêtes des clients et leur envoie la réponse.

Le client est le programme qui contacte le serveur et qui émet des requêtes, il est toujours l’initiateur du dialogue.

On peut avoir plusieurs type d’architecture :

Tâche serveur Tâches clients

requêtes

réponses



11

- serveur centralisé, clients répartis (ex lecture de mail)

- serveurs répartis, client centralisé (ex : monitoring réseau)

Il existe plusieurs type de serveurs :

- serveur itératif : il ne sert qu’un seul client à la fois, il est utilisé dans le cas de requêtes courtes.

- serveur parallèle : il peut servir plusieurs clients (en créant plusieurs processus), il est utilisé dans le cas de requêtes plus longues ou d’un nombre important de clients.

- serveur en mode non connecté : il utilise le protocole UDP et ne peut traiter qu’une seule requête

- Serveur en mode connecté : il utilise le protocole TCP et permet un dialogue entre le client et le serveur.

Schéma utilisé dans notre projet :

Un modèle serveurs répartis (les daemons machines) et client centralisé (l’administrateur), en mode non connecté (système de mailbox) et en itératif.

serveur

serveur

serveur

serveur

client

C1 C2

S

C3

S1 S2

C

S3



12

4°) l’API socket

L’API socket est une interface de programmation applicable ( bibliothèque de fonctions

liée au langage C) permettant d’accéder au service transport, aussi bien en mode connecté (TCP) qu’en mode non connecté (UDP).

Un socket est un mécanisme général de communication entre deux processus locaux ou distants. C’est un point de communication, une prise, équivalente à un point d’accès au service transport (TSAP) (représentation interne), par lequel un processus pourra émettre ou recevoir des informations. On peut noter que ce mécanisme n’est pas spécifique au système d’exploitation utilisé. On caractérise un socket par son domaine, qui détermine les différents protocoles supportés et donne le format des adresses fournies aux sockets pour la communication (AF_INET), et par son type, qui détermine les propriétés et la nature de la communication (SOCK_DGRAM).

On veut faire communiquer des applications qui tournent sur des machines différentes.

On identifiera la tâche par son adresse transport (représentation externe):

- une adresse IP : c’est l’identification de la machine

- un numéro de port : c’est l’identification de la tâche (on le prendra >1024 pour être sûr d’éviter tout conflits avec les ports standards utilisés par le système)

Pour communiquer, on utilisera deux sockets : le socket serveur et le socket client.

client serveur

Socket d’écoute

Lecture info du socket client

Ne sert qu’à attendre la connexion et les infos sur

le client

Ecriture info

Socket de communication, où transitent les données

Connexion + infos client



13

Ces deux derniers paragraphes consistent à présenter de la manière la plus générale possible la définition et l’utilité d’une structure de manière à ce que des personnes n’ayant jamais manipulées ces types de données comprennent mieux son utilisation dans ce projet.

5°) Les structures

La différence entre un tableau et une structure :

Un tableau permet de regrouper des éléments de même type, à savoir codés sur le même nombre de bit et de la même façon. Toutefois, il est généralement utile de pouvoir regrouper des éléments de type différent tels que des chaînes de caractères avec des entiers.

C’est ainsi que les structures permettent de remédier à cette lacune des tableaux, en regroupant des objets (ou variables) au sein d’une entité repérée par un seul nom de variable.

Les objets contenus dans la structure sont appelés champs de la structure.

Exemple de structure :

6°) Les listes chaînées

Une liste chaînée est une structure comportant des champs contenant des données et un pointeur vers une structure de même type. Il est ainsi possible de parcourir la liste de structure en structure.

Structure Voiture {

Entier : n° immatriculation ;

Chaîne de caractère : Marque de la voiture ;

….

}

Champs de la structure



14

III/ La conception de l’application

1°) Cahier des charges (tel que levé du sujet)

Développement et déploiement d’une application distribuée d’administration pour le parc de machines de la subdivision ELR

Principe du projet : création et mise en place d’une application client-serveur pour permettre l’administration distribuée et à distance (déploiement, configuration et gestion de logiciels) des machines de la salle de TP G17 de la subdivision ELR.

Le projet consiste à étudier les principes de fonctionnement des applications client-serveur puis de développer une application qui implémente ce mode d’échange d’information afin de proposer les fonctionnalités décrites ci-dessous. Le langage de programmation devra être choisi parmi C, C++ ou JAVA. Le développement aura lieu sous environnement LINUX. L’application devra disposer d’une interface graphique pour faciliter son utilisation.

L’objectif minimal de l’application développée sera

- Déploiement distribué de logiciels depuis le client vers l’ensemble des serveurs.

- Configuration distribuée des logiciels déjà installé depuis le client vers l’ensemble des serveurs.

- Supervision du réseau pour permettre la détection des serveurs indisponibles ou qui nécessitent une mise à jour de leur configuration.

- « Pilotage » du serveur de façon distribuée par l’intermédiaire d’un client graphique.

L’objectif du projet est double :

- tout d’abord, réaliser le développement de cette application client-serveur distribuée,

- dans un deuxième temps, déployer pour la salle de TP G17 cette solution logicielle et ainsi faciliter l’administration du parc de machines.



15

2°) Analyse de la conception

Afin de répondre à ce cahier des charges, nous avons réalisé la conception d’une application permettant, de surveiller le réseau de la salle, de gérer différents profils (par exemple le profil des TP pour les IESSA ou d’un TP pour les IENAC), et de gérer les logiciels des machines de la salle G17 à partir d’une machine administratrice.

a/ La structure générale

GESTION DE LA CONFIGURATION :

On définira un profil comme un fichier contenant des commandes à exécuter. Ils seront stockés sur les machines daemons (il faudra donc les déployer à partir de l’administrateur).

Les différentes tâches réalisables via cette interface graphique sont :

• L’utilisation d’un profil existant ;

• La modification d’un ou de plusieurs profils

• La création d’un (de) nouveau(x) profil(s) ;

• La suppression d’un (de plusieurs) profil(s).

IHM associé au module Gestion de Configuration :

• Voir la configuration actuelle

• Voir profil(s) existants

• Créer nouveau profil

• Modifier profil

• Supprimer profil

• Retour

Gestion de la configuration

->

Sélection machine(s)

• Paramètres à saisir :

-

-

-

Enregistrer les modifications ou

annuler



16

GESTION LOGICIEL :

Après avoir sélectionné les machines, l’administrateur peut décider :

• D’installer un nouveau logiciel sur la (les) machine(s) de son choix ;

• De supprimer un (plusieurs) logiciel(s) installé(s) sur la (les) machine(s).

• Permettre la mise à jour de logiciels à distance installés sur les machines clientes :

o L’utilisateur aura à sélectionner une ou plusieurs machines dont il veut effectuer la mise à jour ;

o Une liste des logiciels installés sur la (les) machine(s) sélectionnée(s) est (sont) affichée(s) ; l’administrateur sélectionne alors le ou les logiciel(s) dont il veut effectuer la (les) mise(s) à jour ;

o Valide ou annule la mise à jour.

N.B : L’IHM lié à la gestion des logiciels est similaire à celle de la gestion de configuration.

SUPERVISION DU RESEAU :

Cette fonction aura pour objectifs de :

• Vérifier la disponibilité des machines clientes. Pour cela, le mode de communication « multicast » sera utilisé.

o La disponibilité d’une machine se traduira sur l’interface graphique par une machine de couleur verte pour une machine disponible et une machine de couleur rouge pour une machine non disponible.

o Le test de disponibilité des machines se fera au lancement du logiciel, puis soit périodiquement, dans ce cas l’administrateur réseau aura la possibilité de configurer la périodicité de ce test via le logiciel, soit à la demande de l’administrateur (par un clique sur un bouton).

• Configurer la possibilité d’une supervision périodique.



17

INTERFACE IHM :

L’interface pourrait se présenter de la manière suivante :

En cliquant sur les boutons du menu de droite, on peut ainsi gérer les configurations d’une ou de plusieurs machines selon le choix de sélection des machines effectué par l’administrateur (clique dans le menu gauche) via les périphériques entrée/sortie souris ou clavier, gérer les logiciels présents sur ces machines, et superviser le réseau.

De plus, on pourra utiliser les raccourcis du menu de gauche, représentant les machines, en doublecliquant pour effectuer ces opérations sur une machine en particulier, sélectionnée par l’administrateur. Cliquer sur une machine ouvrira la fenêtre suivante :

Machine 1

Machine 2

Machine 3

...

Gestion Configuration

Gestion Logiciel

Supervision Réseau

�� Gestion de la configuration

�� Gestion des logiciels

�� Retour



18

b/ Protocoles, flux de données

Dans nos protocoles de communication, nous envoyons des messages de format prédéfinit afin de faciliter leur gestion. Nous développerons ici ces formats ainsi que les interactions entre ces messages. Il existe des messages de type ping et pong, des messages pour exécuter une commande, avec ou sans paramètres, et enfin des message permettant l’acquisition.

��Message de type 0 : le ping

Le ping est utilisé lors de la supervision réseau, afin de déterminer quelles sont les machines disponibles et de compléter leur structure.

��Message de type 1 : l’exécution d’une commande

��Exécution de sous-type 0 : supprimer, installer, …etc sans paramètres

L’administrateur passe une commande qui est insérée dans le message et exécutée au niveau du daemon.

0

Type

(1o)

0

1 0 Lg(msg)

msg

Type

(1o)

Sous type

(1o)

Longueur du message script

(1o)

Message script

(lg(msg)o)



19

��Exécution de sous-type 1 : avec paramètres

L’administrateur passe une commande avec les paramètres associés. Le tout est inséré dans le messge puis exécuté au niveau du daemon

��Message de type 2 : les acquisitions

��Acquisition de sous-type 0 : basique

Ce message permet de savoir si la commande demandée a été réalisée correctement, elle renvoie le code erreur afin d’avoir toutes les informations nécessaires en cas de problème.

1 1 Lg(msg)

msg Nb par

Lg par1 Param1 Lg par2 Param2

Type

(1o)

Sous type

(1o)

Longueur du message script

(1o)

Message script

(lg(msg)o)

Nombre de paramètres

(1o)

Longueur du 1er paramètre

(1o)

1er paramètre

(lg(param1)o)

Longueur du 2eme paramètre

(1o)

2eme paramètre

(lg(param2)o)

2 0

Type

(1o)

Sous-type

(1o)

Code erreur

(1o)



20

��Acquisition de sous-type 1 : le pong

Ce message est la réponse à un ping, il renvoie le fait que la machine est disponible, plus un certain nombre d’informations sur la machine (sa structure et des informations complémentaires comme son système d’exploitation… etc).

��Message de type 3 : liste logiciels

Ce message permet de renvoyer une liste de logiciel, il est envoyé en réponse à une requête de type 1, envoyé par le module gestion des logiciels.

2 1 Nb par


Type

(1o)

Sous type

(1o)

Nombre de paramètres

(1o)


(1o)

1er paramètre

(lg(param1)o)


(1o)

2eme paramètre

(lg(param2)o)

Etc…

3 Nb par


Type

(1o) Nombre de paramètres

(1o)


(1o)

1er paramètre

(lg(param1)o)


(1o)

2eme paramètre

(lg(param2)o)

Etc…



21

Nous allons maintenant introduire les flux de données, c’est à dire comment interagissent ces messages.

Message de type 0 :

Message de type 1 :

Message de type 3 :

Client admin Daemons

Timer

Ping (0)

Pong (2-1)

Client admin Daemon

Timer

Exec (1-x)

Ack (2-0)

Client admin Daemon

Timer

listlog(3)

Ack (2-0)



22

3°) Schémas fonctionnels :coté administrateur



23

Ce schéma représente l’ensemble des modules que nous avons définis pendant la phase préliminaire de la conception, ainsi que les fonctions les composant et leurs interactions. Les modules spécifiques au daemon sont représentés séparément sur le schéma de la page suivante. Les précisions sur les fonctions composant chaque module seront données dans la suite

Pour plus de clarté, nous utiliserons la légende suivante.

Légende :

��Flèches arrivant au module communication :

��I : Init()

��E : Emit()

��R : Recept()

��A : Attendre()

��C : Close()

�� Flèches arrivant au module tableau dynamique :

�� A : Ajouter()

�� T : Taille()

�� C : Créer nouveau tableau()

�� S : Supprimer un élément ()

�� E : Pointer sur un élément()



24

Schema fonctionnel coté daemon :



25

4°) Fonctionnalités

Nous allons maintenant détailler les fonctionnalités précises de chaque module, leur utilité, leur paramètres d’entrée, et leur valeur de retour.

Module Gestion des erreurs :

Données en entrée :

• Nom de la fonction sur laquelle il y a eu erreur

• Message d’erreur du codeur ;

��Informe l’utilisateur d’une erreur :

��Ouvre le fichier de gestion des erreurs

��Ecrit les paramètres cités ci-dessus;

��Ferme le fichier

Donnée en sortie :

• Fichier de gestion des erreurs.

Module Communications :

Ce module permet la communication entre le serveur et les daemons, en utilisant l’API socket.

Fonction d’initialisation :


• Rôle de la machine : 1 pour le client d’administration et 0 pour le daemon ;

�� Elle permet l’initialisation d’une communication, dans les cas unicast, multicast, admin ou daemon, sur la machine locale. Elle crée les sockets et associe les descripteurs obtenus aux structures des adresses IP et des n° de port. Enfin, elle écrit ces descripteurs dans la structure de la machine locale.

Données en sortie : void (elle ne retourne rien).



26

Fonction d’émission :


• Structure de la machine réceptrice ;

• Le type de communication : 1 pour l’unicast et 0 pour le multicast ;

• Le message a envoyé

• La taille du message

��Elle permet l’émission de données en unicast et en multicast.

Données en sortie :

• Elle retourne le nombre d’octets à envoyer si il y a eu succès

• 0 sinon

Fonction de réception :


• L’espace mémoire dans lequel sera stockée la structure de la machine émettrice.


• L’espace mémoire dans lequel seront stockées les données réçues.

��Elle permet la réception de données unicast et multicast


• Elle retourne le nombre d’octets à envoyer s’il y a eu succès

• 0 sinon

Fonction de fermeture :


• Pas de données en entrée ;

��Elle ferme les communications (destruction des sockets de la machine locale).




27

• Elle retourne la réussite (1) ou l’échec de l’opération (0).

Fonction Attendre :


• Le temps maximal d’attente de réception d’une donnée (timeout) ;


��Elle attend la réception de données pendant le timeout ;


• Elle renvoie le fait que l’on ait reçu une donnée (1), que l’on ai atteint le temps maximal d’attente (0) ou qu’il y a eu une erreur (-1).

Interface Shell :

Ce module a été prévu pour faciliter le lien entre les commandes shell que nous serons amenés à utiliser et notre langage de programmation. Nous ne l’utilisons pas nous même mais nous avons tout de même laissé ce module à la convenance de nos successeurs.

Gestion du disque :

Fonction écriture disque :


• Chemins

• Les données à écrire

��Ecriture sur le disque


• Elle renvoie un code erreur, 1 si il y a eu succès et 0 si échec.

Fonction Lecture disque :


• Chemin



28

• L’espace dans lequel les données lues seront écrites (buffer)

��Lecture sur le disque


• Elle renvoie un code erreur, 1 si il y a eu succès et 0 si échec.

Construction de messages :

Fonction ajout d’un caractère :


• Le buffer dans lequel on veut ajouter le caractère ;

• Le caractère ;

• L’indice du buffer (compteur).

��Elle écrit un caractère dans un buffer et remet le compteur à jour.

Données de sortie :

• Elle ne retourne rien.

Fonction ajout d’une chaîne de caractère :


• Le buffer dans lequel on veut ajouter la chaîne ;

• Le chaîne de caractère ;

• L’indice du buffer (compteur).

��Elle écrit une chaîne de caractère dans un buffer et remet le compteur à jour.

Données de sortie :




29

IHM :

L’IHM fait appel à notre programme principal, nous ne la mettrons pas en œuvre dans le cadre de notre projet.

��Lecture du clavier et de la souris (création d’évènement)

��Affichage


• Les évènements associés à chacune des opérations.

Programme principal de l’admin :

��Initialisation de la communication

��Recherche des machines disponibles

��…

��Fermeture de la communication

Gestion de configuration :

Elle permet de consulter les profils présents sur les postes daemons de la salle G17 et d’utiliser, de modifier et de créer un profil.

Création d’une liste de profil :


• Structure de la machine sur laquelle on veut récupérer la liste des noms de profil

�� Après avoir établi une communication unicast, elle a pour rôle de créer une liste de noms de profil présents sur un daemon.


• Elle retourne un tableau dynamique contenant la liste des noms de profil



30

Fonction liste des machines et des noms logiciels :


• Liste des structures des machines daemons ;

�� Elle permet de récupérer pour chacune des machines daemons, les noms des profils qui y sont stockés et indique le profil actif.


• Elle retourne le tableau dynamique contenant les structures des machines daemons et les noms de profil associés ainsi que le nom du profil actif.

Utilisation d’un profil :


• La structure de la machine daemon

• Le nom du profil rentré par le client d’administration

• Le nom de la commande shell rentrée par l’administrateur

��Elle permet de charger un profil sur le poste daemon pour utilisation.



Modification d’un profil :


• La structure de la machine daemon

• Les paramètres du profil à modifier

• Le nom du profil à modifier

��Elle récupère les nouveaux paramètres saisis par l’administrateur

��Via la communication unicast, elle charge ces nouveaux paramètres dans le nom de profil (fichier) à modifier.



31



Création d’un profil :


• Le tableau dynamique contenant les noms des profils pour une machine daemon particulière ;

• Le nouveau nom de profil

��Elle permet de mettre à jour le tableau dynamique contenant les noms de profil de la machine daemon en rajoutant le nouveau nom de profil à la fin du tableau.


• Le tableau dynamique des noms de profil mis à jour.

Suppression d’un profil :


• Le tableau dynamique contenant les noms des profils pour une machine daemon particulière ;

• Le nouveau nom de profil

��Elle permet de mettre à jour le tableau dynamique contenant les noms de profil de la machine daemon en supprimant le nom de profil situé à l’index correspondant.


• Le tableau dynamique des noms de profil mis à jour.

Gestion de logiciels :

Installer un logiciel :



32


• La liste des structures des machines daemon sur lesquelles on veut installer le logiciel

• La commande shell rentrée par l’administrateur

• Le nom du logiciel rentré par l’administrateur

��Elle récupère les données rentrées par l’administrateur et charge celles-ci via la communication unicast déjà établie.


Elle retourne l’échec ou la réussite de l’installation via un message d’aquittement.

Supprimer un logiciel :


• La liste des structures des machines daemon sur lesquelles on veut installer le logiciel

• La commande shell rentrée par l’administrateur

• Le nom du logiciel rentré par l’administrateur

��Elle récupère les données rentrées par l’administrateur et charge celles-ci via la communication unicast déjà établie.


• Elle retourne l’échec ou la réussite de la suppression via un message d’aquittement.

Mise à jour des logiciels :

Données en entrée : rien

��Cette fonction permet de voir les logiciels qui ne sont pas installés sur toutes les machines et d’uniformiser la situation

Données en sortie : le tableau des machines mises à jour



33

Supervision du réseau côté admin :

Disponibilité :


• Temps maximal durant lequel on attend que les machines répondent ;

��Elle émet un ping en multicast, elle récupère les structures des machines qui ont répondu, en mettant leur état à 1 (disponible) pendant toute la durée du timer.


• Elle retourne le tableau des structures ayant répondu.

Get_time :

Données en entrée : pas de données en entrée

��Récupère la date et l’heure du pc

Données en sortie : le temps

Fonction principale des daemons:

��Elle initialise les communications

��Elle réceptionne les requêtes et appelle les autres modules pour traitement de la requête.

��Elle ferme les communications

Gestion des messages :


• Le message reçu

• La structure de la machine émettrice

��Elle regarde le type du message et fait appel à la fonction adéquate.




34


Traitement des requêtes :

Ce module permet de traiter, en fonction de leur type et de leur sous-type, les messages reçus par une machine daemon.

Fonction réponse à un message ping :


• La structure de la machine émettrice du ping

��Cette fonction écrit dans un buffer les paramètres contenue dans la structure de la machine locale puis fait appel au module de communication pour envoyer ce buffer à la machine émettrice.


• Elle renvoie l’entier 0 en cas d’échec, et 1 en cas de réussite.

Fonction réponse à un message de type 1, soustype 0:


• Le buffer contenant le message envoyé

��Cette fonction prend dans le buffer la ligne de commande, remet de l’ordre (par exemple la lecture du caractère \n veut dire que c’est une deuxième ligne de commande), et exécute les commandes ainsi définies.





35

Fonction réponse à un message de type 1, soustype 1:


• Le buffer contenant le message envoyé

��Cette fonction prend dans le buffer la ligne de commande et les paramètres, remet de l’ordre (par exemple la lecture du caractère \n veut dire que c’est une deuxième ligne de commande), et exécute les commandes ainsi définies.





36

5°) Un exemple concret : Lecture d’une liste de profils sur une machine



37

Nous donnons ici un exemple concret d’utilisation de notre application, afin d’illustrer son fonctionnement. Il s’agira dans ce cas de lire une liste de profils sur une machine donnée.

Pour cela au lancement de l’application, les programmes principaux initialisent les communications (phase 1).

Ensuite, du côté de l’administrateur, le programme principal appelle dans le module supervision du réseau la fonction « disponibilité » (phase 2). Cette fonction appelle elle même le module communication pour émettre un ping en multicast (phase 3), on n’a représenté sur ce schéma qu’un seul serveur daemon, mais il y en a en fait plusieurs. Le message arrive donc au module communication des daemons, en réception (phase 4). Du côté des daemons, le programme principal fait en permanence appel au module communication pour attendre des réceptions (phase 5). Quand il a reçu le message, il fait appel au module gestion des messages afin de définir son type et son sous-type si besoin est (phase 6). Puis le module gestion de message appelle à son tour le module traitement des messages pour traiter la requête en fonction du type (phase 7). Il apppellera le module message afin e construire sa réponse (phase 8), puis appellera la communication pour envoyer la réponse (phase 9), et celle-ci sera transférée à l’administrateur (phase 10). Le module supervision réseau recevra cette réponse (phase 11), et remplira alors les structures des machines (phase 12).

La phase lecture d’une liste de profil pourra alors commencer.

Du côté administrateur, le module gestion de configuration utilise ces structures (phase 13), puis fait appel au module message pour mettre en forme sa commande à exécuter (phase 14) qu’il enverra via le module communication (phase 15). Cette commande est donc transférée au daemon visé (phase 16). Alors, me programme principal daemon, qui écoutait le module communication (phase 17), lors de la réception de la commande, fait appel au module gestion des messages pour définir le type de commande (phase 18), qui une fois le type et le sous-type obtenus , fait lui même appel au module traitement des messages pour exécuter cette commande (phase 19). Dans notre cas, il lira les noms des profils, et les écrira dans un buffer par le module message (phase 20). Puis, il fera appel au module communication pour envoyer ce buffer (phase 21). Ainsi, la réponse est envoyée à la communication de l’administrateur (phase 22). Le module gestion de configuration récupère cette réponse (phase 23), puis écrit sa liste de profil dans un tableau dynamique (phase 24).

Enfin, lorsque l’application se termine, les programmes principaux se chargent de fermer les communications (phase 25).



38

6°) Plan de test

A chaque étape du déploiement, nous avons prévu d’effectuer des tests afin de valider

ces étapes au fur et à mesure. Ainsi, chaque fonction est testée une fois qu’elle est écrite, puis nous vérifions que ces fonctions interagissent bien entres elles.

Enfin, lors du déploiement de l’application dans la salle G17, nous vérifions que notre programme fonctionne dans l’environnement désiré.

Pour tester le module communication, on différenciera le cas unicast du cas multicast.

Pour l’unicast, on implémentera une fonction principale client_administrateur, qui initialisera une communication admin, puis émettra sur une machine choisie, dont on aura initialisé la structure en dur (gethostbyname), puis une fonction principale serveur_daemon, qui initialisera une communication daemon, puis en boucle infinie attendra une réception. L’avancée de chaque étape des fonctions est surveillée par une impression écran. De plus, on imprimera aussi le buffer obtenu, et les indications sur la machine émettrice. Enfin, les deux programmes principaux fermeront les communications.

Pour le multicast, on implémentera de même deux programmes principaux, l’un serveur et l’autre client, qui chacun initialiseront les communications au début, et les fermeront à la fin. Le client ne fait qu’émettre un message « test » à l’adresse multicast, tandis que les serveurs attendent et reçoivent ce message. De même que pour l’unicast, chaque étape est contrôlée par une impression écran, le message et les données sur la machine émettrice sont affichées.

Pour tester le module message, on implémentera une fonction principale qui initialisera un buffer, appellera les fonctions ajouter_caractère et ajouter_chaine_caractère, puis on imprimera le résultat obtenu.

Pour tester le module supervision du réseau, on écrira un programme principal du coté de l’administrateur, qui initialisera les communications et appellera la fonction dispo, tout en faisant des impressions écran à chaque étape, puis un programme principal côté daemon qui initialisera la communication, attendra et recevra le ping puis construira un message de type pong (type 2 sous type 1), avec les données sur sa machine locale derrière, et l’enverra à l’administrateur.

Afin de tester le module gestion des messages, on écrira un programme client qui initialisera sa communication, puis enverra des messages de chaque type. Le programme serveur initialisera sa communication, puis attendra et recevra les messages du client, enfin appellera la fonction gestion des messages. Nous rajouterons dans cette fonction diverses impressions écran prouvant qu’il fait bien appel à la bonne fonction.

Le module traitement des messages daemons sera testé de même avec deux programme principaux, qui initialiserons leur communication, puis dans le cas du client, enverra des messages de chaque type. Le serveur attendra et recevra ces messages puis



39

appellera en fonction du type la fonction correspondante de traitement des messages. Le suivi de ces étapes se fera de même à travers des impressions écran, et quand cela est possible la vérification que la commande a bien été exécutée.

Pour le module de gestion des erreurs, il faut passer deux paramètres à la fonction recuperror pour qu’elle soit opérationnelle, plus précisément deux chaînes de caractères. Le but du test est alors de lui passer deux chaînes de caractères choisies au hasard et vérifier qu’un fichier de gestion d’erreur s’est bien ouvert dans le répertoire de travail courant et que les deux chaînes de caractères y soient inscrites.

Pour le module gestion de configuration :

• La fonction liste_profil a besoin qu’on lui passe un paramètre pour qu’elle fonctionne, à savoir la structure de la machine destinatrice pour laquelle on veut connaître la liste des noms de profil. Le but est donc de lui passer ce paramètre et de vérifier qu’il n’y a pas eu de messages d’erreur sur la fonction message, émission et réception du message et voir si le tableau dynamique a bien été crée et qu’il contient bien tous les noms des profils qui ont été envoyés à partir du poste daemon.

• La fonction liste_machine_profil a besoin quant à elle qu’on lui passe deux paramètres pour la faire fonctionner. Une fois ces paramètres passés, on vérifie bien que dans le nouveau tableau dynamique crée que chaque case du tableau contient une structure machine et le tableau dynamique des noms de profils obtenu via la précédente fonction liste_profil. On vérifie bien évidemment que chacune des sous fonctions n’a pas échoué à savoir message, émission et réception de message.

• La fonction create_profil a besoin qu’on lui passe en paramètre un tableau dynamique (celui contenant la liste des noms de profil) et une chaîne de caractère entrée par l’administrateur client qui n’est autre que le nouveau nom de profil. Après avoir rentré ces deux paramètres on vérifie bien que, dans un premier temps, ce nouveau soit inscrit dans la dernière case du tableau et qu’un fichier du nom du profil soit généré dans le répertoire courant de travail de manière à ce que l’administrateur client puisse y rentrer le contenu du profil. Puis, dans un second temps, il faut vérifier que ce tableau dynamique et ce nouveau profil soient correctement transmis à la machine daemon. On vérifie donc toujours que les sous fonctions message, émission et réception de message se soient correctement passées.

• La fonction suppr_profil a besoin qu’on lui passe en paramètre un tableau dynamique (celui contenant la liste des noms de profil) et un entier qui correspond à l’index associé le profil à supprimer dans le tableau. Après avoir rentré ces deux paramètres on vérifie bien que, dans un premier temps, que le nom de profil en question a bien été supprimé dans le tableau et que le fichier associé à ce nom du profil ait bien été supprimé du poste daemon. Puis, dans un second temps, il faut vérifier que ce tableau dynamique est correctement transmis à la machine daemon. On vérifie donc toujours que les sous fonctions message, émission et réception de message se soient correctement passées.

• La fonction use_profil a besoin qu’on lui passe en paramètres une structure machine destinatrice et une chaîne de caractère correspondant au nom de profil à utiliser. Après avoir passé ces deux paramètres on vérifie bien que les fonctions message,



40

émission de message aient correctement fonctionnées et que le poste daemon ait bien pris en compte le nouveau profil à utiliser.

Pour le module gestion de logiciel :

• La fonction install_logiciel a besoin qu’on lui passe en paramètres une structure machine destinatrice, une chaîne de caractère correspondant au logiciel à installer et une chaîne de caractère correspondant à la commande shell à exécuter sur le poste daemon. Après avoir passé ces paramètres, on vérifie donc toujours que les sous fonctions message, émission et réception de messages n’ont pas généré de fichier d’erreur et que le poste daemon ait bien exécuté la commande shell transmis et que le nouveau logiciel ait bien été installé.

• La fonction suppr_logiciel a besoin qu’on lui passe en paramètres une structure machine destinatrice, une chaîne de caractère correspondant au logiciel à supprimer et une chaîne de caractère correspondant à la commande shell à exécuter sur le poste daemon. Après avoir passé ces paramètres, on vérifie que les sous fonctions message, émission et réception de messages n’ont pas généré de fichier d’erreur et que le poste daemon ait bien exécuté la commande shell transmise et que le logiciel ait bien été supprimé sur le poste daemon.

7°) Conclusion sur la conception

La conception de l’application est une étape cruciale dans la création d’un logiciel. En effet, sa qualité définira la réussite ou l’échec de la création du logiciel puisque toute la suite (mise en œuvre, déploiement, tests et analyse) en découle. Nous avons donc apporté un soin particulier à son élaboration, c’est à dire à la définition des modules principaux, de leurs fonctionnalités et de leurs interactions présentés dans cette partie.

Une fois la conception terminée, nous avons pu commencer la mise en œuvre de l’application, présentée dans la partie suivante.



41

IV/ Le développement de l’application

Nous allons dans cette partie détaillé comment nous avons mis en œuvre notre application, quels choix nous avons effectués et quels outils nous avons utilisés.

1°) Choix techniques

• On a fait le choix de programmer en « langage C », du fait d’une meilleure maîtrise de ce langage parmi les différents langages proposés lors de ce projet ;

• On a décidé de développer un logiciel ayant le plus possible des caractéristiques modulaires (portabilité/ adaptabilité) en utilisant des modules;

• Pour la simplicité de codage, on a décidé de travailler avec des scripts.

• Pour le choix des principales fonctionnalités, se référer au cahier des charges ;

• On a également fait le choix de développer une communication clients/serveur basée sur le protocole UDP car beaucoup plus simple à coder mais également étant donné que l’on travaille au niveau d’un LAN, donc utilisant des connexions point à point, on n’a pas besoin d’assurer le contrôle de flux et de congestion en utilisant TCP. En effet, la couche LLC et MAC (couche 2 du modèle OSI) assurent déjà ces fonctionnalités donc en travaillant dans un LAN des redondances ne sont pas nécéssaires. De plus, la probabilité de pertes de paquets est très faible.

• La communication clients/serveur se fera via des sockets UDP unicast et multicast. L’unicast pour des communications point à point et le multicast dans le cas de la supervision réseau (ping).

• Au lancement du logiciel, le plan d’adressage des machines sera récupéré par la supervision réseau.

• Choix des modules : se référer au graphe

• Nous avons décidé de représenter les machines par des structures contenant les paramètres suivants :

o Le nom de la machine ;

o L’adresse IP unicast ;

o L’adresse IP multicast ;

o N° de port unicast ;

o N° de port multicast ;

o Etat de la machine (1 si disponible et 0 absente) ;

o Descripteur de socket unicast ;

o Descripteur de socket multicast.



42

• Nous travaillons dans le cadre d’une application répartie, nous avons donc décidé de stocker les données (liste de profils) sur les postes daemons. Il est donc important, pour garder l’avantage d’une application répartie, de prévoir une fonction qui permettra de déployer à distance les données sur les daemons.

Mise en œuvre :

Hormis, les différents choix techniques justifiés dans les paragraphes précédents, durant la phase de codage d’autres choix se sont imposés pour faciliter le développement du logiciel et répondre au mieux aux attentes du cahier des charges.

• Pour la gestion des erreurs et la création/ouverture d’un profil, on a fait appel aux primitives d’ouverture et de fermeture de fichier. Le fichier texte de gestion des erreurs ainsi généré permettra de stocker les messages d’erreurs associés aux fonctions dont l’exécution a échoué. Et le fichier de profil crée, dont le nom sera passé en paramètre par l’administrateur client, permettra à celui-ci d’y remplir le contenu du profil.

• Pour stocker les noms des profils rapatriés à partir des postes daemons, on utilisera un tableau dynamique faisant appel aux mécanismes de listes chaînées dont la fonctionnalité est expliquée en fin d’étude bibliographique. L’avantage de ce type de tableau vient du fait qu’il permet de s’adapter automatiquement à la taille des données transférées, sans avoir à passer la taille du tableau au début de sa création. Pratique lorsque l’on ne connaît pas à l’avance la taille des données transférées. Et enfin, l’ajout et la suppression d’un ou plusieurs nom(s) de profil(s) se fera plus précisément via la liste chaînée.

Pour pouvoir associer les noms de profil à la machine qui stocke ces profils, on définira une structure dont les éléments seront une machine avec le bon type associé (type_machine) et un tableau dynamique contenant les noms de profils stockés sur cette machine avec le bon type associé (dyn_tab).

• Pour la supervision du réseau, nous utiliserons le tableau dynamique présenté ci-dessus. Il nous faudra aussi pouvoir récupérer le temps sur la machine, il a donc fallu coder une fonction spécifique .

• Pour la communication, nous implémentons les sockets dans un cas non connecté, selon le schéma suivant :

Conception d’un client :

En mode non connecté

Création d’une socket

Construction de la représentation externe de la socket du serveur(@IP, n°port)

Envois/Réceptions en boucle



43

Conception d’un serveur itératif :

En mode non connecté

Création d’une socket

Représentation externe de la socket

Lien représentations externe et interne

Envois/Réceptions

Les primitives utilisées :

- Création d’un TSAP : socket

La création d’un socket indique l’intention de communiquer dans le domaine voulu (ex : internet), dans le mode choisi (connecté, con connecté) en utiliant le protocole sous-jacent (UDP/TCP).

- Destruction d’un TSAP : close

La destruction d’un socket est identique à la fermeture d’un fichier.

- Lien avec une adresse transport : bind

Ce lien permet d’identifier le processus destinataire. Le bind permet d’associer le descripteur de socket et la structure contenant l’adresse IP et le numéro de port que ‘on veut associer au processus.

- Emission : sendto

Ces primitives renvoient le nombre d’octets envoyés. Il n’est besoin de spécifier le destinataire du message qu’en mode non connecté car il n’y a pas de relations privilégiées entre l’émetteur et le récepteur.

- Reception : recvfrom

C’est la même procédure que pour l’émission.

On donne dans la suite un exemple pour un modèle client serveur itératif en mode non connecté avec le protocole UDP, qui sera utilisé dans notre projet :



44

Nous utiliserons des commandes permettant d’obtenir les adresses locales des machines.

Enfin, dans le cas d’une socket multicast, il faut également, durant l’initialisation de la socket, se joindre au groupe voulu.

Socket()

Socket() Bind()

Recvfrom()

Sendto()

Recvfrom()

Sendto()

Bind() Bloque en attendant des données d’un client

Serveur en mode non connecté

Client en mode non connecté

requête

réponse



45

2°) Tests réalisés

Nous avons testé les fonctions que nous avons pu mettre en œuvre à différentes étapes,

selon le plan de tests que nous nous étions fixé lors de l’étape de conception.

Ces tests ont tout d’abord été effectués dans l’environnement où nous travaillions, la salle G19, puis dans la salle où l’application doit être mise en place, la G17.

Sur les modules gestion d’erreurs, gestion de logiciel et gestion de configuration, communication, supervision du réseau, messages, traitement message et gestion message, seuls les modules gestion d’erreurs, message, communication (en unicast et en multicast) et certaines fonctions du module de gestion de configuration ont été testées en G19. Les tests en G17 n’ont pas pu être réalisés, ou bien seulement partiellement en ce qui concerne le module communication.

• Pour le module de gestion d’erreur, le test de la fonction recuperror s’est fait selon les détails indiqués dans le plan de test. On a passé deux chaînes de caractère à la fonction à savoir « blabla » et « blublu » et on a bien vérifié qu’un fichier texte a été crée dans le répertoire courant de travail et ayant pour contenu les mots « blabla » et « blublu ». Donc, la fonction recuperror fonctionne correctement.

• Pour le module message, nous avons donc, d’après le plan de test, initialisé un buffer puis écrit le caractère « a » suivi de la chaîne « hello ». Lors de l’impression écran nous avons bien pu vérifier que le buffer contenait bien « ahello ».

• Nous avons de même testé le module communication selon le plan de test, en mode unicast et multicast (sur 3 machines), et nous avons pu vérifier de même que ce module fonctionnait dans la salle G19. Dans la salle G17, il a fallu changer la configuration réseau et les programmes de test afin de joindre les machines présentes.

• Pour le module de gestion de configuration, seules les fonctions liste_profil, create_profil et suprr_profil ont été testé.

o Pour la fonction liste profil, après avoir correctement configuré les paramètres de la machine destinatrice utilisés pour l’émission et réception de messages via la socket, on a envoyé via le poste daemon, une chaîne de caractère « tp iessa.txt » et on a vérifié que cette chaîne de caractère ait été correctement copiée dans le tableau dynamique en faisant un affichage du contenu du tableau. Après affichage, la chaîne tp iessa.txt est bien contenu dans le tableau.

o Pour la fonction create_profil, après avoir ajouté une première chaîne de caractère servant de test dans la case 0 du tableau, on a fait appel à la fonction create_profil pour insérer une deuxième chaîne de caractère dans la case 1 du tableau qui n’est autre que le nom passé en paramètre par l’administrateur client et qui correspond au nouveau nom de profil. Après affichage du contenu de la case 0 et 1 du tableau on observe bien que dans la case 1 contient bien le nouveau nom de profil.

o Pour la fonction suppr_profil, après avoir ajouté deux chaînes de caractère servant de test dans les cases 0 « blublu22 » et 1 « blublu30 » du tableau, on a fait appel à la fonction suppr_profil pour supprimer la chaîne de caractère de la case 0 « blublu22 » du tableau. Après affichage du contenu du tableau on observe bien que la case 0 contient la deuxième chaîne de caractère entrée « blublu30 » qui a pour index 0 maintenant.



46

3°) Conclusion sur le développement

Nous avons donc commencé à mettre en œuvre les modules et les fonctions que nous avions définis pendant la phase de conception. Les fonctions achevées sont donc testées en G19, et partiellement en G17. Nous n’avons pas pu coder certaines fonctions par manque de temps, car nous manquions d’expérience en ce qui concerne la programmation, et nous avons du intégrer ces notions pendant notre travail. Il restera donc aux personnes qui reprendront notre travail à finaliser les tests en G17, puis à développer les fonctions que nous n’avons pas eu le temps de coder.



47

V/ Déploiement et bilan

Par manque de temps, les fonctions n’ont pas été testées dans la salle g17, ou pas dans leur intégralité. Ainsi, la phase de déploiement n’a pas pu être réalisée correctement.

VI/ Conclusion générale

Nous avons donc, du fait de son importance, apporté un soin particulier à la phase de conception de l’application. Celle ci étant donc bien finalisée, nous avons pu définir de manière claire et précise les modules que nous utiliserons et les fonctionnalités qui les composent, ainsi que la manière dont elles interagissent.

Ceci nous a permis de passer sans problème à l’étape du développement.

Durant cette phase, consistant à coder les différentes fonctions des modules, nous avons rencontré des difficultés dues à notre manque d’expérience dans ce domaine. En effet, nous ne maîtrisions pas parfaitement les notions de programmation que nous devions utiliser. Nous avons donc du, au fur et à mesure de la mise en œuvre, intégrer ces notions.

Ce projet nous a donc permis d’acquérir de meilleures connaissances dans le domaine de la conception logiciel. En effet, nous avons été sensibilisées aux différentes étapes à suivre, telles que la conception, le développement et le déploiement, et à leur importance. De plus, ces heures de projets nous ont permis d’acquérir plus d’expérience, de compétence et d’assurance dans le domaine de la programmation. D’autre part, à l’issu de notre projet, nous avons pu comprendre l’importance de la communication dans l’équipe pour ce genre de travail. Enfin, nous avons eu, pour la première fois, l’occasion d’organiser et de gérer nous même notre projet, qui s’y adaptait très bien. Ainsi, nous avons pris conscience de l’importance de la gestion de projet dans le suivi de notre travail pour pouvoir le mener à terme. Ce projet nous a en plus donné l’opportunité de coupler ces problèmes de gestion de projet à ceux de la conception logiciel. Or, ce sont des expériences qui pourront nous apporter des qualités nécessaires à notre futur professionnel.

Ainsi, l’élaboration du logiciel voulu est bientôt à terme, il reste cependant à étoffer la partie développement. De ce fait, les personnes qui devront reprendre notre projet devront donc finir de mettre en œuvre l’application, c’est à dire coder les fonctions qui n’auront pas été testées, mettre en œuvre l’interface homme machine que nous n’avons pas développée, et déployer l’application dans son intégralité en salle g17. Ils devront aussi rédiger le manuel d’utilisation du logiciel, destiné à l’utilisateur final.



48

Annexe 1 : Bibliographie

[1] Dave Taylor & James C.Armstrong Jr, UNIX, Campus presse

[2] Jean Luc Bussenot, support de cours La communication réseau sous unix avec TCP/IP et Sockets

[3] Fabien Garcia, support de cours Les applications du monde IP

[4] Alain Pirovano, support de cours Architecture TCP/IP

[5] Alain Pirovano, support de cours Architecture générale des réseaux

[6] Joelle Luter-Claverie, support de cours Dévelopement d’applications réseau

[7] www.cpluplus.com

[8] http://rangiroa.essi.fr/riveill/recherche/98-car.html

[9] http://www-src.lip6.fr/homepages/Xavier.Blanc/courses/XB1-Introduction.ppt#3

[10] http://www.infoclick.fr/ccm/c/cstruct.htm



49

ANNEXE 2 : GESTION DE PROJET CLAUDEL Emilie IENAC 05L

CHEUNG HI Stéphanie

PLAN DE DEVELOPPEMENT DU PROJET

« Développement et déploiement d’une application distribuée d’administration pour le parc de machines de la

subdivision ELR »

Document approuvé par Mlle Cheung HI et Mlle Claudel

Liste de diffusion Nicolas LARRIEU

Fabien GARCIA

Alain PIROVANO



50

Véronique MANNEVILLE

Liste des mises à jour du plan de développement

Version du document

Date Raison de l’évolution Fiche de modification

V0.1 07.12.2007 Création

V0.2 07.01.2008 Remarques des clients

V1.1 20.01.08 Changement de planning



51

1. But du document

Ce document concerne la réalisation du projet tutoré IENAC 3ème année, intitulé Développement et déploiement d’une application distribuée d’administration pour le parc de machines de la subdivision ELR.

Ce document, auquel on se réfèrera tout au long de notre projet, définit :

• La composition du groupe de travail et des encadrants,

• Les objectifs relatifs à ce projet (développement d’un logiciel, rapport et présentation),

• Les tâches à remplir et leur attribue un responsable,

• L’ordonnancement optimal des tâches,

• Mise en place des réunions d’avancement en vue d’une vérification et d’une validation de chaque étape du projet.

2. Documents applicables et de référence

2.1 Documents applicables :

• Le sujet de projet (Annexe 1),

2.2 Documents de référence

• Plan de développement type

• Support de cours ENAC : cours de Gestion de Projet et Réseaux

3. La terminologie

• PBS Product Breakdown Structure

• OBS Organisation Breakdown Structure

• WBS Work Breakdown Structure

• TCP/IP Transmission Control Protocol/ Internet Protocol

• UDP User Datagram Protocol

• IHM Interface Homme Machine

• PDD Plan de développement

• ELR Division Electronique et Réseaux



52

4. Décomposition de la fourniture

Le produit final fournit à Nicolas LARRIEU, Fabien GARCIA, Alain PIROVANO et Véronique MANNEVILLE comportera :

• Un plan de développement,

• Un rapport de synthèse,

• Une présentation orale sous Powerpoint,

• Une version imprimée des slides qui seront présentés,

• Le logiciel de supervision à distance.

5. Démarche de développement

5.1 Cycle de développement global

Le cycle de développement sera présenté dans le WBS (Annexe 3)

5.2 Méthodes de développement par phase

Objectifs

Développer et Déployer une application distribuée d’administration pour le parc de machines de la subdivision ELR.

Phase d’Analyse :

Produits d’entrée :

-Documents applicables et de références.

Se documenter

• Application distribuée et système de communication,

• Ingénierie des réseaux,



53

Définir les l’expression de besoins,

Définir les spécifications,

Concevoir une étude préliminaire des fonctionnalités du logiciel (définition des systèmes et des sous systèmes),

Concevoir l’étude détaillée (algorithmes des systèmes et sous systèmes),

Gestion de projet :

• Définir les objectifs et les produits de sortie PBS (Annexe 4),

• Définir les tâches,

• Définir les responsabilités,

• Rédiger une ébauche du plan de développement (la rédaction d’un plan de qualité n’est pas nécessaire ici).

Produits de sortie :

-Cahier des charges

- Algorithmes des fonctions

- PDD

- OBS

- WBS

- PBS

Phase de Planification :


- Ebauche du PDD ;

Planifier la gestion de projet :

- Etablir le réseau d’ordonnancement

- Estimer les charges

- Identifier le calendrier

- Identifier les contraintes

Produit de sortie :

-PDD

- Réseau d’ordonnancement.



54

Phase de Codage :


- PDD

- Documents applicables et de référence

Se former

• Au langage de programmation C,

• Outils de compilation,

• Outils d’IHM,

Coder


- Codes

Phase des Tests Unitaires et Intermédiaires :


-Codes

-Cahier des charges


- Ebauche du logiciel

Phase d’Intégration :


- Ebauche du logiciel

Déployer le logiciel


- Logiciel déployé sur toutes les machines de la salle de G17



55

Phase de Test de Validation :


- Logiciel déployé sur toutes les machines de la salle de G17

- Cahier des charges

Tester et valider,


- Logiciel final

Phase d’Analyse de résultat et de Rédaction :


- Logiciel final

- Résultats des Tests

Analyser les résultats et conclure

Rédiger le rapport de synthèse

Rédiger le manuel d’utilisation du logiciel,

Préparer la présentation


-Fiche d’amélioration

-Rapport de synthèse

-Manuel d’utilisation du logiciel

-Slides Powerpoint

6. Organisation

L’organisation est présentée dans l’OBS (Annexe 5).



56

7. Planning général prévisionnel

7.1 Réseau logique d’ordonnancement

Il est présenté dans le réseau logique d’ordonnancement des tâches (Annexe 6).

7.2 Echéancier des fournitures

Fourniture Echéances

Plan de développement 23/01/08

Rapport de synthèse 23/01/08

Présentation orale 25/01/08

7.3 Identification des contraintes

Contrainte de temps (soutenance, rapport de synthèse et test du logiciel)

Contrainte vis-à-vis de l’environnement de développement

Contraintes dues aux clients (codage)

8. Présentation du suivi

Les présentation du suivi du projet se sont faites lors des réunions hebdomadaires d’avancement avec Nicolas LARRIEU et Fabien GARCIA.

Nous avons rédigé un plan de développement initial et commencé la conception de l’application en novembre.

Nous avons fini la conception et commencé à la mise en œuvre en semaine 53 de l’année 2007.

Enfin, nous avons rédigé le rapport dans le courant du mois de janvier 2008.



57

9. Identification et suivi des risques

• Retard sur l’échéancier : réunions de suivi fréquentes

• Fonctionnalités manquantes : le projet nécessitera la reprise du projet l’année prochaine, nous essaierons donc d’être les plus claires et concises possibles pour faciliter la reprise en main du projet.



58

ANNEXE 3 : WBS



59

ANNEXE 4 : PBS



60

ANNEXE 5 : OBS

CLAUDEL Emilie

Chef de projet

CLAUDEL Emilie

Ingénieur technique

CHEUNG HI Stéphanie

Ingénieur technique

Chef qualité



61

ANNEXE 6 : RESEAU LOGIQUE D’ORDONNANCEMENT

SYNTHESE PROJET RESEAUX -...

Documents

Transcript of SYNTHESE PROJET RESEAUX -...