copie de rapport final de pfa

40
1 Tunisie Télécom Mohsen BESSGHAIER Liste des figures Figure 1. Diagramme de cas d’utilisation ................................................. ...........................10 Figure 2. Diagramme de séquence du scénario ajouter un agent .........................................12 Figure 3. Diagramme de séquence du scenario supprimer un agent. ...................................13 Figure 4. Diagramme de séquence du scenario modifier un agent. ......................................14 Figure 5. Diagramme de classe de cas d'utilisation gérer les agents. ...................................15 Figure 6. Diagramme de séquence du scénario ajouter un nouvel élément. .........................16 Figure 7. Diagramme de séquence du scénario ajouter une quantité pour un élément. ........17 Figure 8. Diagramme de séquence du scénario retirer une quantité . ...................................18 Figure 9. Diagramme de classe du cas d'utilisation gérer les stockes. ..................................19 Figure 10. Diagramme de séquence du scénario afficher les informations. .........................20 Figure 11. Diagramme de classe de cas d'utilisation afficher les informations. ...................20 Figure 12. Diagramme de séquence du scénario imprimer les informations. .......................21 Figure 13. Diagramme de classe de cas d'utilisation imprimer les informations. .................22

Upload: wael-ajlani

Post on 30-Jun-2015

905 views

Category:

Documents


4 download

TRANSCRIPT

Page 1: Copie de RAPPORT FINAL DE PFA

1

Liste des figures

Figure 1. Diagramme de cas d’utilisation ............................................................................10

Figure 2. Diagramme de séquence du scénario ajouter un agent .........................................12

Figure 3. Diagramme de séquence du scenario supprimer un agent. ...................................13

Figure 4. Diagramme de séquence du scenario modifier un agent. ......................................14

Figure 5. Diagramme de classe de cas d'utilisation gérer les agents. ...................................15

Figure 6. Diagramme de séquence du scénario ajouter un nouvel élément. .........................16

Figure 7. Diagramme de séquence du scénario ajouter une quantité pour un élément. ........17

Figure 8. Diagramme de séquence du scénario retirer une quantité . ...................................18

Figure 9. Diagramme de classe du cas d'utilisation gérer les stockes. ..................................19

Figure 10. Diagramme de séquence du scénario afficher les informations. .........................20

Figure 11. Diagramme de classe de cas d'utilisation afficher les informations. ...................20

Figure 12. Diagramme de séquence du scénario imprimer les informations. .......................21

Figure 13. Diagramme de classe de cas d'utilisation imprimer les informations. .................22

Figure 14. Ecran gestion des agents ..................................................................................... 24

Figure 15. Ecran gestion des ordinateurs ............................................................................. 25

Figure 16. Ecran gestion des dérangements ......................................................................... 26

Figure 17. Ecran gestion des stockes .................................................................................... 27

Liste des tableaux

Tableau 1. Le modèle environnemental ................................................................................ 7

Page 2: Copie de RAPPORT FINAL DE PFA

2

Introduction générale

Chapitre 1 : Expression des besoins et spécification

1.1. Introduction

1.2. Expression des besoins

1.2.1. Présentation de l’organisation et ces domaines d’activités:

1.2.1.1. Présentation de la société « Tunisie Télécom »

1.2.1.1.1. Historique

1.2.1.1.2. Activité

1.2.1.1.3. Fiche

1.2.2. Contexte général du problème

1.2.3. Inventaire des problèmes, besoins et objectifs

1.3. Spécification

1.3.1. Description détaillée du logiciel : Le modèle environnemental

1.3.2. Gestion des besoins fonctionnels

1.4. Conclusion

Chapitre 2 : Analyse et Conception

2.1. Introduction

2.2. Diagramme de cas d’utilisation

2.3. Description des cas d’utilisation

2.3.1 Cas d’utilisation : Gérer les agents

2.3.1.1. Scénario1 : Ajouter un agent

2.3.1.2. Scénario2 : Supprimer un agent

2.3.1.3. Scénario3 : Modifier un agent

2.3.2 Cas d’utilisation : Gérer les stockes

2.3.2.1 Scénario1 : Ajouter un nouvel élément

2.3.2.2 Scénario2 : Ajouter une quantité pour un ancien élément

2.3.2.3 Scénario3 : Retrait d’une quantité

2.3.3 Cas d'utilisation : Afficher des informations

2.3.3.1 Scénario1: Afficher des informations

2.3.4 Cas d'utilisation: Imprimer des informations

Page 3: Copie de RAPPORT FINAL DE PFA

3

2.3.4.1 Scénario1: Imprimer des informations

2.4. Conclusion

Chapitre 3 : Mise en œuvre et Tests

3.1. Introduction

3.2. Réalisation

3.3. Tests de vérification

3.4. Conclusion

Conclusion et perspectives

Bibliographique

Page 4: Copie de RAPPORT FINAL DE PFA

4

Introduction général :

Pour approfondir mes études théorique et pratique dans un entourage plein

d’expérience, j’ai décidé d’effectuer un stage à TUNISIE TELECOM de Médenine

pendant 30 jours.

Ce stage, effectué à la direction Régionale de Télécom à Médenine durant 15/01/2009

au 15/02/2009 permet de faire connaissance avec le milieu socioprofessionnel, de

connaître plus des applications pratiques concernant le domaine de télécommunication

en manipulant quelques gestions et en voyant de près tout ce qu’il était des phrases

flottantes, et encore pour améliorer notre connaissance en informatique et plus

précisément en développement des programmes ( connaître tout ce qui est Analyse,

conception, base des données, programmations …).

Le but de ce projet est de développer une application permettant la gestion des agents, la

gestion des ordinateurs, la gestion des dérangements et la gestion de stocke pour de la

société Tunisie Télécom de Médenine.

J’espère que ce stage m’aidera à l’obtention de la maîtrise en informatique et plus

particulièrement d’enrichir mes connaissances et mes expériences dans ce domaine.

Notre rapport renferme trois chapitres : le premier présente l'expression des besoins et

spécification puis et dans le deuxième chapitre on va présenter la partie analyse et

conception . Finalement, la dernière chapitre présente mise en œuvre et Tests,

Page 5: Copie de RAPPORT FINAL DE PFA

5

Chapitre 1 : Expression des besoins et spécification

1.1. Introduction:

Dans ce chapitre, nous présenterons en premier lieu la société « Tunisie Télécom » et nous

décrirons en second lieu la procédure actuelle de suivi de son centre informatique.

En suite, nous allons évoquer les différents problèmes rencontrés dans ce centre, ainsi que

ses besoins exprimés. Enfin, nous passerons en revue les différents objectifs et

fonctionnalités de l’application réalisée.

1.2. Expression des besoins

1.2.1. Présentation de l’organisation et ces domaines d’activités:

1.2.1.1. Présentation de la société « Tunisie Télécom » :

1. Historique

L’office nationale des télécommunications est un établissement public à

caractère industriel et commercial ; il a été crée le 17/04/1995 et mis en place le

01/01/1996 identifiant son nom TUNISIE TELECOM et son capital et entièrement détenu

par l’état.

2. Activités

Actuellement, l’entreprise a pour objectif principale de moderniser son infrastructure

de télécommunication, diversifier et améliorer les services offerts aux abonnées. Ces

objectifs entre dans le cadre de renforcement de la position de l’entreprise et de sa

compétitivité en vue de faire face l’ouverture de la marche nationale de communication

devants des opérateurs étranges surtout pour le téléphone mobile et l’intégration de la

Tunisie dans la nouvelle économie mondiale.

En effet la réussite de la mise à niveau de cette entreprise passe par la mise en place

d’une infrastructure moderne et fiable de télécommunication permettant de satisfaire,

d’une part de besoin croissants en trafic tout en assurant la fiabilité et la sécurité des

transmissions, et d’autre part de fournir les services demandes par les entreprises qui

deviennent de plus en plus exigeant au niveau de qualité de service et de nouvelles

technologies tel que le réseaux à Haute début (le technologies xdsl,atm,fr,…)et le réseaux

numériques à intégration de services(RNIS).

Page 6: Copie de RAPPORT FINAL DE PFA

6

3. Fiche

Raison social : Direction Régionale de Télécoms à Médenine

Adresse : Avenu Mongi Slim 4100 Médenine

Téléphone : 75 643 555

Fax : 75 646 509

1.2.2. Contexte général du problème

Le but de cette étude est de découvrir la procédure actuelle utilisée pour la recherche et

la gestion d’une information au sein de la société « Tunisie Télécom » et plus précisément du

bureau de maintenance informatique.

Les opérations de recherche sont traitées manuellement, telle que la recherche de

l'adresse IP d’un agent et quelques informations pour tous les ordinateurs de chaque

direction de Tunisie Télécom et encore la recherche des quantités restantes dans son

entrepôt, ce qui maximise le temps de traitement d’informations.

1.2.3. Inventaire des problèmes, besoins et objectifs:

La procédure de gestion de ce centre ainsi décrite nous a permis de dégager les problèmes

suivants :

• La gestion des agents.

• La gestion des ordinateurs.

• La gestion des dérangements.

• La gestion des stockes.

• La recherche des informations.

• L'impression des informations.

Tous ces facteurs se réunissent pour accabler la gestion du bureau de maintenance

informatique au sein de la direction régional Tunisie Télécom.

Pour résoudre ces problèmes, le besoin à satisfaire est de diminuer le temps de recherche

et de facilite les gestions des agents, des ordinateurs, des dérangements et des stockes.

1.3. Spécification :

Après avoir présenté l’étape de l’« Expression des besoins », nous préciserons ensuite

les fonctionnalités que le système offrira à ses utilisateurs et les interactions qui peuvent

exister entre elles. Cette spécification a pour but de mieux comprendre le domaine de

Page 7: Copie de RAPPORT FINAL DE PFA

7

l’application pour bien définir les besoins et les exigences attendus.

1.3.1. Description détaillée du logiciel : Le modèle environnemental

La partie « Expression des besoins » permet d’identifier le seul acteur intervenant dans

ce système et ses événements associés de la façon suivante:

Acteur Evénements associés

Utilisateur - Gestion des agents (ajout, suppression et modification ).

- Gestion des ordinateurs (ajout, suppression et modification).

- Gestion des dérangements (ajout, suppression et modification).

- Gestion de stocke (ajout et retrait).

- Affichage des informations.

- Impression des informations.

Tableau 1. Le modèle environnemental

1.3.2. Gestion des besoins fonctionnels :

On s’intéressera généralement à décomposer le système en un ensemble de paquetages cohérents,

afin de diminuer sa complexité. Chaque paquetage, doit représenter un cas

d’utilisation permettant la réalisation d’une tâche bien déterminée.

L’application, peut être alors, décomposée en 6 cas d’utilisation, de la façon suivante :

• Gestion des Agents : ce module, contient toutes les fonctionnalités nécessaires

pour définir un agent, c'est-à-dire : ajout, suppression, modification des coordonnées d’un agent.

• Gestion des Ordinateurs : ce module, contient toutes les fonctionnalités permettant de

définir un ordinateur, c'est-à-dire : ajout, suppression et modification des coordonnées d’un

ordinateur.

• Gestion des dérangements : ce module, contient toutes les fonctionnalités nécessaires pour définir

un dérangement, c'est-à-dire : ajout, suppression et modification des coordonnées d’un dérangement.

• Gestion du stocke : ce module, contient toutes les fonctionnalités nécessaires pour

gérer le stocke, c'est-à-dire : ajout et retrait des éléments du l’entrepôt.

• Affichage des informations: ce module, contient toutes les fonctionnalités nécessaires pour

afficher des informations de tous les enregistrements (agents, ordinateurs…).

• Impression des informations: imprimer des informations qui sont déjà affichées

Page 8: Copie de RAPPORT FINAL DE PFA

8

1.4. Conclusion

A la fin de ce chapitre, nous avons pu mettre l’accent, sur les problèmes rencontrés et identifier les

besoins et les objectifs de la réalisation de ce projet. La partie spécification a permis d’identifier :

d’une part, l’acteur qui va réagir avec notre système, et d’autre part d’énumérer l’ensemble des cas

d’utilisation et leur structuration.

Dans le chapitre qui suit, on entame l’analyse et la conception où nous présenterons les diagrammes

nécessaires, pour mieux comprendre le système à développer. Pour la conception, nous avons choisi

d’adopter l’approche orientée objet, le langage de modélisation «UML» et le processus de

développement « RUP ».

Chapitre 2 : Analyse et Conception

Page 9: Copie de RAPPORT FINAL DE PFA

9

2.1. Introduction

Dans le chapitre précédent, nous avons pu mettre l’accent, sur les problèmes rencontrés et identifier

les besoins et les objectifs de la réalisation de ce projet. La partie spécification a permis d’identifier :

d’une part, l’acteur qui va réagir avec notre système, et d’autre part d’énumérer l’ensemble des cas

d’utilisation et leur structuration.

Dans ce chapitre, on entame l’analyse et la conception où nous allons présenter les diagrammes

nécessaires, pour mieux comprendre le système à développer. Pour la conception, nous avons choisi

d’adopter l’approche orientée objet vu sa contribution à l’évolution des applications complexes et

évolutives.

Le choix du langage de modélisation Unified Modeling Language « UML » se présente comme la

solution la plus adéquate du simple vu qu’il représente un langage pour s'exprimer clairement à l'aide

des concepts objets, et permettre de représenter des concepts abstraits (graphiquement), limiter les

ambiguïtés (parler un langage commun, ou avec un vocabulaire précis, indépendant des langages

orientés objet), faciliter l'analyse (simplifier la comparaison et l'évaluation des solutions) .

Nous avons choisi comme processus d’analyse et de conception le Rational Unified Process« RUP »,

qui est un processus de développement, proposé par Rational Software, est aussi modélisé avec UML.

Il offre un cadre méthodologique générique qui repose sur UML et la suite d'outils Rational .

Le choix de RUP est justifié par le fait que :

• La gestion des exigences est conduite selon un processus systématique en passant par explicitation

des besoins, leur organisation et la gestion des futurs changements.

• La pratique du développement itératif et incrémental, ce qui consiste à découper le projet en petites

parcelles logiquement congrues et de progresser ainsi à petits pas comme s'il s'agissait d'une suite de

mini projets.

• On y accorde une grande importance à l'architecture logicielle et à la réutilisation de composants.

• Le processus RUP est basé sur l'utilisation du standard UML pour modéliser le produit sous ses

différentes vues, Etc. .

Nous avons réalisé la conception de ce projet à l’aide de Rational Rose.

1.2. Diagramme de cas d’utilisation:

Page 10: Copie de RAPPORT FINAL DE PFA

10

La figure 1 présente le diagramme de cas d’utilisation

Figure 1. Diagramme de cas d’utilisation

2.3. Description des cas d’utilisation

2.3.1 Cas d’utilisation : Gérer les agents

Pour ce cas d’utilisation nous avons prévu 3 scénarios qui sont : ajout, modification, et suppression

d’un agent.

Je insiste que ce travail doit répéter de même pour deux autres cas : Gérer les ordinateurs et Gérer

les dérangements.

2.3.1.1. Scénario1 : Ajouter un agent 

Scénario nominal   :

1- L’utilisateur saisir tous les informations pour un agent.

2- L’utilisateur clique sur le bouton « Ajouter »

3- Le système doit vérifier que tous les informations sont saisies

Page 11: Copie de RAPPORT FINAL DE PFA

11

4- Le système doit vérifier que ce matricule existe déjà dans la base de données ou non.

5- Le système accepte ces informations et les enregistre dans la base de données.

Enchainement alternatifs   :

A1 : La matricule existe déjà dans la base de données.

1. Le système indique à l’utilisateur que ce matricule existe déjà.

Le scenario nominal reprend au 1.

Enchainement d’erreur   :

E1 : Des informations non saisies.

L’enchainement E1 démarre au point 1 du scénario nominal.

2 . Le système indique à l’utilisateur qu’il a des informations manquantes.

E2 : Matricule est erroné.

L’enchainement E2 démarre au point 1 du scénario nominal.

3 . Le système indique à l’utilisateur que le matricule est erroné.

Page 12: Copie de RAPPORT FINAL DE PFA

12

La figure 2 présente le diagramme de séquence de scenario nominal de sous cas d'utilisation:

Ajouter un agent.

Figure 2. Diagramme de séquence N°1

2.3.1.2. Scénario2 : Supprimer un agent

Scénario nominal   :

1-L’utilisateur saisi le matricule.

2-L’utilisateur clique sur le bouton « Rechercher »

3-Le système vérifie que ce matricule existe dans la base de données ou non.

4-Le système accepte ce matricule et affiche les informations.

5-L’utilisateur clique sur le bouton « Supprimer»

6-Le système supprime tous les informations.

Enchainement alternatifs   :

A1 : Le matricule n’existe pas dans la base de données.

3-Le système indique à l’utilisateur que ce matricule n’existe pas .

Le scenario nominal reprend au 1.

Enchainement d’erreur   :

Page 13: Copie de RAPPORT FINAL DE PFA

13

E1 : Le matricule est erroné.

L’enchainement E1 démarre au point 1 du scénario nominal.

3- Le système indique à l’utilisateur que le matricule est erroné.

La figure 3 présente le diagramme de séquence de scenario nominal de sous cas d'utilisation:

Supprimer un agent.

Figure 3. Diagramme de séquence N°2

2.3.1.3. Scénario3 : Modifier un agent:

Scénario nominal   :

1- L’utilisateur saisi le matricule.

2- L’utilisateur clique sur le bouton « Rechercher »

3- Le système vérifie que ce matricule existe dans la base de données ou non.

4- Le système accepte ce matricule et affiche les informations.

5- L’utilisateur modifie un ou plusieurs informations.

6- L’utilisateur clique sur le bouton « Modifier»

7- Le système modifie les informations.

Enchainement alternatifs   :

Page 14: Copie de RAPPORT FINAL DE PFA

14

A1 : Le matricule n’existe pas dans la base de données.

3-Le Telecom indique à l’utilisateur que ce n’existe pas.

Le scenario nominal reprend au 1 .

Enchainement d’erreur   :

E1 : Le matricule est erroné.

L’enchainement E1 démarre au point 1 du scénario nominal.

3- Le Telecom indique à l’utilisateur que le matricule est erroné.

La figure 4 présente le diagramme de séquence de scenario nominal de sous cas d'utilisation:

Modifier un agent.

Figure 4. Diagramme de séquence N°3

Diagramme de classe:

La figure 5 présente le diagramme de classe de cas d'utilisation: Gérer des agents.

Page 15: Copie de RAPPORT FINAL DE PFA

15

Figure 5. Diagramme de classe N°3

2.2.2 Cas d’utilisation : Gérer les stockes

Pour ce cas d’utilisation nous avons prévu 4 scénarios qui sont : affichage de la quantité

restant, ajout d’un nouvel élément, ajout d’une quantité à un ancien élément, retrait d’une

quantité d’un élément de l’entrepôt.

2.2.2.1. Scénario1 : Ajouter un nouvel élément

Scénario nominal   :

1- L’utilisateur saisit tous les informations pour un nouvel élément.

2- L’utilisateur clique sur le bouton « Ajouter »

3- Le système doit vérifier que tous les informations sont saisies

4- Le système doit vérifier que cet élément existe déjà dans la base de données ou non.

5- Le système accepte ces informations et les enregistre dans la base de données.

Enchainement alternatifs   :

A1 : Cet élément existe déjà dans la base de données.

2. Le système indique à l’utilisateur que cet élément existe déjà.

Le scenario nominal reprend au 4.

Enchainement d’erreur   :

E1 : Des informations non saisies.

L’enchainement E1 démarre au point 3 du scénario nominal.

2 . Le système indique à l’utilisateur qu’il a des informations manquantes.

Page 16: Copie de RAPPORT FINAL DE PFA

16

La figure 6 présente le diagramme de séquence de scenario nominal de sous cas d'utilisation:

Ajouter un nouvel élément.

Figure 6. Diagramme de séquence N°1

2.2.2.2. Scénario2: Ajouter une quantité à un ancien élément

Scénario nominal   :

1- L’utilisateur choisit le nom et le type d’un composant et saisit la quantité.

2- L’utilisateur clique sur le bouton « Ajouter ».

3- Le système vérifie que toutes les informations sont existées.

4- Le système vérifie que la quantité saisie est bien formé (un entier positif).

5- Le système accepte ces informations et les enregistre dans la base de données.

Enchainement d’erreur   :

E1 : Des informations non saisies.

L’enchainement E1 démarre au point 2 du scénario nominal.

4 . Le système indique à l’utilisateur qu’il a des informations manquantes.

E2 : La quantité est erronée.

L’enchainement E2 démarre au point 2 du scénario nominal.

5 . Le système indique à l’utilisateur que la quantité est erronée

Page 17: Copie de RAPPORT FINAL DE PFA

17

La figure 7 présente le diagramme de séquence de scenario nominal de sous cas d'utilisation:

Ajouter une quantité à un ancien élément.

Figure 7. Diagramme de séquence N°2

2.2.2.3. Scénario3 : Retirer une quantité:

 Scénario nominal   :

1- L’utilisateur choisit le nom et le type de composant et saisit la quantité qu’il veut retirer.

2- Le système vérifie que tous les informations sont tapées.

3- Le système vérifie que la quantité tapée est inférieur à celle qui existe dans l’entrepôt.

4- Le système accepte le retrait et enregistre la nouvelle quantité.

Enchainement alternatifs   :

A1 : La quantité tapés est supérieur à celle existe dans l’entrepôt.

3. Le système indique à l’utilisateur que la quantité demandée est supérieur à celle qui existe

dans l’entrepôt.

Le scenario nominal reprend au 1.

Enchainement d’erreur   :

E1 : Des informations non saisies.

L’enchainement E1 démarre au point 2 du scénario nominal.

3 . Le système indique à l’utilisateur qu’il a des informations manquantes.

Page 18: Copie de RAPPORT FINAL DE PFA

18

E2 : La quantité est erronée.

L’enchainement E2 démarre au point 2 du scénario nominal.

4 . Le système indique à l’utilisateur que la quantité est erronée

La figure 8 présente le diagramme de séquence de scenario nominal de sous cas d'utilisation:

Retirer une quantité.

Figure 8. Diagramme de séquence N°3

Diagramme de classe:

Page 19: Copie de RAPPORT FINAL DE PFA

19

La figure 9 présente le diagramme de classe de cas d'utilisation: Gérer les stockes.

Figure 9. Diagramme de classe N°2

2.2.3 Cas d’utilisation : Afficher les informations

Pour ce cas d’utilisation nous avons prévu 1 scénario qui est l'affichage d'un élément .

2.2.3.1. Scénario1 : Afficher les informations.

Scénario nominal   :

1- L’utilisateur saisit le matricule.

2- L’utilisateur clique sur le bouton « Rechercher »

3- Le système vérifie que ce matricule existe dans la base de données ou non.

4- Le système accepte ce matricule et affiche les informations.

Enchainement alternatifs :

A1 : Le matricule n’existe pas dans la base de données.

3-Le système indique à l’utilisateur que ce matricule existe déjà.

Le scenario nominal reprend au 3.

Enchainement d’erreur :

E1 : Le matricule est erroné.

L’enchainement E1 démarre au point 3 du scénario nominal.

2- Le système indique à l’utilisateur que le matricule est erroné.

La figure 10 présente le diagramme de séquence de scenario nominal de sous cas d'utilisation:

Afficher les informations.

Page 20: Copie de RAPPORT FINAL DE PFA

20

Figure 10. Diagramme de séquence N°1

Diagramme de classe:

La figure 11 présente le diagramme de classe de cas d'utilisation: Afficher des informations.

Figure 11. Diagramme de classe N°3

2.2.4 Cas d’utilisation : Imprimer les informations

Pour ce cas d’utilisation nous avons prévu 1 scénario qui est l'impression.

Scénario1 : Imprimer les informations.

Scénario nominal   :

1. L’utilisateur saisit la matricule.

2. L’utilisateur clique sur le bouton « Afficher tout ».

3. Le système affiche tous les informations dans un tableau.

Page 21: Copie de RAPPORT FINAL DE PFA

21

4. L’utilisateur clique sur le bouton « Imprimer ».

5. Le système imprime les informations.

La figure 12 présente le diagramme de séquence de scenario nominal de sous cas d'utilisation:

Imprimer les informations.

Figure 12. Diagramme de séquence N°1

Diagramme de classe:

La figure 4 présente le diagramme de classe de cas d'utilisation: Imprimer les informattions.

Page 22: Copie de RAPPORT FINAL DE PFA

22

Figure 13. Diagramme de classe N°4

2.3. Conclusion

Dans ce chapitre, nous avons essayé de donner une vision claire et rigoureuse du problème posé

et du système à réaliser en déterminant ses éléments et leurs interactions. Le résultat a été présenté

en divers diagrammes.

Dans le chapitre qui suit, nous allons passer à l’étape de l’implémentation de la base de

données et de l’application.

Chapitre 3 : Mise en œuvre et Tests

Page 23: Copie de RAPPORT FINAL DE PFA

23

3.1. Introduction

Dans le chapitre précédent, nous avons essayé de donner une vision claire et rigoureuse du problème

et du système à réaliser en déterminant ses éléments et leurs interactions. Le résultat a été présenté en

divers diagrammes.

Dans ce chapitre, nous allons passer à l’étape de l’implémentation de la base de données

et de l’application.

Pour élaborer notre projet nous avons utilisé VB.Net 2008 (Microsoft Visuel Basic version 2008)

comme un langage de programmation et Microsoft SQL Server 2000 comme un Système de Gestion

de Base de Données.

• Choix de VB.Net   :

VB.Net est une commande fournier par le groupe Microsoft, représente une grande importance

car elle combine entre la commande graphique et le programmeur et encore il facilite la connexion

avec la base des données.

• Choix de SQL Server 2000   :

SQL Server 2000 est un système de gestion de base de données relationnelle de Microsoft.

Son emploi présente plusieurs bénéfices, vu qu’il est exceptionnellement évolutif et fiable.

3.2. Réalisation :

a- Gestionnaire des agents :

Page 24: Copie de RAPPORT FINAL DE PFA

24

L’interface de gestion des agents est la suivante :

Figure14 . Gestion des agents

A partir de laquelle, l’utilisateur peut :

• Ajouter un agent

• Modifier les informations d'un agent.

• Supprimer un agent.

• Imprimer la liste des agents.

• Rechercher les informations d'un agent.

Pour les boutons Rechercher, Modifier ,Afficher tout, et Supprimer, la saisie du champ matricule

est obligatoire.

Et pour le bouton Ajouter il faut remplir tous les champs.

b- Gestion des ordinateurs :

L’interface de gestion des agents est la suivante :

Page 25: Copie de RAPPORT FINAL DE PFA

25

Figure15 : Gestion des ordinateurs

A partir de laquelle, l’utilisateur peut :

• Ajouter un ordinateur

• Modifier les paramètres d'un ordinateur.

• Supprimer un ordinateur.

• Rechercher les paramètres d'un ordinateurs.

Pour les boutons Rechercher, Modifier ,Afficher tout, et Supprimer, la saisie du champ matricule

est obligatoire.

Et pour le bouton Ajouter il faut remplir tous les champs.

c- Gestion des dérangements :

L’interface de gestion des dérangements est la suivante :

Page 26: Copie de RAPPORT FINAL DE PFA

26

Figure16 : Gestion des dérangements

A partir de laquelle, l’utilisateur peut :

• Ajouter un dérangement.

• Modifier les informations pour un dérangement.

• Supprimer un ordinateur.

• Rechercher des informations pour un dérangement.

• Imprimer les informations pour un dérangement.

Pour les boutons Rechercher, Modifier, Afficher tout et Supprimer, la saisie du champ matricule

est obligatoire.

Et pour le bouton Ajouter il faut remplir tous les champs.

d – Gestion des stockes :

L’interface de gestion des stockes est la suivante :

Page 27: Copie de RAPPORT FINAL DE PFA

27

Figure17 : Gestion de stocke

A partir de laquelle, l’utilisateur peut :

• Ajouter un nouvel élément.

• Ajouter une quantité pour un ancien élément.

• Retirer une quantité.

• Afficher les quantités restantes

Pour le bouton Ajouter il faut remplir tout les champs, mais pour les autres il faut choisir le nom

et le type de la liste.

3.3. Tests de vérification :

Les tests de vérification permettent de s’assurer que le système a été construit correctement,

sans erreurs de conception et de programmation. Ils ont pour objectif de contrôler le travail

effectué par les développeurs et de relever tous les défauts de conception et d’implémentation,

afin de garantir la robustesse et la cohérence du système. Il faut signaler le fait que les

composants ne doivent pas être testés par les individus qui les ont conçus et/ou implémentés,

mais plutôt par les utilisateurs du système.

3.4. Conclusion :

Page 28: Copie de RAPPORT FINAL DE PFA

28

Ainsi nous avons pu réaliser notre logiciel qui gère quelque gestions au sein de la société.

Conclusion et perspectives

Page 29: Copie de RAPPORT FINAL DE PFA

29

Ce projet était une bonne occasion pour appliquer nos connaissances théoriques requises le long

de notre formation dans le cycle d’ingénieur dans la vie pratique.

Ce système couvre la gestion des agents, des ordinateurs, des dérangements et les stockes.

Pour la conduite de ce projet informatique, nous avons adopté l’approche orientée objet, la

notation UML et le processus de développement RUP pour l’analyse et conception de l’application,

Microsoft SQL Server pour la gestion des bases de données sous la version 2000, le langage de

programmation VB.Net pour le développement de l’interface graphique.

Nous avons présenté au premier lieu « Tunisie Télécom » ainsi que les différents objectifs que notre

application devrait atteindre. Nous avons analysé et fait la conception du notre système, en second

lieu. Et troisième lieu nous avons expliqué la phase de réalisation, de tests de vérification et

validation.

Enfin, nous espérons que ce travail soit réussi et ouvre la voie pour d’autres projets et travaux

intéressants.

Bibliographie :

www.labo-dotnet.com www.developpez.com www.codes-sources.com