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).
| 
