WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

Conception et réalisation d'une application de gestion des marchés par appel d'offres au sein de l'Entreprise Tunisienne d'Activités Pétrolières

( Télécharger le fichier original )
par Helmi GNICHI
Institut supérieur d'informatique Tunisie - Diplôme national d'ingénieur 2012
  

précédent sommaire suivant

Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy

3.1.3 Diagramme de cas d'utilisation général

Figure 3: Diagramme de cas d'utilisation général

 
 

Chapitre II : Spécification et analyse des besoins

3.1.4 Affectation des priorités

Les cas d'utilisation peuvent être classés selon leur ordre d'importance pour chacun des acteurs. Ce classement donne lieu à la définition d'un ordre de priorité pour les cas d'utilisation.

Dans notre cas, les cas d'utilisation qui s'avèrent les plus prioritaires ont la priorité la plus forte « 1 » et les moins prioritaires ont la priorité « 2 ».

Ceci est représenté dans le tableau ci-dessous :

Cas Utilisation 6'ar,hLQ,ifiLI

Acteur

Tous les utilisateurs

Priorité 1

Gérer Marché

L'opérateur Service Marché

1

Gérer Commission

L'opérateur Service Marché

1

Gérer soumissionnaire

L'opérateur Service Marché

1

Consulter situation marché

Direction initiatrice

1

Initialiser marché

Direction initiatrice

1

Valider cahier des charges

Direction Initiatrice

Direction administrative et juridique

2

Valider contrat

Direction administrative et juridique

2

Proposer membre de la commission

Direction administrative et juridique

2

Ajouter plis

Responsable bureau ordre central

1

Tableau 2:Affectation des priorités des cas d'utilisations

 
 

Chapitre II : Spécification et analyse des besoins

3.1.5 Raffinement des cas utilisation prioritaire

a Raffinement du cas d'utilisation « S'authentifier »

Figure 4: Raffinement CU S'authentifier

Cas Utilisation : « S'authentifier Acteur principal

»

bous les utilisateurs du système

Pré-condition

L'utilisateur est connecté au serveur

Post-condition

L'utilisateur est connecté au système, et redirigé vers la section qui lui convient

Scénario nominal

1) L'utilisateur saisit son login et mot de passe

2) L'utilisateur valide

3) Le système vérifie les données saisies

Exception

Un message d'erreur est affiché le cas d'essais échéant

Tableau 3:Description textuelle du CU S'authentifier

 
 

Chapitre II : Spécification et analyse des besoins

b Raffinement du cas d'utilisation « Gérer Marché »

Figure 5: Raffinement CU « Gérer marché »

Acteur principal

Cas Utilisation : « Gérer marché » L'opérateur Service Marché

Pré-condition

L'opérateur service marché doit être connecté au serveur et identifié

Post-condition

S'il y a des modifications concernant un marché elles sont enregistrées dans la base de données

Scénario nominal

1) Le système affiche une liste de marchés

2) L'opérateur Service Marché peut ajouter un nouvel marché

3) L'opérateur Service Marché choisit un marché

L'opérateur Service Marché peut modifier un marché L'opérateur Service Marché saisit les nouvelles données

L'opérateur Service Marché confirme la modification Le système enregistre les nouvelles données

4) L'opérateur Service Marché peut supprimer le marché sélectionné

Le système demande une confirmation de suppression L'opérateur Service Marché confirme

Le système enregistre la suppression

5) L'opérateur Service Marché peut faire ainsi les différentes opérations de gestion sur les offres (Consultation des offres existantes, Ajout de nouvelle offre, suppression d'une offre ou bien mise à jour d'une offre) concernant un marché sélectionné

Exception

Un message d'erreur est affiché le cas échéant

Tableau 4:Description textuelle du CU Gérer marché

 
 

Chapitre II : Spécification et analyse des besoins

c Raffinement du cas d'utilisation « Gérer Commission »

Figure 6:Raffinement CU « Gérer commission »

Acteur principal

Cas Utilisation : « Gérer commission » L'opérateur Service Marché

Pré-condition

L'opérateur service marché doit être connecté au serveur et identifié

Post-condition

S'il y a des modifications concernant une commission elles sont enregistrées dans la base de données

Scénario nominal

1) Le système affiche une liste des commissions

2) L'opérateur Service Marché peut ajouter une nouvelle commission

3) L'opérateur Service Marché choisit une commission L'opérateur Service Marché peut modifier la commission L'opérateur Service Marché saisie les nouvelles données L'opérateur Service Marché confirme la modification Le système enregistre les nouvelles données

4) L'opérateur Service Marché peut supprimer la commission sélectionnée

Le système demande une confirmation de suppression L'opérateur Service Marché confirme

Le système enregistre la suppression

5) L'opérateur Service Marché peut affecter la commission a un marché

Exception

Un message d'erreur est affiché le cas échéant

Tableau 5:Description textuelle du CU Gérer commission

 
 

Chapitre II : Spécification et analyse des besoins

d Raffinement du cas d'utilisation « Gérer Soumissionnaire »

Figure 7:Raffinement CU « Gérer Soumissionnaire »

Acteur principal

Cas Utilisation : « Gérer soumissionnaire » L'opérateur Service Marché

Pré-condition

L'opérateur service marché doit être connecté au serveur et identifié

Post-condition

S'il y a des modifications concernant un ou plusieurs soumissionnaires elles sont enregistrées dans la base de données

Scénario nominal 1

1) Le système affiche une liste de soumissionnaires

2) L'opérateur Service Marché choisit un soumissionnaire

2.1) L'opérateur Service Marché peut modifier les données du

soumissionnaire sélectionné

2.1.1) L'opérateur Service Marché saisit les nouvelles données Confirme la modification

2.1.2) Le système enregistre les nouvelles données

2.2) L'opérateur Service Marché peut supprimer le soumissionnaire

sélectionné

2.2.1) Le système demande une confirmation de suppression

2.2.2) L'opérateur Service Marché confirme

2.2.3) Le système enregistre la suppression

3) L'opérateur Service Marché peut ajouter un nouvel soumissionnaire

Exception

Un message d'erreur est affiché le cas échéant

Tableau 6:Description textuelle du CU Gérer soumissionnaire

 
 

Chapitre II : Spécification et analyse des besoins

e Raffinement du cas d'utilisation « Consulter situation marché»

Figure 8: Raffinement CU « Consulter situation marché »

Acteur principal

Cas Utilisation : « Consulter situation marché » Direction initiatrice

Pré-condition

L'utilisateur doit être connecté au serveur et identifié

Post-condition

Les détails concernant la situation actuelle du marché sont affichés

Scénario nominal

1) Le système affiche la situation du dernier marché lancé par la direction

2) Le système affiche une liste de tous les marchés lancé par la direction

3) L'utilisateur choisit un marché

4) Le système affiche la situation du marché sélectionné

Exception

Si la direction n'a lancé aucun marché, un message d'information est affiché

Tableau 7:Description textuelle du CU Consulter situation marché

f Raffinement du cas d'utilisation « Initialiser marché»

Figure 9: Raffinement CU « Initialiser marché »

Acteur principal

Cas Utilisation : « Initialiser marché » Direction initiatrice

Pré-condition

L'utilisateur doit être connecté au serveur et identifié

Post-condition

Les données concernant le nouvel marché initié sont enregistrées

Et un mail de notification est envoyé vers le service marché, ainsi que la direction juridique et administrative

Scénario nominal

1) L'utilisateur saisit les données du nouveau marché

2) L'utilisateur valide

3) Le système enregistre le nouveau marché

Exception

Un message d'erreur est affiché dans le cas marché déjà initié

Tableau 8:Decription textuelle du CU Initialiser marché

 
 

Chapitre II : Spécification et analyse des besoins

Cas Utilisation :« Ajouter pli»

Acteur principal Bureau ordre central

Pré-condition L'utilisateur doit etre connecté au serveur et identifié

Post-condition Le pli est enregistré dans la base de données

Scénario nominal 1) Le système affiche une liste de marché en phase de réception de plis

2) L'agent du Bureau Ordre Centrale choisit un marché

3) L'utilisateur saisit les données du no

4) L'utilisateur valide

5) Le système enregistre le pli

Exception Si un pli déjà. ajouté un message d'en-eur est affiché

g Raffineme17 du caM3utilisation « Ajouter plis»

Figure 10: Raffinement CU « Ajouter plis »
Tableau 9:Description textuelle du CU Ajouter plis

précédent sommaire suivant






Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy








"I don't believe we shall ever have a good money again before we take the thing out of the hand of governments. We can't take it violently, out of the hands of governments, all we can do is by some sly roundabout way introduce something that they can't stop ..."   Friedrich Hayek (1899-1992) en 1984