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

Introduction générale

Afin que l'entreprise puisse s'adapter à un environnement en mouvance continue et perpétuelle générée par une croissance et évolution technique et scientifique rapide, elle se trouve dans l'obligation d'établir une stratégie basée sur des moyens techniques et humains dont elle dispose. C'est dans ce cadre que l'Entreprise Tunisienne d'Activités Pétrolières envisage automatiser ses activités. Parmi ces activités, la gestion des achats et plus spécifiquement celle par appel d'offres.

La gestion informatisée des appels d'offres intéresse de plus en plus les entreprises soucieuses de réduire leurs coüts, le recours aux appels d'offres permet en effet d'effectuer des achats plus adaptés à leurs besoins, de mieux faire jouer la concurrence, et de faire baisser les prix. Seulement cette gestion demande du temps, des ressources et des compétences afin d'en récolter les avantages.

Le but de l'appel d'offres est de réaliser une prestation de travaux, de fournitures ou de service et de mettre pour cela plusieurs entreprises en concurrence, afin d'obtenir un produit ou un service. Le choix du soumissionnaire qui sera un fournisseur vient suite à plusieurs commissions qui discuteront les offres selon les différentes soumissions.

Le processus commence par l'initiation d'un marché, préparation du cahier des charges, affectation des commissions et dépouillement des différentes offres et enfin le choix d'un soumissionnaire final, la notification de ce dernier et la contractualisation.

Dans ce contexte et dans et dans le cadre de mon projet de fin d'études, je suis amené à concevoir et à réaliser l'informatisation d'une application permettant le suivi des marchés par appel d'offres.

Le présent rapport est organisé comme suit :

Le premier chapitre « présentation générale », est un chapitre introductif où nous présentons le cadre du travail pour notre projet.

Le deuxième chapitre intitulé «Spécifications et analyse des besoins», est consacré au
recensement et à l'analyse des besoins exprimés par les utilisateurs et sur lesquels nous

sommes basés pour la réalisation de notre projet.

Concernant le troisième chapitre intitulé « Conception », nous étendons la représentation des diagrammes effectués au niveau de l'analyse en y intégrant les aspects techniques les plus proches des préoccupations physique.

Enfin, nous nous intéressons dans le dernier chapitre « Implémentation et réalisation », à l'implémentation et à la réalisation de l'application. Une description du système à travers les interfaces développées est effectuée. Dans ce même chapitre nous présentons les perspectives ainsi que les améliorations que nous pouvons apportées à notre application.

Le rapport est clôturé par une conclusion générale où nous résumons notre travail et nous décrivons les apports offerts par ce stage.

CHAPITRE 1
Présentation Générale

Sommaire

· Introduction

· Présentation de l'entreprise d'accueil

· Etude de l'existant

· Méthodologie adopté
· Conclusion

Chapitre I : Présentation générale

1 Introduction

Dans ce chapitre, nous exposons le contexte général de notre projet. En effet, nous présentons la société accueillante, à savoir l'Entreprise Tunisienne d'Activités Pétrolières (ETAP). Par la suite, nous introduisons notre problématique qui consiste à concevoir et réaliser une application de gestion du marché par appel d'offres.

2 Présentation de l'entreprise d'accueil

2.1 Fiche identité

Raison sociale : Entreprise Tunisienne d'Activités Pétrolières Forme juridique : Entreprise Publique

Création : L'ETAP est créée en 1972

Adresse : 54, Avenue Mohamed V - 1002 Tunis, Tunisie Tel: [phone]

Fax: [phone]

Web: http://www.etap.com.tn/

2.2 Mission de l'ETAP

L'ETAP à pour rôles essentiels la promotion de la recherche et la production du pétrole et du gaz en Tunisie ainsi que le suivi et le contrôle de ces activités pour le compte de l'état Tunisien. Les principales activités de de l'ETAP sont :

n Gérer l'exploration et la production d'hydrocarbures pour le compte de l'Etat Tunisien.

n Produire les hydrocarbures qui permettront à la Tunisie d'accélérer son développement économique et d'asseoir son positionnement sur l'échiquier mondial.

n Le développement des ressources humaines dans le domaine pétrolier.

Chapitre I : Présentation générale

2.3 Organigramme de l'ETAP

Figure 1: Organigramme de l'ETAP

Chapitre I : Présentation générale

3 Etude de l'existant

3.1 Contexte du système

Un appel d'offres est une procédure qui permet à une entreprise de limiter les coûts d'acquisition d'un bien ou d'un service tout en garantissant la meilleure qualité possible. Le but est de mettre plusieurs entreprises en concurrence.

Toute direction de l'ETAP peut initier un appel d'offres suite à un besoin spécifique exprimé. La démarche de passation d'un marché s'effectue en suivant les étapes ci-dessous :

3.1.1 Appel d'offres

Après la rédaction du cahier des charges ainsi que l'avis d'appel d'offres, ce dernier doit être publié dans les journaux, sur le site officiel de l'ETAP et sur le site national des marchés publics. L'objectif est d'informer les soumissionnaires intéressés tout en fixant le délai du dépôt des dossiers.

3.1.2 Réception des plis

Chaque soumissionnaire intéressé par l'acquisition de ce marché doit déposer son offre. Les plis doivent être enregistrés au Bureau d'Ordre Central ; ils doivent rester cachetés et scellés jusqu'à leurs ouvertures par les commissions compétentes.

3.1.3 Ouverture des plis

Une commission dite « Commission d'ouverture des plis », formée par des membres du personnel de l'ETAP sera requise par le service marché pour ouvrir les plis. Cette commission va analyser, du point de vue administratif, les offres concernant le marché pour tout dossier incomplet elle invitera le soumissionnaire à le compléter.

3.1.4 Dépouillement technique et financier

Des membres du personnel de l'ETAP sont proposés par les différentes directions. Ils forment une Commission de dépouillement technique et financier. Cette commission est invitée par le Service Marché à étudier et analyser les offres sur le plan technique en se basant sur les critères annoncés dans le cahier des charges, puis sur le plan financier en étudiant les prix proposés par les soumissionnaires dont les offres ont été admises au niveau technique, en cherchant à minimiser le coût du marché.

Chapitre I : Présentation générale

Une fois l'analyse achevée, les offres retenues sont validées (signées) par chaque membre. La commission de dépouillement technique et financier adresse au Service Marché un ProcèsVerbal (PV) qui explique les raisons de cette sélection. Les soumissionnaires non sélectionnés seront informés par la suite du refus de leurs offres.

3.1.5 Approbation, exécution et suivi des marchés

Après le Dépouillement technique et financier des offres, les structures concernées par le marché sont invitées à déterminer le soumissionnaire adéquat pour acquérir le marché, parmi ceux retenus. Le Service Marché doit donc informer le titulaire de marché.

3.1.6 Contractualisation

Le titulaire de marché doit signer le contrat du marché. 3.2 Problématique

Notre mission à l'ETAP consiste à concevoir et développer une application de gestion des marchés publics qui assure toutes les fonctionnalités de gestion ainsi le suivi dans toutes les phases du marché.

4 Méthodologie adopté

Une méthodologie de développement logiciel, composée d'un formalisme et un processus, est une démarche à suivre afin de créer des classes avec leurs attributs, leurs méthodes et les relations entre celles-ci pour réaliser une application spécifique. Elle permet d'augmenter grandement la productivité, d'estimer le temps de développement et de créer des applications plus robustes.

Un processus est une démarche méthodologique, qui définit une séquence d'étapes, partiellement ordonnées, qui concourent à l'obtention d'un système logiciel ou à l'évolution d'un système existant. L'objet d'un processus de développement est de produire des logiciels de qualité qui répondent aux besoins de leurs utilisateurs dans des temps et des coûts prévisibles. Plus simplement, un processus doit permettre de répondre à la question fondamentale : " Qui fait quoi et quand ? ".

Chapitre I : Présentation générale

4.1 Processus adopté

Rational Unified Process (RUP) à plusieurs atouts :

· Le changement est mieux géré, car il est possible de recadrer le projet après une itération.

· Meilleur niveau de portabilité grace à l'utilisation de l'UML (Unified Modelling Language).

· Vérification constante de la qualité.

RUP est une démarche de développement qui est souvent utilisé conjointement au langage UML

Rational Unified Process est basé sur trois principes :

· Piloté par les cas d'utilisation

o La principale qualité d'un logiciel est son utilité

· Adéquation du service rendu par le logiciel avec les besoins des utilisateurs

o Le développement d'un logiciel doit être centré sur l'utilisateur

o Les cas d'utilisation permettent d'exprimer ces besoins

· Détection et description des besoins fonctionnels

· Organisation des besoins fonctionnels

· Centré sur l'architecture

o Modélisation de différentes perspectives indépendantes et complémentaires o Architecture en couches et vues

Vue logique

Vue cas
d'utilisation

Vue déploiement

Vue composants

Vue
implémentation

Figure 2: Les vues en RUP

			Chapitre I : Présentation générale

· Vue du système

- Vue cas d'utilisation

Description du système comme un ensemble de transactions du point de vue de l'utilisateur

· Vue logique

- Créée lors de la phase d'élaboration et raffinée lors de la phase de construction

- Utilisation de diagrammes de classes, de séquences...

· Vue composants

- Description de l'architecture logicielle

· Vue déploiement

- Description de l'architecture matérielle du système

· Vue implémentation

- Description des algorithmes, code source

· Itératif et incrémental

o Chaque itération prend en compte un certain nombre de cas d'utilisation.

o Chaque itération donne lieu à un incrément et produit une nouvelle version.

Rational Unified Process organise le développement en phases

· Phase de création « Incubation »

Traduit une idée en vision de produit fini et présente une étude de rentabilité pour ce produit

Que va faire le système pour les utilisateurs ?

A quoi peut ressembler l'architecture d'un tel système ?

Quels sont l'organisation et les coüts du développement de ce produit ? On fait apparaître les principaux cas d'utilisation.

L'architecture est provisoire, identification des risques majeurs et planification de la phase d'élaboration.

· Phase d'élaboration

Permet de préciser la plupart des cas d'utilisation et de concevoir l'architecture du système. L'architecture doit être exprimée sous forme de vue de chacun des modèles. A l'issue de cette phase, on doit être en mesure de prévoir les activités et d'estimer les ressources nécessaires à l'achèvement du projet.

			Chapitre I : Présentation générale

? Phase de construction

Moment où l'on construit le produit. L'architecture de référence se métamorphose en produit complet, elle est maintenant stable. Le produit contient tous les cas d'utilisation qui ont été décidé de mettre au point pour cette version. Celle-ci doit encore avoir des anomalies qui peuvent être en partie résolue lors de la phase de transition.

? Phase de transition

Le produit est en version beta. Un groupe d'utilisateurs essaye le produit et détecte les anomalies et défauts. Cette phase suppose des activités comme la fabrication, la formation des utilisateurs clients, la mise en oeuvre d'un service d'assistance et la correction des anomalies constatées. (Où le report de leur correction à la version suivante).

5 Conclusion

Après avoir présenté le contexte du projet et après avoir mis en place une démarche de développement à suivre tout au long la réalisation de notre application, nous passons dans le chapitre suivante à une nouvelle étape qui consiste a décortiquer le cahier des charges pour analyser les besoins recensés.

CHAPITRE 2

Spécifications

et analyse

des besoins

Sommaire

· Introduction

· Spécifications des besoins

· Analyse des besoins

· Conclusion

			Chapitre II : Spécification et analyse des besoins

1 Introduction

L'objectif de l'application est la gestion et le suivi des marchés par appel d'offre en plus d'autres fonctionnalités assurant l'interaction entre les utilisateurs de l'application et le bon déroulement de l'exécution d'un marché. Au niveau de ce chapitre, qui constitue la première phase du processus unifié « incubation », nous détaillons et analysons les besoins fonctionnels et non fonctionnels de notre projet.

2 Spécifications des besoins

2.1 Besoins fonctionnels

Un besoin fonctionnel spécifie l'action qu'un système doit être capable d'effectuer, hors contrainte physique : besoin spécifiant un comportement d'entrée/sortie d'un système.

La gestion des marchés publics doit être assurée durant toutes ses phases, dès l'initiation jusqu'à la clôture. La première étape du marché est la rédaction du cahier des charges contenant toutes les spécifications détaillées, puis la publication d'un appel d'offres. Une fois les offres reçues il faut procéder au dépouillement des offres et l'analyse de ces dernières afin de sélectionner un seul fournisseur.

Dans ce contexte notre application de gestions des appels d'offres, implémente les fonctionnalités suivantes:

· Gestion des marchés :

o Créer marché

Le marché est lancé par une direction initiatrice, puis le Service Marché à la tache de le créer après avoir reçu une notification.

o Consulter marché

Consulter la liste des marchés effectués.

o Modifier marché

Modifier un marché, au cas où certaines informations sont changées. o Supprimer marché

La suppression est une action non fréquente mais requise, puisque

éventuellement il peut y avoir une suppression d'un marché.

o Enregistrer les différents documents liés à un marché

Pour chaque marché il existe plusieurs documents liés. Donc pour avoir

			Chapitre II : Spécification et analyse des besoins

l'historique ainsi que la trace d'un marché il faut garder une copie des documents qui y sont associés.

o Gérer les offres concernant un marché donné.

Effectuer les différentes opérations de gestion des offres (Ajout, modification,

suppression et consultation) des offres pour un marché donnée.

· Gestion des soumissionnaires :

o Créer soumissionnaires

Créer un nouveau soumissionnaire.

o Consulter soumissionnaires

Consulter la liste des soumissionnaires. o Modifier soumissionnaires

Modifier un ou plusieurs soumissionnaires. o Supprimer soumissionnaires

Supprimer un soumissionnaire.

· Gestion des commissions o Créer commission

Il existe deux types de commission une d'ouverture de plis et l'autre de dépouillement, chaque commission est composées des membres qui sont du personnel de l'ETAP.

o Consulter commission

Consulter la liste des différentes commissions o Modifier commission

On peut modifier le type d'une commission, ou bien l'affecter à un autre marché ou aussi lui ajouter ou supprimer un membre

o Supprimer commission Supprimer une commission

· Le suivi des marchés

o Chaque direction peut consulter la situation d'un marché en cours, ou bien la liste de tous les marchés lancés par cette dernière.

			Chapitre II : Spécification et analyse des besoins

2.2 Besoins non fonctionnels

Un besoin non fonctionnel est besoin spécifiant des propriétés du système, telles que les contraintes liées à l'environnement et l'implémentation, les exigences en matière de performances, de dépendances de plate-forme, de facilité de maintenance, d'extensibilité et de fiabilité. [Jacobson, Boosh, Rambaugh 1999]

Dans notre système on distingue les besoins non fonctionnels suivant :

· Sécurité

La plateforme doit assurer la sécurité pour les utilisateurs (Authentification).

· Convivialité

Ergonomie des interfaces homme machine et facilité d'utilisation.

· Contrôle

Saisie contrôlée selon les choix prédéfinis.

· Gagner du temps à l'intérieur de l'entreprise

3 Analyse des besoins

3.1 Modèle cas utilisation

La spécification des besoins représente l'ensemble des services que doit fournir le logiciel à son utilisateur. Selon le processus unifié chaque service est modélisé sous un cas d'utilisation, pour élaborer à la fin un diagramme UML de cas d'utilisation. Chaque cas d'utilisation est décrit sous une forme textuelle représentant un scenario nominal (ensemble des actions à réaliser pour atteindre l'objectif).

Dans cette partie, nous allons dégager tous les acteurs en les décrivant. Ensuite, nous allons exprimer dans des phrases les principales actions du système et des acteurs. Enfin, nous allons représenter et décrire les différents diagrammes des cas d'utilisation pour donner une vue externe sur notre système.

3.1.1 Identifications des acteurs

Un acteur est une personne, un matériel ou un logiciel qui interagit directement avec le système pour réaliser une tâche. Ainsi, un acteur peut consulter et/ou modifier directement

			Chapitre II : Spécification et analyse des besoins

l'état du système en émettant et/ou recevant des messages susceptibles contenir des données. Durant notre analyse nous avons identifiés les acteurs suivants :

· Utilisateur : le système lui donne la possibilité de s'authentifier. Il est à noter que cet utilisateur peut être le responsable d'une direction, l'opérateur de service marché, le responsable de bureau d'ordre central et le responsable du service administratif et juridique.

· L'opérateur de service marché : le système lui offre la possibilité de s'authentifier, gérer les marchés, gérer les soumissionnaires et gérer les commissions.

· Directeur d'une direction : il est le directeur de la direction qui capte le besoin pour lancer un marché, le système lui offre les fonctionnalités : s'authentifier, initier un nouveau marché, valider le cahier des charges et suivre l'état d'un marché en cours ou déjà clôturé.

· Le responsable du bureau d'ordre central : le système lui offre la possibilité d'enregistrer les plis en plus de l'authentification.

· Direction administratives et juridique : ses membres se chargent de la validation du cahier des charges, de la validation des contrats et de proposer des membres pour les commissions des marchés en cours. Ses directions sont :

o Direction financière

o Direction de gestion

o Direction juridique

3.1.2 Identification des cas d'utilisation

Un cas d'utilisation est une fonctionnalité de système qui produit un résultat observable pour un utilisateur potentiel du système. Le cas d'utilisation regroupe une famille de scénario ou chaque scénario est un traitement particulier du système.

Lors de notre analyse des besoins nous avons pu identifier les actions importantes que nous présenterons ci-dessous et nous les modélisons par la suite avec les diagrammes cas utilisation d'UML.

Chapitre II : Spécification et analyse des besoins

Les cas utilisations les plus importantes par acteurs sont :

Cas Utilisation 6'arihLQiifiLI		Acteur Tous les utilisateurs			Description textuelle L'utilisateur n'accède au système que si il a le droit à le faire, d'où le passage par la saisie de login et mot de passe.
Gérer Marché		L'opérateur Service Marché			L'opérateur service marché à la possibilité d'effectuer toutes opérations de gestion de marché (ajout, consultation, suppression et mise à jour) ainsi que la gestion (ajout, modification et suppression) des offres liées à un marché.
Gérer Commission		L'opérateur Service Marché			L'opérateur service marché à la possibilité d'effectuer toutes opérations de gestion de commission (ajout, consultation, suppression et mise à jour) ainsi que l'affection d'une commission à un marché.
Gérer soumissionnaire		L'opérateur Service Marché			L'opérateur service marché à la possibilité d'effectuer toutes opérations de gestion de commission (ajout, consultation, suppression et mise à jour).
Consulter situation marché		Direction initiatrice Opérateur Service Marché			Consulter les différentes phases d'un marché
Initialiser marché		Direction initiatrice			Initialiser un marché (demande de création d'un nouveau marché)
Valider cahier des charges		Direction Initiatrice Direction administrative et juridique			Après la création d'un nouveau marché, la rédaction de cahier des charges aura lieu, ce dernier doit être validé avant sa publication
Valider contrat		Direction administrative et juridique			Après le choix du titulaire du marché un contrat doit être signé, ce dernier est validé et paramétré par la direction administrative et juridique.
Chapitre II : Spécification et analyse des besoins
Proposer membre	Direction			Pour chaque nouvel marché et selon le marché
de la commission	administrative et			ainsi que le profil du personnel disponible, cette
	Iuridique			direction propose des membres pour assister aux différentes commissions
Ajouter plis	Responsable bureau			L'operateur bureau ordre central, ajoute les
	ordre central			différents plis (offres) pour les marchés en phase de réception de plis

Tableau 1: Identification des cas d'utilisation

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

3.2 Modèle Analyse

Le modèle d'analyse doit fournir une approche conceptuelle du problème. Le but de ce modèle est de définir une structure robuste et extensible qui nous servira de base pour la construction du système. Chaque type d'objet (entité, contrôle et interface) apporte sa propre contribution à ces deux qualités. Le modèle d'analyse doit fournir des spécifications fonctionnelles totales du système que l'on veut développer sans aucune référence à l'environnement de développement. La phase de développement sera conduite à partir de ce modèle.

Après une première ébauche des besoins des clients, il va falloir approfondir ses besoins, examiner les différents scénarios des cas d'utilisation, tenir compte des traitements exceptionnels et cas d'erreur. Il va être nécessaire de regarder le séquencement des

pl i

Chapitre II : Spécification et analyse des besoins

opérations d'un point de vue fonctionnel, pour voir comment les différents acteurs interagissent avec le logiciel(à l'aide des diagrammes de séquence). Il est alors nécessaire de distinguer les différents objets qui collaborent dans notre système (à l'aide des diagrammes de classe d'analyse). Enfin nous aurons alors tous les éléments pour passer à la conception.

Le modèle analyse se base sur trois types de classes d'analyse, les dialogues, les contrôles et les entités :

Les classes de dialogues

Les classes qui permettent les interactions entre l'IHM et les utilisateurs sont qualifiées de dialogues.

Les classes de contrôles

Les classes qui modélisent la cinématique de l'application sont appelées contrôles. Elles font la jonction entre les dialogues et les classes métier en permettant aux différentes vues de l'application de manipuler des informations détenues par un ou plusieurs objets métier. Elles contiennent les règles applicatives et les isolent à la fois des dialogues et des entités.

Les classes entités

Les classes entités sont généralement persistantes, c'est-à-dire qu'elles survivent à l'exécution d'un cas d'utilisation particulier et qu'elles permettent à des données et des relations d'être stockées dans des fichiers ou des bases de données. Lors de l'implémentation, ces classes peuvent ne pas se concrétiser par des classes mais par des relations, au sens des bases de données relationnelles.

3.2.1 Analyse des cas d'utilisation prioritaires

Après avoir détaillé les cas d'utilisation, nous procédons par une analyse pour chaque cas, nous commencerons par présenter la traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse, ensuite nous présentons le diagramme de classe du modèle d'analyse et enfin le diagramme de collaboration de ces cas.

a Analyse du CU « S'authentifier »

Le cas d'utilisation « S'authentifier » correspond dans le modèle d'analyse aux classes

Chapitre II : Spécification et analyse des besoins

d'analyse suivante :

· La classe de dialogue « : Interface_utilisateurs ", désignée par le stéréotype « boundary ", qui permet à l'utilisateur d'interagir avec le système.

· La classe entité « : users ", désignée par le stéréotype « entity ", qui sert à modéliser les informations de longue durée et souvent de nature persistante.

· La classe contrôle « : gestionnaire_authentification ", désignée par le stéréotype « control ", qui se charge de contrôler les données saisies par l' utilisateur.la classe contrôle joue le rôle de coordinateur entre la classe interface el la classe entité.

Modèle cas utilisation Modèle d'analyse

Figure 11:Traçabilité modèle cas utilisation et modèle analyse pour le CU« S'authentifier »

La traçabilité ente le modèle de cas d'utilisation et le modèle d'analyse met en relation deux livrables de deux jalons différents du cycle de vie du projet. C'est un moyen qui favorise le passage immédiat d'une phase à une autre du processus unifié.

Figure 12: Diagramme de classe d'analyse pour le CU « S'authentifier »

Le diagramme de classes d'analyse effectue la jonction entre, d'une part, les cas d'utilisation, et d'autre part, les diagrammes de conception logicielle que sont les diagrammes d'interaction (diagramme de séquence d'analyse dans notre cas).

			Chapitre II : Spécification et analyse des besoins

Figure 13:Diagramme de collaboration pour le CU « S'authentifier »

Pour accéder à l'application, tous les utilisateurs doivent valider leurs authentifications. L'utilisateur tape ses paramètres de connexion (login et mot de passe), ces paramètres vont être envoyée au gestionnaire, après avoir recherché ces derniers dans la base et vérifiés leurs validités. En cas de succès, la page d'accueil est renvoyée selon les droits d'accès. Un message d'erreur est renvoyé le cas échéant.

b Analyse du CU « Gérer Marché »

Le cas d'utilisation « Gérer marché » correspond dans le modèle d'analyse aux classes d'analyse suivante :

· La classe de dialogue « : IU_Service_marché ».

· Les classes entité « : marché », « : Dossiermarché », « : lot », « : phase », « : offre ».

· La classe contrôle « : gestionnairemarché »

Modèle cas utilisation Modèle d'analyse

Figure 14:Traçabilité modèle cas d'utilisation et modèle analyse pour le CU« Gestion marché»

			Chapitre II : Spécification et analyse des besoins

Figure 15:Diagramme de classe d'analyse pour le CU « Gérer marché »

Figure 16:Diagramme de collaboration du CU « Gérer marché »

Comme le montre la figure 5 « raffinement du cas d'utilisation gérer marché », la gestion de marché s'effectue en menant l'une des opérations (Ajout, Modification, Suppression ou bien une opération de gestion d'offre à savoir ajouter offre, modifier offre ou supprimer offre) ce qui engendre une mise à jour au niveau des entités.

L'opérateur service marché, après l'authentification, est redirigé vers la page de gestions des marchés. Le contrôleur de cette page charge la liste des marchés initiés par les différentes directions initiatrice de l'ETAP. Si ce dernier souhaite lancer un nouveau marché il doit choisir une demande initiée, pour les autres opérations de gestion ; l'utilisateur choisit un marché existant, effectue une opération les modifications sont enregistrées dans la base de données (selon la nature de l'opération l'entité est modifiée).

			Chapitre II : Spécification et analyse des besoins

c Analyse du CU « Gérer Commission >>

Le cas d'utilisation « Gérer commission " correspond dans le modèle d'analyse aux classes d'analyse suivante :

· La classe de dialogue « : IU_Service_marché ".

· Les classes entité « : marché ", « : commission ", « : membre_commission ", « : personnel ".

· La classe contrôle « : gestionnaire_commission ".

Modèle cas utilisation Mod~le d'analyse

			Figure 17:Traçabilité modèle cas d'utilisation et modèle analyse pour le CU« Gérer commission>>
Figure 18:Diagramme de classe d'analyse pour le CU « Gérer commission >>
		PFE 2011-2012 29

			Chapitre II : Spécification et analyse des besoins

Figure 19:diagramme de collaboration du CU « Gérer commission »

L'opérateur service marché demande la page de gestion des commissions, le gestionnaire charge la liste des commissions ainsi que les membres des commissions (personnel de l'ETAP) et les marchés associés à la commission. Puis l'utilisateur effectue une opération (Ajout de nouvelle commission, modification d'une commission, suppression d'une commission, affection d'une commission ou bien ajout, suppression ou modification des membres d'une commission.

d Analyse du CU « Gérer Soumissionnaire »

Le cas d'utilisation « Gérer Soumissionnaire » correspond dans le modèle d'analyse aux classes d'analyse suivante :

· La classe de dialogue « : IUServicemarché ».

· Les classes entité « : soumissionnaire »

· La classe contrôle « : gestionnairesoumissionnaire »

Figure 20:Traçabilité modèle de cas d'utilisation et modèle analyse pour le CU« Gérer soumissionnaire»

Figure 21:Diagramme de classe d'analyse pour le CU « Gérer soumissionnaire»

Figure 23:Traçabilité modèle cas utilisation et modèle analyse pour le CU« Consulter situation marché»

Figure 24:Diagramme de classe d'analyse pour le CU « Consulter situation marché»

Figure 26:Traçabilité modèle cas utilisation et modèle analyse pour le CU« Initialiser marché»
Figure 27:Diagramme de classe d'analyse pour le CU « Initialiser marché»

Figure 28:Diagramme de collaboration pour le CU « Initialiser marché »

	Chapitre II : Spécification et analyse des besoins

Modèle cas utilisation Mod~le d'analyse

Figure 22:Diagramme de collaboration pour le CU « Gérer soumissionnaire »

L'opérateur service marché effectue une opération sur un soumissionnaire (Ajout, modification, suppression), cette modification est envoyée au gestionnaire par le biais de l'interface, et ces modifications sont enregistrées dans la base de données (dans l'entité soumissionnaire).

e Analyse du CU « Consulter Situation Marché »

Le cas d'utilisation « Consulter situation marché " correspond dans le modèle d'analyse aux classes d'analyse suivante :

· La classe de dialogue « : IUdirectioninitiatrice ".

· Les classes entité « : marché ", « : Dossiermarché ", « : phase ".

· La classe contrôle « : gestionnaire_marché ".

·			Chapitre II : Spécification et analyse des besoins

Modèle cas utilisation Modèle ('IXIlyse

Figure 25:Diagramme de collaboration pour le CU « Consulter situation marché »

Le responsable de la direction initiatrice, après l'authentification, est redirigé vers la page de suivi des marchés. Le contrôleur de cette page charges la liste des marchés en cours lancés par cette direction.

			Chapitre II : Spécification et analyse des besoins

f Analyse du CU « Initialiser Marché »

Le cas d'utilisation « Initialiser marché » correspond dans le modèle d'analyse aux classes d'analyse suivante :

· La classe de dialogue « : Interface_direction_initiatrice ».

· Les classes entité « : marché », « : dossier_marché ».

· La classe contrôle « : gestionnaire_marché ».

Modèle cas utilisation 0 1CleIC'IXaly\e

			Chapitre II : Spécification et analyse des besoins

Le responsable de la direction initiatrice, une fois l'interface du lancement de nouveau marché affiché, ce dernier entre les informations nécessaires. Le gestionnaire récupère ces informations et les enregistre dans les entités de la base correspondante.

g Analyse du CU « Ajouter Plis »

Le cas d'utilisation « Gérer commission » correspond dans le modèle d'analyse aux classes d'analyse suivante :

· La classe de dialogue « : IU_bureau_ordre_central ».

· Les classes entité « : offre », « : phase ».

· La classe contrôle « : gestionnaire_offre ».

Modèle cas utilisation 0 1CleIC'IXaly\e

			Figure 29:Traçabilité modèle cas utilisation et modèle analyse pour le CU« Ajouter plis»
Figure 30:Diagramme de classe d'analyse pour le CU « Ajouter plis»
		PFE 2011-2012 34

			Chapitre II : Spécification et analyse des besoins

Figure 31:Diagramme de collaboration pour le CU « Ajouter plis »

Le responsable du Bureau d'Ordre Central, est redirigé vers la page d'ajout des plis après l'authentification, le gestionnaire de cette page, charge la liste des marchés en phase de réception des plis. Après la saisie des plis reçus ces informations sont enregistrées dans la base de données (entité plis).

4 Conclusion

Au cours de ce chapitre, nous avons analysé les besoins fonctionnels de notre système, nous avons cerné les différentes relations et interactions menant à bien comprendre le système et ses limites, en mettant en relief ses contraintes et ses exigences.

Dans le chapitre qui suit, conception, on entame la phase élaboration du processus

unifié.

CHAPITRE 3

Conception

Sommaire

· Introduction

· Modèle de conception

· Modèle de déploiement

· Conclusion

			Chapitre III : Conception

1 Introduction

Ce chapitre présente la deuxième phase du Processus Unifié, élaboration. Au cours de cette phase, la plupart des cas d'utilisation seront spécifiés de manière détaillée. Nous réaliserons la conception, qui consiste à organiser le système et à lui donner une forme et une architecture.

La première partie de ce chapitre sera consacrée à la conception des cas d'utilisations, en déterminant les différentes classes de conception impliquées et leurs interactions. Dans la deuxième partie, la configuration physique du système sera représentée à travers le diagramme de déploiement.

2 Modèle de conception

Le modèle de conception est axé sur la conception des cas l'utilisation, en se basant sur l'étude de traçabilité entre le modèle d'analyse et le modèle de conception. La phase d'analyse fournit une bonne compréhension des requis, des concepts et du comportement d'un système. Le modèle de conception est d'abord créé à partir du modèle d'analyse, avant d'être adapté à l'environnement l'implémentation choisi.

La première réalisation du modèle de conception se fait automatiquement à partir du modèle d'analyse. On a une bijection entre les objets de l'analyse et les blocs du modèle de conception. La conservation de cette bijection est un des points forts de la méthode car elle permet d'associer du code avec des raisons analytiques et permet en cas de changement du modèle d'analyse de retrouver rapidement le code associé (traçabilité). Cette propriété de traçabilité va nous permettre de pouvoir naviguer aisément dans le modèle d'implémentation grâce au modèle d'analyse. De plus cela aide à une plus grande localisation de fonctionnalité, ce qui réduit les coûts de transformation.

Le passage à l'étape de conception consiste à construire les diagrammes qui permettront de décrire les communications entre les objets et leurs responsabilités respectives afin de remplir les requis.

2.1 Conception des cas d'utilisation prioritaires

Dans ce qui suit, nous allons concevoir les cas d'utilisations prioritaires déjà analysés, nous commençons par une traçabilité entre le modèle d'analyse et le modèle de conception, ensuite un diagramme de classe du modèle de conception et enfin le diagramme de

			Chapitre III : Conception

séquence pour chaque cas.

a 811QFIEWQ EXIIIM⁴KIKPONQI« 6⁴1MNIQAIIier »

Figure 327 librIENIKEQtiiili P FlaPHd⁴DQUSIMIEVOIP FEaleICIDFQHWAPQ IVEDV« 6⁴11AIeQtAIIH »

La propriété de traçabilité nous permet la réalisation automatique du modèle de conception á partir du modèle d'analyse.

Figure 33:Diagramme de classe du modèle de conception pour le CU « S'authentifier »

Le diagramme de classe de conception est basé sur le diagramme de classe d'analyse, il nous sert pour donner un diagramme de classe préliminaire avec les catégories de classe, les attributs et les méthodes.

La figure 34 ci-dessous illustre le scénario du cas d'utilisation « s'authentifier ». Lorsqu'un des utilisateurs, lance l'application il se retrouve à l'interface d'authentification. Il tape sont login et mot de passe, selon les paramètres entrés il est redirigé vers la section qui lui convient. Dans le cas échéant un message d'erreur est affiché.

			Chapitre III : Conception

Figure 34:Diagramme de séquence pour le CU « S'authentifier »

Le service marché

Dans le chapitre précèdent nous avons vu que l'opérateur du service marché peut accomplir plusieurs fonctionnalités. Dans la figure 35 ci-dessous, nous allons montrer ces activités dans un seul diagramme d'activité.

Le détail de ces activités sera fait dans les parties « b Gestion des marchés » jusqu'à « d Gestion des commissions ».

Chapitre III : Conception

Figure 35: Diagramme d'activités pour l'opérateur service marché

	Chapitre III : Conception

b Conception du cas d'utilisation « Gérer marché »

Figure 36:Traçabilité entre le mod4le d'analyse et le modIle de conception du cas « Gérer marché~

Figure 37:Diagramme de classe du modèle de conception pour le CU « Gérer marché »

La figure 38 ci-dessous illustre le scénario du cas d'utilisation « Gérer marché ». Après l'authentification, l'opérateur du Service marché est appelé à assurer la gestion des marchés

			Chapitre III : Conception

de l'ETAP à travers l'une des actions suivantes :

· Ajouter un nouveau marché

Ceci n'est possible que si une direction initiatrice a demandé de lancer un nouveau marché

· Modifier un marché

Modifier un marché en changeant la phase atteinte, ou changer un des documents constituant le dossier ce marché ou d'autre information

· Supprimer marché

Cette action n'est pas fréquente, mais elle sert à changer la phase d'un marché à l'état bloqué.

· Ajouter, modifier ou supprimer les offres reçues pour un marché donné

			Chapitre III : Conception

Figure 38:Diagramme de séquence pour le CU « Gérer marché »

c Conception du cas d'utilisation « Gérer commission»

Figure 39:Traçabilité entre le mod~le d'analyse et le mod~le de conception du cas « Gérer commission~

			Chapitre III : Conception

Figure 40:Diagramme de classe du modèle de conception pour le CU « Gérer commission »

La figure 41 ci-dessous, décrit le scénario du cas d'utilisation « Gérer commission ». L'opérateur service marché peut créer, modifier, supprimer, affecter une commission ainsi que ajouter, modifier, supprimer des membres d'une commission.

Figure 41:Diagramme de séquence pour le CU « Gérer commission »

			Chapitre III : Conception

d Conception du cas d'utilisation « Gérer soumissionnaire »

Figure 42:Traçabilité entre le modIle d'analyse et le modIle de conception du cas « Gérer soumissionnaire~
Figure 43:Diagramme de classe du modèle de conception pour le CU « Gérer soumissionnaire »

Le scénario présent dans la figure 44, traduit ce qui a été détaillé dans les diagrammes précédents pour le cas d'utilisation « Gérer soumissionnaire » où l'opérateur Service marché, saisit, modifie ou supprime un soumissionnaire, enfin il valide ses choix.

			Chapitre III : Conception

Figure 44:Diagramme de séquence pour le CU « Gérer soumissionnaire »

La direction initiatrice :

Figure 45:Diagramme d'activité pour la direction initiatrice

			Chapitre III : Conception

La direction initiatrice plusieurs tâches à effectuer. Le diagramme d'activités sert à montrer toutes ces fonctionnalités ensemble. Ces activités vont être détaillé dans la suite de la partie « e Consulter situation marché » et « f Initialiser marché ».

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

Figure 46:Traçabilité entre le mod4le d'analyse et le modIle de conception du cas « Consulter situation marché ~
Figure 47:Diagramme de classe du modèle de conception pour le CU « Consulter situation marché »

La figure 48 ci-dessous montre les étapes de la consultation de la situation d'un marché pour une direction initiatrice, l'utilisateur affiche l'interface de la consultation et sélectionne le marché en question et tous ces paramètres seront alors affichés pour lecture seule.

Figure 49 : Traçabilité entre le modqle d'analyse et le mod~le de conception du cas « Initialiser marché ~

	Chapitre III : Conception

Figure 48:Diagramme de séquence pour le CU « Consulter situation marché »

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

			Chapitre III : Conception

Figure 50:Diagramme de classe du modèle de conception pour le CU « Initialiser marché »

La figure 51 illustre les premières étapes par lesquelles passe le lancement d'un nouveau marché, où le responsable de direction initiatrice saisit les paramètres de ce dernier dans l'interface de lancement de marché et clique sur le bouton valider et notifier SM.

Figure 51:Diagramme de séquence pour le CU « Initialiser marché »

Chapitre III : Conception

g Conception du cas d'utilisation « Ajouter plis »

Figure 52:Traçabilité entre le modIle d'analyse et le modIle de conception du cas « Ajouter plis »

Figure 53:Diagramme de classe du modèle de conception pour le CU « Ajouter plis »

La figure 54 ci-dessous montre les étapes de l'ajout d'un nouveau pli où le responsable de Bureau d'Ordre Central affiche l'interface de l'ajout, sélectionne un marché en phase de réceptions des plis, saisit les paramètres et confirme son choix en cliquant sur le bouton « ajouter ».

			Chapitre III : Conception

Figure 54:Diagramme de séquence pour le CU « Ajouter plis »

2.2 Diagramme de classe

Le diagramme de classe constitue un élément très important de la modélisation, il permet de définir quelles seront les composantes du système final. Il ne permet pas en revanche de définir le nombre et l'état des instances individuelles.

Néanmoins, on constate souvent qu'un diagramme de classe proprement réalisé permet de structurer le travail de développement de manière très efficace. Ci-dessus le diagramme de classe général.

Dans le diagramme de classe ci-dessous, les attributs qui commence par << path >> et dont le type est << varchar2 >> représente le path des documents du marché. Ces document sont enregistrés, et peuvent être consultés à tout moment.

Chapitre III : Conception
	Figure 55:Diagramme de classe
PFE 2011-2012	52

			Chapitre III : Conception

3 Modèle de déploiement

Figure 56:Diagramme de déploiement

Le diagramme de déploiement montre la disposition physique des matériels qui composent le système et la répartition des composants sur ces matériels. Ce diagramme représente une architecture deux-tiers sur laquelle notre futur système va être déployé.

L'application réalisée à l'ETAP est une application lourde, déployé sur deux tiers, mais grace à l'outil oracle application server 10g, cette dernière peut être migrée vers une application web.

4 Conclusion

Dans ce chapitre, nous avons conçu les cas d'utilisation prioritaires. Durant ce chapitre nous avons effectué la traçabilité entre le modèle d'analyse et le modèle de conception, ensuite les diagrammes de classe participantes, puis les diagrammes de séquence et nous avons établi le diagramme de classe, enfin nous avons montré l'architecture physique à travers le diagramme de déploiement .Grâce à l'activité de conception nous avons accompli la phase d'élaboration du processus unifié. Ainsi, nous pouvons entamer la dernière phase restante du processus unifié, phase de construction.

CHAPITRE 4				Implémentation et réalisation

Sommaire

· Introduction

· Modèle implémentation

· Réalisation

· Conclusion

1 Introduction

L'objectif de la phase d'implémentation est d'aboutir à un produit final, exploitable par les utilisateurs. En premier lieu, nous présenterons le modèle d'implémentation, qui illustre l'architecture physique pour la construction de notre application, quant à la deuxième partie « réalisation », nous spécifierons les outils, langages et techniques utilisés et nous finirons par présenter les scénarios les plus généraux de notre application illustrés par des captures d'écrans.

2 Modèle implémentation

Nous commencerons par présenter la traçabilité entre le modèle de conception et le modèle d'implémentation, ensuite nous présentons une vue globale sur notre application à partir du diagramme de composants du système.

Figure 57:Traçabilité entre le modèle conception et le modèle implémentation

Les dépendances entre composants permettent d'identifier les contraintes de compilation et de mettre en évidence la réutilisation de composants.

Les composants peuvent être organisés en paquetages, qui définissent des soussystèmes. Les sous-systèmes organisent la vue des composants (de réalisation) d'un système. Ils permettent de gérer la complexité, par encapsulation des détails d'implémentation.

La figure suivante montre le diagramme de composants du système :

Figure 58:diagramme de composant système

3 Réalisation

Dans cette session nous commencerons par présenter les outils et langages de notre application et enfin nous terminerons par la description des scénarios les plus généraux illustrés par des captures d'écrans de notre application.

3.1 Outils et langages utilisés

Tout au long de ce projet, nous avons utilisé les produits de la maison Oracle car l'Entreprise Tunisienne d'Activités Pétrolière possède la licence oracle pour utiliser les différents produits offerts par ce dernier. Le langage de programmation est PL/SQL.

· Oracle

L'histoire d'Oracle débute avec la création d'Oracle corporation en 1977. Sa première version était commercialisée en 1979. L'année 1986 a été marquée par l'introduction de l'architecture client / serveur qui tend à devenir aujourd'hui sa spécialité.

Les fonctionnalités Oracle :

Oracle est un SGBD (Système de Gestion de Base de Données) permettant d'assurer :

· La définition et la manipulation des données

· La cohérence des données

· La confidentialité des données

· L'intégrité des données

· La sauvegarde et la restauration des données

· La gestion des accès concurrents

Les Composant Oracle :

Outre la base de données, la solution Oracle est un véritable environnement de travail constitué de nombreux logiciels permettant notamment une administration graphique d'Oracle, l'interface avec des produits divers et des assistants de création de bases de données et la configuration de celles-ci.

On peut classer les outils d'Oracle selon diverses catégories :

· Les outils d'administrations

· Les outils de développement

· Les outils de communication

· Les outils de génie logiciel

· Les outils d'aide à la décision Les outils de développements utilisés sont :

Oracle Forms : Un générateur d'applications transactionnelles basé sur le langage PL/SQL, il permet la conception, la création et l'exécution de ces applications sur divers plateformes. Il donne la possibilité de présenter les données de la base de façon graphique. Il autorise ainsi le développement rapide de plusieurs applications consistantes (fenêtres,

formulaires,.....). Il permet de créer des systèmes à haute performance.

Oracle Reports : Un outil pour l'élaboration des états sur des données stockées dans une base de données Oracle. Il donne la possibilité de générer des rapports élaborés avec l'utilisation de SQL pour transformer des données en informations utiles pour l'analyse et la prise de décision.

? Langage utilisé PL/SQL

Le langage PL/SQL est un langage L4G (entendez par ce terme un langage de quatrième génération), fournissant une interface procédurale au SGBD Oracle. Le langage PL/SQL intègre parfaitement le langage SQL en lui apportant une dimension procédurale.

Ainsi le langage PL/SQL permet de manipuler de façon complexe les données contenues dans une base Oracle en transmettant un bloc de programmation au SGBD au lieu d'envoyer une requête SQL. De cette façon les traitements sont directement réalisés par le système de gestion de bases de données. Cela a pour effet notamment de réduire le nombre d'échanges à travers le réseau et donc d'optimiser les performances des applications.

D'autre part le langage PL/SQL permet de faire appel à des procédures externes, c'està-dire des procédures écrites dans un autre langage (de troisième génération, généralement le langage C).

Principe du PL/SQL

Le langage PL/SQL permet de définir un ensemble de commandes contenues dans ce que l'on appelle un "bloc" PL/SQL. Un bloc PL/SQL peut lui-même contenir des sous-blocs. La syntaxe PL/SQL est simple et lisible.

Gestion des exceptions

PL/SQL offre un moyen d'identifier et de traiter les éventuelles erreurs à l'aide du mécanisme des exceptions.

En cas d'erreur, celle-ci est automatiquement transmise à un bloc EXCEPTION permettant de la traiter. PL/SQL définit en standard un grand nombre d'exceptions. De plus il est possible de définir nos propres exceptions, ce qui offre de nombreuses possibilités.

3.2 Applications réalisées

Figure 59: Page authentification

C'est l'interface commune pour tous les utilisateurs (Service marché, Direction initiatrice, Bureau Ordre Central et Direction administrative et juridique). Pour accéder à l'application, l'acteur s'authentifie : il introduit ses cordonnées (login et mot de passe) ; en cas de succès il est dirigé vers la section qui lui convient selon les droit d'accès ; dans le cas échéant un message d'erreur est affiché.

Figure 60:Accueil direction initiatrice

La page d'accueil de la direction initiatrice. Une liste des marché lance par la direction est affiché. Après la sélection d'un marché les détails de ce dernier sont affichés.

Figure 61:Accueil Service marché

Pour la page d'accueil du service marché, il trouve la liste des marchés initialisés par les différentes directions initiatrices de l'ETAP, il sélectionne un marché et lance un nouveau à partir du bouton nouveau marché.

Figure 62:Gestion des marchés (Service marché)

Interface de gestion des marchés, ou le service marché est appelé à sélectionner un marché ensuite faire l'une des opérations suivantes :

Modifier marché : Modifier les données concernant le marché sélectionné ; Supprimer marché : Supprimer le marché sélectionné ;

Aussi, l'opérateur de service marché peut assurer cette gestion de marché à travers les fonctionnalités dans les onglets, en bas de la liste des marchés, qui assure :

Consulter/Modifier les documents d'un marché donnée ;

Suivre les phases d'un marché, ajouter ou bien modifier une phase ;

Consulter les détails des offres reçus pour un marché donné, Ainsi que l'ajout, modification et suppression des offres ;

Aussi la gestion des différents lots qui compose le marché.

Figure 63:Gestion des commissions (Service marché)

Interface de gestion de commission, ou le service marché est appelé a sélectionné une commission puis faire l'une des opérations suivantes :

Modifier commission (date commission, type commission) ; Ajouter/supprimer membre de commission ;

Affecter commission : Affecter la commission a un marché.

Figure 64:Gestion des soumissionnaires (Service marché)

Interface de gestion des soumissionnaires, ou le service marché est appelé à faire l'une des opérations suivantes :

Ajouter/Modifier/Supprimer un soumissionnaire ;

Afficher les différentes offres soumis par un soumissionnaire donnée.

Figure 65:Interface de la direction Financière

L'agent de la direction financière trouve une liste des tâches à réaliser dès qu'il est authentifié.

Pour la validation du cahier des charges /contrat il sélectionne le marché approprié et valide ou envoi une observation si non validé.

L'agent de cette direction peut proposer des membres pour les commissions ainsi que le lancement d'un nouveau marché.

3 Conclusion

Dans cette partie nous avons présenté l'environnement matériel et logiciel de notre projet. Ensuite nous avons illustré les différentes fonctionnalités de notre application à travers quelques interfaces afin de donner une meilleure idée du travail réalisé. Enfin nous avons proposé les améliorations possibles de l'application comme perspectives.

Conclusion générale

Le travail réalisé dans le cadre de notre projet de fin des études a consisté à faire la conception et la réalisation d'une application de gestion de marchés par appels d'offres au sein de l'Entreprise Tunisienne d'Activités Pétrolières.

Ce travail est décomposé en trois étapes. La première a été consacrée à comprendre le contexte général du projet. L'étape suivante a été dévolue à la spécification des besoins fonctionnels et non fonctionnels ce qui a permis de classer les fonctionnalités du système en plusieurs itérations selon la priorité. Dans la dernière étape nous nous sommes penchés sur la conception et l'implémentation de ces itérations. En effet, pour chaque itération, nous avons défini les modèles statiques et dynamiques sur lesquels nous nous sommes basés dans la phase d'implémentation.

Pour ce faire, nous avons choisi le Processus Unifié comme méthodologie à suivre au niveau du développement et le langage UML comme langage de modélisation. Lors de la réalisation, nous avons utilisé un ensemble d'outils Oracle, à savoir, Oracle Forms et Reports, le SGBD oracle pour la base de données et PL/SQL comme langage de développement.

Durant ces quatre mois de stage, j'ai pu mettre en pratique une partie des connaissances acquises lors de ma formation académique. Ce projet a constitué une occasion pour m'intégrer dans le milieu professionnel. En effet, j'ai eu l'occasion de me confronter au travail d'équipe et de découvrir ses richesses. J'ai également découvert les contraintes à respecter pour bien gérer les relations humaines. L'expérience acquise durant ce travail est précieuse pour ma future vie professionnelle.

L'outil développé à la faveur de l'Entreprise Tunisienne d' Activités Pétrolières, porte en lui les germes d'un outil complet qui pourra être amélioré avec l'ajout d'autres fonctionnalités dont un module de gestion électronique de documents.

Bibliographie

Cours :

Génie Logiciel Avancée cours 3^ème ING Héla Hachicha, 2011-2012 Méthodologies de conception ^2ème ING Adel khalfallah, 2010-2011

Articles :

- Rapport annuel de l'ETAP « Bibliothèque interne de l'ETAP », (2010-2011)

- Procédures de Passation des Marchés Publics « Bibliothèque interne de l'ETAP », (2010-2011)

Webographie :

- Rational Unified Process, Best Practices for Software : Rational Software White Paper TP026B, Rev 11/01 page consultée le 25 avril 2012.

Disponible sur http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_ bestpractices TP026B.pdf

- Object Management Group, Object Management Group - uml. Page consulté le 24 mars 2012.

Disponible sur http://www.uml.org/

- Observatoire National des marchés publics. Page consulté le 01 mars 2012. Disponible sur http://www.marchespublics.gov.tn

Sommaire

Introduction générale 1

Chapitre I : Présentation Générale 3

1 Introduction 4

2 Présentation de l'entreprise d'accueil . 4

2.1 Fiche identité 4

2.2 Mission de l'ETAP 4

2.3 Organigramme de l'ETAP 5

3 Etude de l'existant .. 6

3.1 Contexte du système 6

3.1.1 Appel d'offres 6

3.1.2 Réception des plis 6

3.1.3 Ouverture des plis 6

3.1.4 Dépouillement technique et financier 6

3.1.5 Approbation, exécution et suivi des marchés 7

3.1.6 Contractualisation 7

3.2 Problématique 7

4 Méthodologie adopté 7

4.1 Processus adopté 8

5 Conclusion 10

Chapitre II : Spécifications et analyse des besoins 11

1 Introduction 12

2 Spécifications des besoins 12

2.1 Besoins fonctionnels 12

2.2 Besoins non fonctionnels 14

3 Analyse des besoins 14

3.1 Modèle cas utilisation 14

3.1.1 Identifications des acteurs 14

3.1.2 Identification des cas d'utilisation 15

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

3.1.4 Affectation des priorités 18

3.1.5 Raffinement des cas utilisation prioritaire 19

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

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

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

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

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

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

g Raffinement du cas d'utilisation « A]outer plis» 24

3.2 Modèle Analyse 24

3.2.1 Analyse des cas d'utilisation prioritaires 25

a Analyse du CU « S'authentifier » 25

b Analyse du CU « Gérer Marché » 27

c Analyse du CU « Gérer Commission » 29

d Analyse du CU « Gérer Soumissionnaire » 30

e Analyse du CU « Consulter Situation Marché » 31

f Analyse du CU « Initialiser Marché » 33

g Analyse du CU « A]outer Plis » 34

4 Conclusion 35

Chapitre III : Conception 36

1 Introduction 37

2 Modèle de conception 37

2.1 Conception des cas d'utilisation prioritaires 37

a Conception du cas d'utilisation « S'authentifier » 38

b Conception du cas d'utilisation « Gérer marché » 41

c Conception du cas d'utilisation « Gérer commission» 43

d Conception du cas d'utilisation « Gérer soumissionnaire » 45

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

f Conception du cas d'utilisation « Initialiser marché » 48

g Conception du cas d'utilisation « Ajouter plis » 50

2.2 Diagramme de classe 51

3 Modèle de déploiement 53

4 Conclusion 53

Chapitre IV : Implémentation et réalisation 54

1 Introduction 55

2 Modèle implémentation 55

3 Réalisation 56

3.1 Outils et langages utilisés 56

3.2 Applications réalisées 59

3 Conclusion 63

Conclusion générale 64

Bibliographie 65

Liste des figures

Figure 1: Organigramme de l'ETAP 5

Figure 2: Les vues en RUP 8

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

Figure 4: Raffinement CU S'authentifier 19

Figure 5: Raffinement CU < Gérer marché » 20

Figure 6:Raffinement CU < Gérer commission » 21

Figure 7:Raffinement CU < Gérer Soumissionnaire » 22

Figure 8: Raffinement CU < Consulter situation marché » 23

Figure 9: Raffinement CU < Initialiser marché » 23

Figure 10: Raffinement CU < Ajouter plis » 24

Figure 11:Traçabilité modèle cas utilisation et modèle analyse pour le CU< S'authentifier » 26

Figure 12: Diagramme de classe d'analyse pour le CU < S'authentifier » 26

Figure 13:Diagramme de collaboration pour le CU < S'authentifier » 27

Figure 14:Traçabilité modèle cas d'utilisation et modèle analyse pour le CU« Gestion marché» 27

Figure 15:Diagramme de classe d'analyse pour le CU < Gérer marché » 28

Figure 16:Diagramme de collaboration du CU < Gérer marché » 28

Figure 17:Traçabilité modèle cas d'utilisation et modèle analyse pour le CU< Gérer commission» 29

Figure 18:Diagramme de classe d'analyse pour le CU < Gérer commission » 29

Figure 19:diagramme de collaboration du CU < Gérer commission » 30

Figure 20:Traçabilité modèle de cas d'utilisation et modèle analyse pour le CU« Gérer

soumissionnaire» 31

Figure 21:Diagramme de classe d'analyse pour le CU < Gérer soumissionnaire» 31

Figure 22:Diagramme de collaboration pour le CU < Gérer soumissionnaire » 31

Figure 23:Traçabilité modèle cas utilisation et modèle analyse pour le CU< Consulter situation

marché» 32

Figure 24:Diagramme de classe d'analyse pour le CU < Consulter situation marché» 32

Figure 25:Diagramme de collaboration pour le CU < Consulter situation marché » 32

Figure 26:Traçabilité modèle cas utilisation et modèle analyse pour le CU< Initialiser marché» 33

Figure 27:Diagramme de classe d'analyse pour le CU < Initialiser marché» 33

Figure 28:Diagramme de collaboration pour le CU < Initialiser marché » 33

Figure 29:Traçabilité modèle cas utilisation et modèle analyse pour le CU< Ajouter plis» 34

Figure 30:Diagramme de classe d'analyse pour le CU < Ajouter plis» 34

Figure 31:Diagramme de collaboration pour le CU « Ajouter plis » 35

Figure 32:Traçabilité entre le modèle d'analyse et le modèle de conception du cas « S'authentifier »38

Figure 33:Diagramme de classe du modèle de conception pour le CU « S'authentifier » 38

Figure 34:Diagramme de séquence pour le CU « S'authentifier » 39

Figure 35: Diagramme d'activités pour l'opérateur service marché 40

Figure 36:Traçabilité entre le modèle d'analyse et le modèle de conception du cas « Gérer marché» 41

Figure 37:Diagramme de classe du modèle de conception pour le CU « Gérer marché » 41

Figure 38:Diagramme de séquence pour le CU « Gérer marché » 43

Figure 39:Traçabilité entre le modèle d'analyse et le modèle de conception du cas « Gérer
commission» 43

Figure 40:Diagramme de classe du modèle de conception pour le CU « Gérer commission » 44

Figure 41:Diagramme de séquence pour le CU « Gérer commission » 44

Figure 42:Traçabilité entre le modèle d'analyse et le modèle de conception du cas « Gérer
soumissionnaire» 45

Figure 43:Diagramme de classe du modèle de conception pour le CU « Gérer soumissionnaire » 45

Figure 44:Diagramme de séquence pour le CU « Gérer soumissionnaire » 46

Figure 45:Diagramme d'activité pour la direction initiatrice 46

Figure 46:Traçabilité entre le modèle d'analyse et le modèle de conception du cas « Consulter
situation marché » 47

Figure 47:Diagramme de classe du modèle de conception pour le CU « Consulter situation marché »47
Figure 48:Diagramme de séquence pour le CU « Consulter situation marché » 48

Figure 49 : Traçabilité entre le modèle d'analyse et le modèle de conception du cas « Initialiser
marché » 48

Figure 50:Diagramme de classe du modèle de conception pour le CU « Initialiser marché » 49

Figure 51:Diagramme de séquence pour le CU « Initialiser marché » 49

Figure 52:Traçabilité entre le modèle d'analyse et le modèle de conception du cas « Ajouter plis » 50

Figure 53:Diagramme de classe du modèle de conception pour le CU « Ajouter plis » 50

Figure 54:Diagramme de séquence pour le CU « Ajouter plis » 51

Figure 55:Diagramme de classe 52

Figure 56:Diagramme de déploiement 53

Figure 57:Traçabilité entre le modèle conception et le modèle implémentation 55

Figure 58:diagramme de composant système 56

Figure 59: Page authentification 59

Figure 60:Accueil direction initiatrice 60

Figure 61:Accueil Service marché 60

Figure 62:Gestion des marchés (Service marché) 61

Figure 63:Gestion des commissions (Service marché) 62

Figure 64:Gestion des soumissionnaires (Service marché) 62

Figure 65:Interface de la direction Financière 63

Liste des tableaux

Tableau 1: Identification des cas d'utilisation 17

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

Tableau 3:Description textuelle du CU S'authentifier 19

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

Tableau 5:Description textuelle du CU Gérer commission 21

Tableau 6:Description textuelle du CU Gérer soumissionnaire 22

Tableau 7:Description textuelle du CU Consulter situation marché 23

Tableau 8:Decription textuelle du CU Initialiser marché 23

Tableau 9:Description textuelle du CU Ajouter plis 24

Remerciement

Aucun travail ne s'accomplit dans la solitude. Au terme de ce travail, je tiens à remercier et à présenter mes reconnaissances à tous ceux qui ont contribué de près ou de loin, à sa réalisation et son aboutissement.

Me manque les mots pour exprimer ma reconnaissance à Madame Olfa EL ARBI, qui a accepté de m'encadrer et qui m'a fait profiter de ses larges connaissances et de ses précieux conseils au cours de mon projet de fin d'étude.

J'adresse mes remerciements tout particulièrement aux dirigeants de l'ETAP et surtout Mr Kamel BEN NACEUR pour son encadrement sa disponibilité, ses conseils et son temps précieux.

Enfin j'exprime mes remerciements les plus dévoués aux membres de jury qui m'ont honoré en acceptant d'évaluer ce travail.

Helmi