Gestion des courriers assistée par ordinateur avec Visual Studio.Net sous Windows (cas de la GCM)

Diane NGOIE, TFE, Licence professionnelle en informatique de gestion, ISS

Gestion des courriers assistée par ordinateur avec Visual Studio.Net sous Windows (cas de la GCM) 1

INTRODUCTION GENERALE

Depuis les temps anciens, les humains échanges des messages

soit au travers de la parole, des gestes. En rapport avec la distance, ils ont inventé

un autre mode de communication. De la parole, des gestes ils sont passés au tam-

tam, à l'envoi des courriers, à la téléphonie,….jusqu'à l'échanges des messages par

téléphones, internet et autres nouvelles technologies.

L'entreprise étant aussi une personne morale, se doit d'échanger

des messages avec des entités externes ou internes. Pour y parvenir elle utilise le

courrier. Ces courriers qui proviennent de différents endroits doivent être organisés

(transmission, classement,…) afin de pouvoir en tirer les informations nécessaires

dont l'entreprise a besoin. Un département est chargé d'assurer la gestion de ces

courriers.

C’est dans cette optique que nous nous sommes penchés sur la

gestion des courriers du département des services administratifs de la Gécamines.

1. PROBLEMATIQUE

La Gécamines est l’une de grandes entreprises qui compte en son

sein un grand nombre d’agents répartis dans différents sièges. Ces différents

sièges, pour le bon fonctionnement de l'entreprise, envoient ou reçoivent des

courriers qui proviennent de l'extérieure (SNEL, REGIDESO,..) ou de l'entreprise.

Le département des services administratifs, face à cette masse d'informations qui

lui parvient, n'arrive pas toujours à mieux gérés ses courriers soit par oublie de

transmission des courriers, de traitement des courriers, de suivi des courriers, de

classement, …. Or la politique de toute entreprise est une meilleure production (de

service, de produit, etc.) en un temps réduit et une accessibilité rapide aux

résultats.

Alors comment arriver à se rappeler des courriers qui ont été mis

en suspend ?



Comment savoir que tel courrier doit recevoir sa réponse dans

peu de temps ? Comment rappeler aux destinataires qu'il y a une attente de

réponse dans le système ?

Comment rechercher facilement un courrier dans une pile des

courriers classés ou transmis ?

Comment arriver à éliminer les tâches inutiles, gagner en temps

de travail en ayant un accès rapide aux informations relatives au courrier ?

2. HYPOTHESE

Nous pensons que pour résoudre ces problèmes il faudra analyser

ce système d’information afin d’arriver à voir de quelle manière l’insertion d’un

outil informatique est capable de répondre à tous ces besoins.

L’étude de la gestion des courriers doit nous permette d’arriver à

mettre sur pied une application de gestion des courriers. Cette application

facilitera le classement, la transmission, le suivi des courriers qui attendent de

réponse, qui sont en suspend, …

3. CHOIX ET INTERET DU SUJET

Notre choix a porté sur ce sujet parce que c'est un sujet qui sort

du cadre d'étude habituel. L’intérêt de ce sujet est que le résultat (application)

aidera le département à mieux gérer ses courriers.

4. METHODES ET TECHNIQUES

Comme tout travail scientifique exige une méthode de travail,

nous utiliserons de méthodes descriptives et analytiques basées sur le langage de

modélisation UML 2.0 dans la démarche 2TUP. La récolte des données s'est faite

grâce aux techniques suivantes :

- L’observation participative, qui nous a permis de porter un regard sur les

réalités et d’avoir en vue les moindres détails.

- L’interview libre, qui a permis une récolte de données précises.



- La documentation, qui a porté sur les documents écrits se rapportant au

sujet d’étude.

5. SUBDIVISION DU TRAVAIL

Notre travail est subdivisé, hormis l’introduction générale et la

conclusion générale, en 3 chapitres à savoir :

- CHAPITRE I : MODELISATION DES BESOINS, Dans ce chapitre nous

avons présenté l'existant, les besoins des utilisateurs, le contexte, qui nous

ont conduits à avoir les cas d'utilisations et les classes participantes des

besoins fonctionnels et techniques.

- CHAPITRE II : ANALYSE OBJET ET CONCEPTION DE L'ARCHITECTURE

TECHNIQUE, dans ce chapitre nous présentons les scénarios des cas

d'utilisations obtenus au niveau du premier chapitre et les diagrammes

dynamiques qui ressortent de cette analyse, nous réétudions les classes

participantes et la conception générique.

- CHAPITRE III : CONCEPTION OBJET, dans ce chapitre nous présentons la

conception détaillée du système qui abouti au codage.



CHAP I : MODELISATION DES BESOINS

1.1. ETUDE PRÉLIMINAIRE

La première phase lors de l’étude d’un système est l’étude

préliminaire. Celle-ci se base sur la recherche des besoins fonctionnels et

opérationnels, en utilisant principalement des diagrammes simplifiés et une

description textuelle. Elle prépare les activités formelles de capture des besoins

fonctionnels et de capture techniques.

1.1.1 Recueil des besoins fonctionnels

Plusieurs recherches ont été effectuées pour identifier au mieux

les besoins des utilisateurs afin de répondre à leurs attentes. Nous avons recueilli

les informations au sein du Département des Services Administratives Sud (DSA/S)

pour bien définir le périmètre de notre système. Toutes les informations trouvées

nous ont permis d’établir le cahier des charges suivant :

Le Département DSA/S reçoit des courriers provenant de

Directions, Départements, Divisions et Services de la GCM ; des sociétés

partenaires ; des individus ou des agents n'engageant pas leur Service, …

A l'arrivée du courrier, le Secrétaire du DSA/S réceptionne et lit

les indications mentionnées sur l'enveloppe. Il se renseigne délicatement sur

l'émetteur du Courrier et/ou le porteur.

Il peut s'agir d'un courrier confidentiel (privé) ou d'un courrier de

service. Dans le premier cas, le Secrétaire du DSS le remet en mains propre au

DSS/DIR. Et dans le second cas, il prend connaissance du contenu du courrier, en

vérifiant le degré de priorité puis le transmet au bureau d'administration.

L'agent chargé d'horodatage et enregistrement des courriers

(Bureau d'administration du Secrétariat) tiens à jour le registre des courriers reçus.

Pour chaque courrier reçu, il enregistre dans l'ordre:

1) la date de réception du courrier (qu'il inscrit sur le courrier reçu);



2) le numéro d'ordre d'arrivée du courrier (qu'il attribue à chaque courrier

reçu) le numéro d'ordre est renouvelé à chaque début d'années pour les

nouveaux courriers.

3) le numéro de référence du courrier (de l'expéditeur);

4) l'expéditeur du courrier;

5) l'objet du courrier ou le résumé explicatif;

6) le destinataire;

Après enregistrement, le courrier est remis au Secrétaire pour la

présentation au Départemental. Si le courrier reçu fait référence à un autre courrier

déjà archivé et classé auparavant, celui-ci sera retiré du classeur par le chargé de

saisies et classement. Deux courriers seront alors placés côte à côte dans le

signataire. Le signataire sera ensuite déposé à l'angle gauche du bureau du

DSS/DIR.

Les courriers portant la mention "Urgent" sur l'enveloppe, sont

présentés dans un signataire distinctif.

Après étude des courriers par le DSS/DIR, les signataires sortent

avec des annotations et directives sur chaque courrier.

Exemples : Voir ENS, Voir AGS, Note de regret, à classer,…

Le Secrétaire transmet le courrier étudié et annoté au bureau

d'administration du Secrétariat pour le classement, la réorientation ou l'édition

d'un document de réponse selon l'esprit des annotations.

L'agent chargé d'horodatage et enregistrement des courriers

poursuit l'enregistrement des informations supplémentaires dans le registre de

courriers reçus, de chaque courrier traité. Les données enregistrées sont :

7) la date de sortie du courrier du bureau DSS/DIR

8) le classement du courrier;

Lorsque les annotations ordonnent le classement d'un courrier, le

bureau d'administration du Secrétariat procède au classement du courrier après

enregistrement du code du classeur dans le registre de courriers reçus.



Dans le cas d'une réorientation, un carnet de transmission est

complété au bureau d'administration du secrétariat. Le courrier et le carnet sont

remis à l'agent Huissier qui s'occupera de la transmission du courrier vers la

nouvelle destination. Les éléments mis en évidence dans ce carnet sont :

1) La date de transmission du courrier

2) Le numéro d'ordre cité plus haut

3) Le numéro de référence du courrier cité plus haut

4) L'objet du courrier (celui mentionné dans le registre)

5) Les annotations (mentionnées par le DSA)

6) Le destinataire (réorienté) d'après les annotations du DSS/DIR

7) La date d'accusée de réception du courrier

8) La signature de l'agent accusant réception du courrier

Le Département DSS émet également des courriers vers d'autres

Directions, Départements, Divisions et Services de la GCM. Lorsque le document

est prêt pour l'expédition, le bureau administratif du Secrétariat DSS prend bon

soin de noter les indications nécessaires dans le registre des courriers expédiées. Il

s'agit des données signalétiques suivantes :

1) La date d'expédition du courrier ;

2) le numéro de référence du courrier. donné par CID chaque année ;

3) le destinataire ;

4) l'objet du courrier ;

5) l'observation.

Dès que tout est prêt pour l'expédition du courrier, l'agent

huissier du Secrétariat DSA, muni du cahier de transmission et des courriers à

transmettre, s'en va acheminer les courriers vers les destinataires respectifs et

prend le soin d'obtenir d'eux la date et la signature pour accusé de réception.

Les ressources hardware et software de la Direction DSS

Pour assurer une bonne prestation, le Département DSS a mis à la

disposition de son Secrétariat un certain nombre d'outils de travail dont une

solution informatique.



a. Les Matériels (hardware)

Il s'agit des tous les appareils utilisés par le Secrétariat de la

Direction DSA :

� un ordinateur de bureau Intel Pentium ® 4 ; 2.66 GHz ; 80 Go HDD

� une imprimante HP LaserJet 1320

� un onduleur de 625 KVa

� un stabilisateur

� un téléfax

� 3 téléphones fixes

� deux routeurs (WIFI) d'où il tire la connexion internet à l'aide d'un Link 6.

b. Les logiciels de base

Nous entendons par logiciel de base, le système d'exploitation et

l'environnement de travail ou logiciels utilitaires. Parmi les logiciels utilisés, nous

pouvons citer :

o Le système d’exploitation :

Il y a 2 systèmes d'exploitation Windows XP Pro déjà installés sur 2

partitions (Lecteur C et D)

o Logiciels :

La, suite bureautique MS Office 2003 (MS Word, MS Excel, …), et

MS office XP (MS Word 2002, MS Excel 2002…), l'antivirus

NORTON 2008, Antivirus AVG 7.0, Ahead Software AG Nero

Burning ROM 6.6, Acrobat 5.0 et Acrobat 7.0 , Visual C++ 2005,…



Structure du Département DSS

Figure 1. Organigramme du Département DSS de la GCM (Source : DSA/S)

Sigles :

DSS : Département des Services Administratifs du Groupe Sud

DSS/DIR : Directeur du Département DSS

DSS/SEC : Secrétariat de la Direction DSS

ADM-BDG+RCT : Administration, Budget & Recrutement du DSS

AGS : Division de l’Administration du Groupe Sud

AGS/DIR : Directeur de la Division AGS

AGS/SEC : Secrétariat de la Division AGS

ENS : Division de l'Enseignement du Groupe Sud

DDDDépartement des SSSServices Administratifs du groupe SSSSUD DSS/DIR

DSS/ADM-BDG+RCT

DSS/SEC

Division Enseignement du Groupe Sud

ENS/DIR

ENS/SEC

Division Administration du Groupe Sud

AGS/DIR

AGS/SEC

AD

M

SE

C

PR

IM

SA

S

SG

X

SP

L



ENS/DIR : Directrice de Division ENS

ENS/SEC : Secrétariat de la Division ENS

ADM : Service administratif de la Division ENS

SEC : Service de l'enseignement SECONDAIRE Groupe SUD

PRIM : Service de l'enseignement PRIMAIRE Groupe SUD

SAS : Service d'Actions Sociales Groupe Sud

SGX : Services Généraux

SPL : Service du Personnel

Les agents en charge des courriers ont émis les besoins suivants :

- La facilitation de la recherche d’un courrier : le système doit être en mesure

de permettre, en un temps réduit, la recherche d’un courrier pris en

référence ou recherché pour être annexé ou éventuellement pour une

consultation.

- Le suivi des courriers en attente de réponse (FeedBack) : le système doit

être en mesure de rappeler en temps réel les courriers qui attendent une

réponse selon un délai d’attente.

- Le rappel des courriers mis en suspend : le système doit être capable de

rappeler les courriers mis en attente pour traitement et cela un jour avant la

date requise pour le traitement.

Le système doit permettre, à tout moment de la journée, au Départemental

de connaître le nombre de courriers qu’il a à traiter.

Le modèle, parmi tant d'autres, qui peut être proposé est la

conception d'une application de gestion de courrier.

Cette application doit permettre le suivi des courriers mis en

attente (pour traitement) et le suivi des courriers qui attendent des réponses. Elle

doit aussi permettre de suivre la transmission des courriers ainsi que leur

classement ou archivage.

Pour répondre aux besoins soulevés ci-haut, des méthodes et des

techniques doivent être opérées.



1.1.2 Choix techniques

Plusieurs techniques et méthodes existent pour l’analyse et la

conception d’un système. Dans cette étude, nous avons opté pour les techniques

suivantes:

- UML. Dans sa deuxième version pour la modélisation du système.

- Une programmation orientée objet dans une architecture à 3 couches

- Visual Basic 6.0 pour la programmation de l'application.

- Le système de gestion de base de données SQL Server pour l'élaboration

d'une base de données.

- Utilisation des ateliers de génie logiciel PaceStar UML et Power Designer

pour la représentation des modèles UML ainsi que Visio et Packet Tracer

pour la présentation des modèles réseaux.

Plusieurs démarches utilisant UML sont présentes : 2TUP, XP,

Scrum, RUP,…). De toutes ces démarches, nous avons opté pour la méthode 2TUP

à cause de son originalité et son agilité. Cette méthode se base sur les principes du

processus UP.

Un processus définit une séquence d’étapes, en partie 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. [Roques & Vallée, 2004].

2TUP signifie « 2 Track Unified Process» .C’est un processus qui

répond aux caractéristiques du Processus Unifié. Le processus 2TUP apporte une

réponse aux contraintes de changement continuel imposées aux systèmes

d’information de l’entreprise. En ce sens, il renforce le contrôle sur les capacités

d’évolution et de correction de tels systèmes. « 2 Track» signifient littéralement que

le processus suit deux chemins : fonctionnel et technique. Ces deux chemins

correspondent aux deux axes de changement imposés au système d’information.

La branche fonctionnelle (partie gauche) se base sur la

connaissance du métier de l’entreprise. Les fonctions du système d’information

sont indépendantes des technologies utilisées. Cette branche comporte les étapes

suivantes :



- La capture des besoins fonctionnels, basé sur le métier des utilisateurs.

- L’analyse de ces besoins fonctionnels.

La branche technique (partie droite) : se base sur un savoir-faire

technique. Cette branche comporte les étapes suivantes :

- La capture des besoins techniques.

- La conception générique.

La branche du milieu : à l’issue des évolutions du modèle fonctionnel

et de l’architecture technique, la réalisation du système consiste à fusionner les

résultats des 2 branches. Cette branche comporte les étapes suivantes : la

conception préliminaire, la conception détaillée, le codage et l’intégration. Cette

fusion conduit à l’obtention d’un processus en forme de Y.

Figure 2. Le processus de développement en Y

Le processus 2TUP s’appuie sur UML tout au long du cycle de

développement, car les différents diagrammes de ce dernier permettent de part

leur facilité et clarté, de bien modéliser le système à chaque étape.



1.1.3 Identification des acteurs

Dans un système donné, il y a des acteurs qui agissent. Un acteur

représente l'abstraction d'un rôle joué par des entités externes (utilisateur,

dispositif matériel ou autre système) qui interagissent directement avec le système

étudié [Roques & Vallée, 2004].

.

Pour réduire la complexité du système de gestion de courriers,

nous avons restreint notre champ d'application sur la gestion de courriers

uniquement dans un département. Notre périmètre est le Département DSS dans

sa gestion de courriers.

Il y a 7 acteurs qui apparaissent dans ce périmètre, à savoir :

- Le Départemental : Le départemental traite tous les courriers qui entrent et

sortent de son bureau. Il appose des annotations en rapport

avec la transmission, la réorientation ou le classement de

ces courriers.

- Le Secrétaire : le secrétaire réceptionne les courriers, il vérifie la présentation

et transfère pour enregistrement. Il rappelle les courriers en

suspend pour le traitement et effectue le suivi des courriers

qui attendent une réponse.

- L’attaché au Bureau Administration : il enregistre les courriers émis ou reçus.

- L’attaché au Bureau Archivage : il archive les courriers selon un mode de

classement.

- L'Huissier : il achemine les courriers vers les destinataires respectifs.

- L’Expéditeur : envoi des courriers au département

- Le Destinataire : reçoit les courriers en provenance du Département.

Mais le système ne sera utilisé que par 5 acteurs : Le

Départemental, le secrétaire, l'attachée au bureau d'administration, l'attachée au

bureau d'archivage et l'expéditeur.



1.1.4 Identification des messages

"Un message représente la spécification d'une communication

unidirectionnelle entre objets qui transporte de l'information avec l'intention de

déclencher une activité chez le récepteur" [Roques et Vallée, 2006].

Un message est normalement associé à deux occurrences

d'événements : un Evénement d'envoi et un événement de réception. Cette

notion de message est également tout à fait applicable pour décrire les interactions

de plus haut niveau entre les acteurs et le système.

Pour notre étude de cas GESTCOUR, nous avons les messages

suivants entre le système et ses acteurs :

Le système GESTCOUR émet :

� Les courriers mis en attente de traitement,

� Les courriers archivés,

� Les courriers transmis,

� Les courriers en attente de feedBack (réponse)

Le système GESTCOUR reçoit :

� Les créations, modifications des courriers,

� L’enregistrement du classement des courriers,

� Les créations de classeurs,

� Les informations de suivi d’un courrier (FeedBack),

� Les connexions au système

� Les visualisations des courriers (recherche, visualisation pure)



Diagramme de contexte dynamique de GESTCOUR

A partir des informations obtenues lors des deux précédentes étapes,

nous allons modéliser le contexte de notre application. Ceci nous permettra de

définir les besoins fonctionnels de chaque acteur dans le système (Tableau 1) :

Utilisateurs Description des besoins fonctionnels

Départemental Le système GESTCOUR permettra au Départemental :

• de s'authentifier

• de consulter les courriers qu'il doit traiter

• de consulter les courriers qui attendent une réponse.

• de rechercher un courrier déjà classé ou transmis.

Attachée au bureau

administration

GESTCOUR permettra à l'Attachée du bureau administration :

• de s'authentifier,

• de gérer les courriers entrants/sortants et à transmettre.

Secrétaire GESTCOUR permettra au Secrétaire :

• S'authentifier

• de consulter les courriers que le départemental doit

traiter

• de consulter les courriers qui attendent une réponse.

• de rechercher un courrier déjà classé ou transmis.

Attachée au bureau

archivage

GESTCOUR permettra à l'Attachée au bureau archivage :

• de s'authentifier

• de gérer les classeurs et l'archivage des courriers.

Destinataire/Expéditeur GESTCOUR permettre au Destinataire :

• de recevoir/envoyer son courrier

Tableau 1 : Contexte dynamique de GESTCOUR



Le diagramme de contexte de GESTCOUR est le suivant :

Figure 3. Diagramme de Contexte dynamique

1.2. ANALYSE FONCTIONNELLE

La capture des besoins fonctionnels est la première étape de la

branche gauche du cycle en Y. Elle formalise et détaille ce qui a été ébauché au

cours de l’étude préliminaire nous dit Roques.

Cette capture peut être facilitée par un diagramme d'activités

représentant toutes les activités de chaque utilisateur du système. ce diagramme

d'activités est appelé diagramme d'activités par couloir de responsabilité.

Consulter réponse courriers (FeedBack)

GESCOUR

S'authentifierConsulter les courriers à traiter

Rechercher courriers

Liste courriers en attente

Liste courriers Feedback

S'authentifierCréer , Modifier Courrier E/SCréer transmition courrier

S'authentifierCréer classeursCréer Archivage courrier

Consulter réponse courriers (FeedBack)

S'authentifierConsulter les courriers à traiter

Rechercher courriers Recevoir courrier

Départemental

Secrétaire

Attachée Bur.Admin

Attachée. Bur. Archiv

Destinataire



Cas d'un courrier sortant.

Figure 4. Diagramme d'Activité "CourrierSortant"

Dans ce premier diagramme, à partir des activités énumérées, nous

voyons que certaines activités peuvent être regroupées en une vue générale.

Du poste du départemental jusqu'au poste du secrétaire, il apparaît des

activités qui peuvent être regroupés en une vue "GérerCourrierSortant". Cette

gestion du courrier concerne plus le bureau d’administration vu que c’est ce

dernier qui attribue un numéro d’entrée et effectue l'auto-datant de ces courriers. Il

apparaît aussi la transmission des courriers. Cette partie sera explicité dans le

deuxième diagramme d'activités.



Cas d'un courrier entrant

Figure 5. Diagramme d'activités "CourrierEntrant"

Dans ce second diagramme, on peut avoir une gestion de

l’archivage des courriers, la transmission des courriers, la gestion des courriers

entrants ainsi que la gestion des FeedBack (si il y a une attente de réponse).



1.2.1 Détermination des cas d’utilisation

Un cas d’utilisation (use case) représente un ensemble de

séquences d’actions réalisées par le système et produisant un résultat observable

intéressant pour un acteur particulier [UML 2 en action].

Un cas d’utilisation modélise un service rendu par le système. Il

exprime les interactions acteurs/système.

Chaque cas d’utilisation spécifie un comportement attendu du

système considéré comme un tout, sans imposer le mode de réalisation de ce

comportement. Il permet de décrire ce que le futur système devra faire, sans

spécifier comment il le fera. Le cas d’utilisation met en valeur les interactions

métier entre les acteurs et le système (au niveau fonctionnel).

Le tableau ci-dessous montre les cas d’utilisation retenus dans le

système GESTCOUR

Cas d'utilisation Acteur principal, acteurs

secondaires Messages émis/reçus par les acteurs

Attachée au Bureau

d’administration

Emet : Création, mise à jour, annulation des

courriers entrants.

Reçoit : Condition du courrier

GérerCourrierEntrant

Destinataire Reçoit : Réponse (si c’est nécessaire)

GérerArchivage Attaché au Bureau

archivage

Emet : Création, mise à jour Classeurs

Attachée au bureau

d’administration

Emet : Création, mise à jour des transmissions GérerTransmission

Huissier Reçoit : Accusé Réception

Secrétaire Emet : Mise à jour des courriers en attente de

réponse

GérerFeedBack

Départemental Reçoit : Etat final des courriers en attente de

réponse

Secrétaire Emet : Mise à jour des courriers en suspend GérerCourrierSuspend

Départemental

Reçoit : Etat final des courriers en suspend

GérerCourrierSortant Attachée au bureau

d'administration

Emét : Création, modification des courriers

sortants.

Tableau 2 : Cas d'utilisation de GESTCOUR



Description préliminaire des cas d’utilisations

Voici une description préliminaire des cas d’utilisations énumérés ci-haut :

1. GérerCourrierEntrant :

- Intention : Gérer tous les courriers entrants au sein du département.

- Actions : Pour les courriers entrants; le bureau d'administration effectue

l'auto-datage, enregistre les éléments signalétiques des courriers dans

le système ainsi que l’expéditeur.

2. GérerCourrierEntrant :

- Intention : Gérer tous les courriers Sortant au sein du département.

- Actions : Pour les courriers sortants, il enregistre, comme pour les

courriers entrants, les éléments signalétiques et le destinataire.Le

bureau d'administration modifie également les éléments d'un courrier

s'ils ont été mal saisis.

3. GérerTransmission

- Intention : Assuré le suivi d’une transmission d’un courrier

- Actions : En rapport avec les annotations mises sur les courriers par le

Départemental, le bureau d'administration gère la transmission des

courriers en enregistrant les courriers à transmettre. Le huissier est

chargé de revenir avec un accusé réception dans le système.

4. GérerArchivage :

- Intention : Gérer le classement des courriers

- Actions : Le bureau archivage est chargé de classer les courriers en

suivant un mode de classement déjà établit. Il crée des classeurs quand

il en manque et supprime quand le besoin se fait sentir. Il range les

classeurs dans les rayons. Il effectue la recherche des courriers qui

doivent être traité (cas des courriers en suspend), des courriers

référencés, etc.



5. GérerFeedBack

- Intention : assurer le suivi des courriers en attente de réponse

- Actions : Le secrétaire est chargé de valider les courriers ayant reçues

une réponse ou changés d’état (de l’état en attente à l’état répondu).

6. GérerCourrierSuspend

- Intention : assurer le suivi des courriers en suspend

- Actions : Le secrétaire est chargé de valider les courriers en suspend qui

ont été traités et de rappeler au départemental les courriers qui doivent

être traités selon la date de traitement prévue.

Le Départemental utilise ces deux derniers cas d’utilisation en

consultation. Il a une vue générale des courriers qui attende un feedback pour

insister sur l’urgence des réponses à ces courriers. Il peut également consulter les

courriers qui attendent d'être traités ou éventuellement rechercher un courrier.



Ce qui donne le diagramme de cas d’utilisation suivant :

Figure 6. Diagramme de Cas d’utilisation

1.2.2 Description détaillée des cas d’utilisations

Vallée nous dit que la description du cas d’utilisation décrit l’intention

de l’acteur lorsqu’il utilise le système et les séquences d’actions principales qu’il

est susceptible d’effectuer.

Les descriptions se présentent comme suit :

- Un sommaire d’identification résumant les propriétés du cas d’utilisation.

- Une description détaillée présentant les Pré-conditions qui entraîne le

déclenchement du cas d’utilisation jusqu’à sa réalisation.

- Les diagrammes apportent une compréhension supplémentaire au cas

d’utilisation. Mais ils sont optionnels.

Cette description des cas d’utilisation se présente sur une fiche appelé

fiche d’identification. Dans notre cas d'étude nous avons retenu les fiches

suivantes :

GérerTransmission

GérerArchivage

Départemental

GérerCourrierSuspend


Att. Bur.Admin

Att. Bur.Archiv

Secrétaire

GérerFeedBack

ExpéditeurGérerCourrierSortant

Destinataire



Fiche d'identification du cas d’utilisation : "GérerCourrierEntrant"

Description des enchaînements

Titre : GérerCourrierEntrant But : Gérer les courriers reçus. Résumé : Création, modification d'un courrier Acteurs : Attachée au bureau d’administration Date de création : 3/05/2009 Date de mise à jour : 12/07/2009 Version : 1.0 Responsable : Diane NGOIE

Précondition : L'attachée au bureau d’administration s'est déjà authentifiée. Enchainements nominaux :

Ce cas d'utilisation commence lorsqu'il y a un courrier Entrant, Alors

l'attachée au bureau d’administration demande au système la création d'un courrier.

Enchaînement (a) Créer un courrier Entrant

L'attaché saisit le Numéro d’entrée du courrier. Le système vérifie si ce

numéro existe. Si le numéro saisie existe alors exécution de [Exception 1 :

NumCourrierExistant].

L'agent saisit ensuite toutes les informations liées au courrier (le numéro de

référence du courrier, le résumé du courrier, l’expéditeur) et demande la validation

du courrier.

Le système vérifie le format des données. Si le format n’est pas conforme ;

alors exécuter [Exception 2 : ErreurFormat].

Enchainement (b) Valider Création courrier

L'attachée valide la création du courrier. Le système attribue une date de

création du courrier.



Exceptions :

[Exception 1 : NumCourrierExistant] :

Le système affiche un message d'erreur et demande la saisie d’un nouveau numéro de courrier. Il désactive la validation du courrier jusqu’à la saisie du nouveau numéro de courrier.

[Exception 2: ErreurFormat] :

Le système affiche un message d'erreur et demande la modification du format des données selon ceux qui sont définis. Post-conditions - Le courrier validé a un numéro d’enregistrement,

- les données saisies respectent les formats définis.

Enchainements alternatifs :

Enchainement (c) Annuler Création Courrier

Lors de la création d’un courrier, il peut se faire que ce courrier soit adressé à

un autre département ou à une des divisions du département, alors l’attachée au

bureau d’administration annule la création du courrier dans le système. Enchainementd) Modifier Courrier

Lors de la création du courrier, il se peut que l’attachée ait mal saisie les

éléments du courrier, le système lui permet de modifier ce qui a été mal saisie.

Le cas d’utilisation « GérerCourrierEntrant » prend fin quand l’attachée valide

la création du courrier ou l’annulation. Le courrier contient le numéro d’entrée, la

date, le résumé, l’expéditeur et le numéro de référence.



Voici le diagramme de séquences représentant les messages échangés, pour le cas

d’utilisation "GérerCourrierEntrant", entre le système et l'attachée au bureau

d'administration.

Figure 7. Diagramme de séquences du cas d’utilisation « GérerCourrierEntrant »

Le système est vu, à ce niveau, comme une boîte noire.

Fiche d'identification du cas d’utilisation : "GérerCourrierSortant"

La fiche d'identification du cas d'utilisation "GérerCourriersortant" est identique à

la fiche d'identification du cas d'utilisation "GérerCourrierEntrant". Mais la petite

différence est qu'à la création d'un courrier sortant, l'expéditeur est remplacé par

le destinataire.



Fiche d'identification du cas d’utilisation : "GérerArchivage"


Titre : GérerArchivage But : Gérer le classement des courriers reçus. Résumé : Création, modification d'un classement. Acteurs : Attachée au bureau d’archivage Date de création : 3/05/2009 Date de mise à jour : 12/07/2009 Version : 1.0 Responsable : Diane NGOIE

Précondition : L'attachée au bureau d’archivage s'est déjà authentifiée. Il existe au moins un courrier enregistré dans le système. Enchainements nominaux :

Ce cas d'utilisation commence lorsqu'il y a un courrier Entrant à classer, Alors

l'attachée au bureau d’archivage demande au système l'archivage d'un courrier.

Enchaînement (a) Créer un Archivage.

L'attaché saisit le Numéro du courrier. Le système vérifie si ce numéro existe.

Si le numéro saisie n'existe pas alors exécution de [Exception 1 :

NumCourrierInexistant]

L'agent saisit le code du classeur. Le système vérifie si ce classeur existe. S'il

n'existe pas alors [Exception 2 : CodeClasseurInexistant]. Enchainement (b) Valider Création Archivage

L'attachée valide l'archivage du courrier. Le système attribue une date

d'archivage et un numéro d'archivage.




Enchainement (c) Créer un nouveau classeur

Lors de l'archivage d’un courrier, il peut se faire que ce courrier soit à archiver

dans un classeur qui n'existe pas dans le système. dans ce cas, il faudra d'abord créer

un classeur.

Le cas d’utilisation « GérerArchivage » prend fin quand l’attachée au bureau

archivage valide l'archivage du courrier ou l’annulation. L'archivage contient le

numéro du courrier, le classeur et la date de l'archivage.

Exceptions :

[Exception 1 : NumCourrierInexistant] :

Le système affiche un message d'erreur et demande la saisie d’un numéro de

courrier existant. Il désactive la validation jusqu’à la saisie du numéro de courrier.

[Exception 2: CodeClasseurInexistant] :

Le système affiche un message d'erreur et demande la modification du

CodeClasseur.

Post-conditions - Le courrier traité est archivé,

- il existe au moins un classeur.



Le diagramme de séquences qui illustre cette description est :

Figure 8. Diagramme de séquences du cas d’utilisation « GérerArchivage »

Fiche d'identification du cas d’utilisation : "GérerTransmission"

Titre : GérerTransmission But : Gérer la transmission des courriers E/S. Résumé : Création Transmission. Acteurs : Attachée au bureau d’administration Date de création : 3/05/2009 Date de mise à jour : 12/07/2009 Version : 1.0 Responsable : Diane NGOIE





Enchainement (c) Modifier une transmission

Lors de l'enregistrement de la transmission d’un courrier ou pour un courrier

dont la transmission est déjà validée, il peut se faire que le destinataire ait été mal saisi.

dans ce cas, il faudra modifier le destinataire puis (re) valider.

Le cas d’utilisation « GérerTransmission » prend fin quand l’attachée au

bureau administration valide la transmission du courrier ou l'annulation de la

transmission. L'archivage contient le numéro du courrier, le destinataire et la date de

transmission.

Exceptions :

[Exception 1 : NumCourrierInexistant] :


courrier existant. Il désactive la validation jusqu’à la saisie d'un numéro de courrier

valide.

Post-conditions 1. Le courrier est transmis

Précondition : L'attachée au bureau d’administration s'est déjà authentifiée. Il existe au moins un courrier enregistré dans le système. Enchainements nominaux :

Ce cas d'utilisation commence lorsqu'il y a un courrier Entrant/Sortant à

transmettre, Alors l'attachée au bureau d’administration demande au système

l'enregistrement de la transmission du courrier.

Enchaînement (a) Créer une transmission d'un courrier.

L'attaché saisit le Numéro du courrier. Le système vérifie si ce numéro existe.

Si le numéro saisie n'existe pas alors exécution de [Exception 1 :

NumCourrierInexistant]. L'agent saisit le destinataire

Enchainement (b) Valider Transmission courrier.

L'attachée valide la transmission du courrier. Le système attribue une date de transmission et un numéro de transmission.



La description du cas d'utilisation peut être aussi représentée par un modèle UML.

Figure 9. Diagramme de séquences du cas d’utilisation « GérerTransmission »

Fiche d'identification du cas d’utilisation : "GérerFeedback"

Titre : GérerFeedback But : Gérer les réponses des courriers transmis. Résumé : Validation d'une réponse au courrier transmis Acteurs : Secrétaire Date de création : 3/05/2009 Date de mise à jour : 12/07/2009 Version : 1.0 Responsable : Diane NGOIE




Exceptions :

[Exception 1 : CourrierNonTransmis] :


courrier transmis. Il désactive la validation jusqu’à la saisie du numéro de courrier.

Post-conditions Validation de la réponse au courrier transmis

Précondition : Le secrétaire s'est déjà authentifié. Au moins un courrier attend une réponse. Enchainements nominaux :

Ce cas d'utilisation commence lorsqu'un courrier transmis reçoit une réponse,

Alors le secrétaire demande au système la validation de la réponse.

Enchaînement (a) Valider FeedBack

L'attaché saisit le Numéro du courrier transmis. Le système vérifie si ce

numéro existe. Si le numéro saisie n'existe pas ou existe mais n'a pas été transmis,

alors exécution de [Exception 1 : CourrierNonTransmis].

L'agent saisit ensuite toutes le numéro de référence du courrier reçu en

réponse et valide.



Voici le diagramme de séquences représentant les messages échangés, pour le cas

d’utilisation "GérerFeedback", entre le système et le secrétaire.

Figure 10. Diagramme de Séquences du cas d'Utilisation "GererFeedback"

Fiche d'identification du cas d’utilisation : "GérerCourrierSuspend"

Dans la gestion des courriers en suspend, le secrétaire a une vue de

tous les courriers qui sont mis en suspend. De la même façon qu'il valide les

réponses aux courriers transmis, il valide aussi le traitement d'un courrier qui a été

mis en suspend.



1.2.3 Organisation des cas d’utilisations

Les cas d’utilisation peuvent être organisés de deux façons différentes et complémentaires, dit Pascal Roques, à savoir :

� en ajoutant des relations d’inclusion, d’extension, et de généralisation entre les cas d’utilisation ;

� en les regroupant en packages, afin de définir des blocs fonctionnels de

plus haut niveau.

UML définit trois types de relations standardisées entre cas d’utilisation :

� une relation d’inclusion, formalisée par un mot-clé <<include>>, � une relation d’extension, formalisée par un mot-clé <<extend>>, � une relation de généralisation/spécialisation.

Dans notre cas d'étude, nous retrouvons uniquement l'inclusion et la

généralisation. Les Uses case "GérerCourrierEntrant" et "GérerCourrierSortant"

peuvent être généralisés en un cas d'utilisation abstrait "GérerCourrier".

Figure 11. Cas d'utilisation généralisés.

Les uses case "GérerTransmission" et "GérerClassement" sont des cas qui

étendent la gestion des courriers. Les points d'extensions sont la transmission et le

classement. "GérerCourrierSuspend" est un cas inclus dans la gestion de courrier

parce que tout courrier enregistré est en suspend.

<<Généralisation>>

GérerCourrier


Att. Bur.Admin

GérerCourrierSortant




Figure 12. Uses case dans GérerCourrier

Le cas d'utilisation "GérerTransmission" gère aussi les réponses qui proviennent

des courriers transmis, d'où le cas d'utilisation "GérerFeedback" est un cas inclus

dans le cas d'utilisation "GérerTransmission".

Figure 13. Cas d'utilisation inclus dans Gérer transmission.

Ces cas d'utilisation organisés doivent être regroupés en package.

Les éléments contenus dans un package :

� doivent représenter un ensemble fortement cohérent,

� sont généralement de même nature et de même niveau sémantique

Le critère de regroupement retenu pour le système GESTCOUR

correspond à un découpage par ensemble d’acteurs fortement reliés. En reprenant

le tableau préliminaire et en affectant chaque cas d’utilisation à un package, nous

obtenons ce qui suit :

<<Extend>>

<<Extend>>


<<Include>>


GérerTransmission

GérerCourrier

GérerArchivageGérerCourrierSuspend


Att. Bur.Admin

Att. Bur.Archiv

Secrétaire


Point d'extension :Classer Courrier

Point d'extension :Transmettre Courrier

<<Include>>

GérerTransmission

Att. Bur.Admin

Secrétaire

GérerFeedBack



Cas d’utilisation Acteurs Package

Attachée Bur. Admin GérerCourrierEntrant

Expéditeur

Attachée Bur. Admin GérerCourrierSortant

Destinataire

GérerCourrierSuspend Secrétaire

Gestion Courrier

Gérer Classement Attachée Bur. Archiv Gestion classement courrier

GérerTransmission Attachée Bur. Admin

GérerFeedBack Secrétaire

Gestion transmission

courrier

Tableau 3 : Package des cas d'utilisation.

Chaque package de cas d’utilisation occasionne la création d’un

diagramme de cas d'utilisation.

1.2.4 Identification des classes candidates

L'identification des classes candidate est fonction des concepts

connus; c'est-à-dire, ceux qui sont utilisés couramment dans la gestion des

courriers (les objets métier).

Exemple : CourrierEntrant, CourrierSortant, CourrierSuspend,

transmission, classement, registre, TypeCourrier, etc.

Nous ajouterons dans un second temps des concepts « applicatifs »,

liés à l’informatisation. Exemples pour l’étude de cas : Profil utilisateur, etc.

De la description de chaque cas d'utilisation, il y a des classes

participantes qui en découlent, soit par les concepts connu ou les concepts

applicatifs, comme dit ci-haut.

Nous formalisons ensuite ces concepts métier sous forme de classes

et d’associations rassemblées dans un diagramme statique pour chaque cas

d’utilisation.

Ces diagrammes de classes participantes, appelés «diagrammes

préliminaires», n’ont pas d’objectif exhaustif. Ils servent uniquement à démarrer la

découverte des classes du modèle d’analyse pour la partie de l’application.



Voici les diagrammes de classes participantes de certains cas

d'utilisation :

Diagramme de classes participantes du cas d'utilisation "GérerTransmission"

Figure 14. Diagramme de Classes participantes du CU "Gérertransmission"

La transmission, l'accusée réception, reçu et pas reçu, le

courrierEntrant (ou courrier sortant) apparaissent en classes dans le diagramme. La

classe Accusée réception est une classe abstraite ayant pour instance les classes

reçu et pas reçu sont des classes abstraites qui se généralisent dans la classe

Accusée réception.

Les classes courrierEntrant et courrierSortant sont des classes qui se

généralisent dans la classe Courrier qui est une classe abstraite.

Diagramme de classes participantes du cas d'utilisation "GérerClassement"

Figure 15. Diagramme de Classes participantes du CU "Gérerclassement"

reçoit

1..*

1..1

Concerne1..1 0..*appartient1..1 0..*TypeCourrier CourrierEntrant Transmission

Accusée Réception

Reçu Pas reçu

est rangé

1..1 1..*

0..*

1..1

appartient subit Concerne1..* 1..11..1 0..*

ClasseurClassement

CourrierEntrant

TypeCourrier

CourrierSortant

Courrier

Rayon



Un courrier peut être classé dans plusieurs classeurs selon qu'il est

adressé à plusieurs destinataires. Ce qui entraine la création de la classe

classement. Un classeur est rangé dans un rayon.

1.2.5 Validation et consolidation

Dans le cadre d’un développement itératif et incrémental, il est très

utile de recourir au découpage en cas d’utilisation pour définir les itérations. À cet

effet, il convient en premier lieu d’identifier les cas d’utilisation les plus critiques

en termes de gestion des risques. Ces cas d’utilisation devront être traités

prioritairement afin de lever au plus tôt les risques majeurs. Il sera également

demandé au client d’affecter une priorité fonctionnelle à chaque cas d’utilisation,

afin de livrer d’abord les cas d’utilisation les plus demandés.1

Franck dit que nous peuvons aussi prendre en compte les

éventuelles relations entre cas d’utilisation :

développer plutôt les cas factorisés (<include>) avant ceux qui les utilisent,

développer plutôt les cas qui étendent (<extend>) après les cas de base Ce qui explique l'organisation suivante du diagramme de cas d'utilisation :

Figure 16. Diagramme de cas d'utilisation organisés

(Itération 1)

(Itération 2)

(Itération 3)

(Itération 4)

(Itération 5)

<<Extend>>

<<Extend>>

<<Include>>

<<Include>>


DépartementalGérerCourrierSuspend


Att. Bur.Admin

GérerArchivage

Att. Bur.ArchivSecrétaire

GérerFeedBack

Expéditeur

GérerTransmission


Destinataire

GérerCourrier




1.3. CAPTURE DES BESOINS TECHNIQUES Par rapport aux besoins fonctionnels, les besoins techniques

viennent en complément. Ils interessent les contraintes autres que la description

métier et la description applicative. La spécification technique est nécessaire pour

la conception d’architecture.

Cette capture des besoins interesse deux aspects : l'aspect logiciel et

l'aspect matériel. Les matériels a utiliser dans le système doivent être définis

suivant la structure logiciel prévue.1

1.3.1 Spécification technique du point de vue matériel

Dans la spécification des méthodes et techniques de

développement, nous avons fait des choix en rapport avec la configuration logiciel

et matériel a utiliser pour le cas d'étude. Cette configuration se base sur la sécurité

du système, son utilisation, l'accès aux données,…

Pour notre cas d'étude l'architecture à deux niveaux (local et

départemental) est celle qui répondra favorablement.

Les attentes (techniques) du système GESTCOUR, selon

l'architecture choisie, nous donne les nœuds suivants :

- Un poste qui fera office de serveur de base de données où sera installé

GESTCOUR;

- Un serveur de messagerie local où les courriers provenant de l'intérieure de

l'entreprise seront reçus (par mail);

- 4 postes de travail pour les acteurs internes au système;

- 1 switch;

- Un serveur Web pour permettre aux destinataires/expéditeurs externes à

l'entreprise d'envoyer leurs courriers via internet.

- Un serveur proxy pour protéger GESTCOUR des autres utilisateurs du

système.

- Une photocopieuse pour garder les traces des courriers importants transmis.

GESTCOUR sera utilisé dans chaque bureau de l'entreprise d'une

façon autonome (niveau local). La direction de la GCM aura une vue générale sur

les courriers qui circulent dans l'entreprise (niveau départemental).

1 P Roques, F Vallée, UML 2 en action, Ed Eyrolles, 2006.



Figure 17. Diagramme de déploiement GESTCOUR

Le serveur de messagerie et le serveur Web sont séparés du serveur

GESTCOUR pour ne pas permettre à d'autres personnes qui n'ont pas

l'autorisation d'accéder au informations contenues dans ce serveur. Cette

séparation est rendu possible par un Pare-Feu. Le département tire sa connexion à

partir du 7ième routeur.

<LAN>

<LAN>

Firewall

SERVEUR GESTCOURIMPRIMANTE

POSTE

(Number = 4)

SERVEUR WEBSERVEUR MESSAGERIE



Figure 18. Configuration réseau de GESTCOUR


40

1.3.2 Spécification d’architecture et influence sur le modèle de déploiement

Pascal Roques et Franck Vallée nous dissent que le choix d'une

architecture influence aussi le choix du modèle de déploiement. Ce choix

conditionne la façon dont seront organisés et déployés les composants

d’exploitation du système.

Plusieurs composants sont donc utilisés dans le système selon les

rôles qu'ils exercent. Les uns font office de bases de données et les autres des

applications qui sollicitent les bases de données.

Un composant d’exploitation est une partie du système logiciel qui

doit être connue, installée, déclarée et manipulée par les exploitants du système.

Un composant d’exploitation doit être interchangeable entre différentes versions et

peut être arrêté ou démarré séparément. Il assume des fonctions bien identifiées

dans le système, de sorte qu’en cas de dysfonctionnement, le composant incriminé

est facilement repérable1.

Le style d’architecture en tiers (tier signifie « partie » en anglais)

spécifie l’organisation des composants d’exploitation mis en oeuvre pour réaliser

le système. Chaque partie indique une responsabilité technique à laquelle

souscrivent les différents composants d’exploitation d’un système.

Roques dit que le choix d'une architecture client/serveur 3-tiers

amène à la répartition des composants d’exploitation selon :

� L'utilisation d'un moteur de base de données relationnel

� la répartition des différents métiers est faite sur plusieurs composants

métier

� la réalisation des applications correspondantes aux différents composants

d’exploitation retenus.


41

1.3.3 Élaboration et organisation du modèle de spécification logicielle

L'élaboration et l'organisation du modèle de spécification logicielle

se base sur les fonctionnalités propres du système technique. Ces fonctionnalités

forment des cas d’utilisation d'une manière différente que pour la spécification

fonctionnelle , dit Vallée.

Il poursuit en disant que les acteurs de ces cas d'utilisations

techniques sont appelés des exploitants.

Tout système informatique possède au minimum un exploitant qui

est « l’utilisateur du système ». il s’agit ici de l’utilisateur dans son sens le plus

général, indépendamment des fonctions ou du métier qu’il réalise au travers de

l’application.

Dans ce cadre, tout utilisateur se connecte au système ou utilise

l'internet. Ce sont les fonctionnalités purement techniques dont il bénéficie en tant

qu’exploitant.

Le modèle de spécification logicielle est construit sous deux étapes.

La première consiste à repertorier tous les besoins des exploitants du système et à

extraire les cas d’utilisation techniques à partir de ces besoins. La deuxième étape

réorganise en couches les responsabilités techniques1.

À chaque fonction observable pour l’exploitant, correspond en effet

une cascade de responsabilités techniques qui se déploient sur les différentes

couches logicielles. Chaque couche produisant des services pour les niveaux

supérieurs contient en conséquence des cas d’utilisation pilotés par les couches

exploitantes.


42

Les cas d'utilisations technique retenus pour GESTCOUR ainsi que leurs

exploitants sont :

- L'utilisateur :

� Utiliser des objets

� Suivre les règles de sécurité du système

� Consulter l'aide pour bien utiliser le système

- L'ingénieur d'exploitation (l'Administrateur système)

� Gérer la sécurité en utilisation du système

� entretenir les performances du système.

Figure 19. Diagramme de cas d'utilisation techniques

1.3.4 Description des couches logicielles

La responsabilité affectée à chaque couche du modèle logicielle

(présentation, application, métier, accés aux données, stockage de données) donne

une identification poussée des cas d’utilisation techniques. cela permet de poser

de manière plus précise des problèmes à traiter.

D’une part, les cas d’utilisation techniques peuvent se spécialiser

suivant les couches sur lesquelles ils vont s’exécuter ; d’autre part, de nouveaux

Administrateur Sys

Utilisateur

GérerSécurité

EntretenirPerformances

UtiliserObjets

SuivreRèglesSécurité

ConsulterAide


43

cas d’utilisation peuvent apparaître pour répondre à la particularité d’une des

couches1.

Le cas de GESTCOUR offre une illustration de ces différents cas.Par

exemple : «Manipuler des objets » va donner lieu à plusieurs cas d’utilisation qui

vont s’enchaîner depuis la couche de présentation jusqu’à la couche d’accès aux

données. Par ailleurs, pour manipuler des objets, il est nécessaire de gérer des

transactions avec la base de données relationnelle. Il s’agit donc d’un nouveau cas

d’utilisation spécifique pour la couche de stockage des données.

Pour obtenir une spécification technique détaillée de notre cas

d'étude, les éléments retenus sont :

� la recherche d'un objet au niveau de la présentation nécessite de s’appuyer

directement sur l’exploitation du schéma de données d’une classe (ou T-

uplets) au niveau de la couche d’accès aux données ;

� l'exécution d'un service au niveau de la couche métier repose sur

l’exploitation de requêtes spécifiques au niveau de la couche d’accès aux

données, qui utilise systématiquement la gestion des transactions.

1.3.5 Description d’un cas d’utilisation technique

D'après Franck Vallée, la description d’un cas d’utilisation technique

est analogue à celle des cas d’utilisation de la spécification fonctionnelle. Dans ce

cadre, on utilise un premier niveau de description, composé d’une fiche textuelle

et d’un diagramme d’activité. Un second niveau de description objet complète

éventuellement la spécification. On utilise alors un diagramme de classes et un

diagramme d’interactions.

Les concepts utilisés pour décrire les cas d’utilisation appartiennent à

la couche logicielle considérée et font l’objet d’une définition dans le dictionnaire

des termes techniques.

Exemple : Accès aux données :: GérerClasse.

Cette exemple illustre la manière dont les classes sont gérér au

niveau de la couche d'accès aux données.


44

CHAP II : ANALYSE OBJET & CONCEPTION DE

L'ARCHITECTURE TECHNIQUE

2.1. NOTIONS DE CATEGORIES

2.1.1 Découpage en catégories

D'après Pascal Roques, une catégorie est un regroupement logique

de classes à forte cohérence interne et faible couplage externe.La création d'une

catégorie est fonction du regroupement des classes sémantiquement proches. Elle

se base sur les critères suivants :

- La finalité : les classes rendent des services de même nature aux utilisateurs - L'évolution : séparation des classes métiers (classes stables) des classes

applicatives (classes qui évoluent au cours du projet). - Le cycle de vie des objets : permet de distinguer; de gérer différemment les

classes dont les objets ont des durées de vie très différentes.

Dans notre cadre d'étude, en se basant sur le premier point,

GESTCOUR peut être repartis en trois catégories : le package "CLASSEMENT", le

package "COURRIER" et le package "AGENT".

Figure 20. Packages de GESTCOUR

Ce découpage en package nous permet d'avoir une vision sur le

développement de GESTCOUR en terme de module, de réutilisabilité, etc.


45

2.1.2 Dépendance entre catégorie

La dépendance entre catégorie est fonction de la visibilité des

catégories et aussi de l'importation de certains éléments visibles d'un package par

d'autres packages.

Le sens de cette importation est rendu visible par les diagrammes de

classes d'analyse par catégorie qui montre clairement quelles sont les classses qui

sollicitent des classes appartenant à d'autres catégorie (exemple de la classe

classement qui sollicite la classse courrier) .

Deux visibilités sont retenues, à savoir :

- Public : élément utilisable par tout package relié par une

dépendance

- Private : élément utilisable que par son package parent.

Il faut aussi retenir que les dépendances entre catégories ne sont pas

transitives.

En appliquant ces principes à GESTCOUR, nous avons le diagramme

de package d'analyse suivant :

Figure 21. Diagramme de package d'analyse

La catégorie "COURRIER" importe des données de la catégorie

"AGENT" lors de l'enregistrement d'un courrier dans le système. cela pour

permettre de savoir qui a enregistrer le courrier (traçabilité).


46

La catégorie "CLASSEMENT" tire des données de la catégorie

"COURRIER" parce qu'elle ne peut classer que des courriers qui ont étés

enregistrés dans le système et applique aussi le même principe que la catégorie

"COURRIER" pour la catégorie "AGENT".

2.2. DEVELOPPEMENT DU MODELE STATIQUE

Le développement du modèle statique se base sur les diagrammes

des classes participantes (déjà présentés selon les cas d'utilisation) et le découpage

en catégorie. Il vient compléter, détailler et optimiser ces deux précédentes parties

pour produire des diagrammes de classes affinés[UML 2 en action].

D'après Roques, les classes identifiées lors de l'étude des cas

d'utilisation puis reparties dans des catégories sont maintenant réétudier, d'une

manière détaillée afin de voir s'il faut en ajouter ou en supprimer certaines. Cet

ajout ou suppression de classes se base sur les critères suivant :

- L'élimination des classes redondantes c'est-à-dire les classes représentants

les mêmes concepts (souvent dans le cas d'un progés réalisés par plusieurs

groupes d'analystes.);

- L'élimination des classes vagues : des classes trop générales et pas trop

précises;

- L' élimination des classes à la place d'attribut : ces classes expriments des

concepts quantifiables;

- L'élimination des classes à la place d'un rôle : elles expriment un rôle dans

une association particulière;

- L'élimination des classes représentant des acteurs sauf si le système gère

des informations sur l'acteur.

- L'élimination les classes de conception parce qu'elles introduisent trop tôt

le choix de réalisation.

- L'élimination des classes représentant des groupes d'objets (cas des classes

associatives).

- La subdivision des classes ayant trop de responsabilités pour reduire le

nombre d'associations, d'attribut ou d'opérations.

- Ne pas confrondre une entité de sa decription.


47

Après avoir affiné les classes, l'étude des associations est la

deuxième étape.

Dans l'étude des associations, il faut tenir compte des paramètres

suivants :

- enlever les associations transitives.

- ressortir les associations dites "Agrégation" ou "composition"

- identifier leurs règles de gestion (gestion de la suppression :AddOnly ,

refus de modification, …)

La fin de l'étude des associations, amène à la troisième étape qui est

celle d'ajouter les attributs.

Un attribut est une propriété nommée d'une classe qui décrit un

domaine de valeurs possibles partagé par tous les objets de la classe1. Un attribut

peut être simple, dérivé, un qualificatif, etc.

La quatrième étape vient ajouter les opérations. Cette étape est

optionnelle.

Une opération est un service, un traitement qui peut être demandé à

n'importe quel objet d'une classe. Vallée nous dit qu'il est possible d'identifier les

opérations par l'analyse textuelle du cahier de charge et des fiches de description

de cas d'utilisation.

La dernière étape est l'optimisation de la généralisation. À cette

phase, il faut réétudier les classes possédant des caractéristiques communes en

rapport avec les attributs, les associations et les opérations afin de pouvoir

rassembler les attributs et/ou opérations communes dans une super-classe, et de

laisser les attributs et/ou opérations dans chaque classe spécifique.

En appliquant toutes ces règles aux différents diagrammes de classes

préliminaires par catégories, nous avons les diagrammes de classes suivants :


48

Diagramme de classes de la catégorie "AGENT"

Figure 22. DCL de la catégorie "AGENT"

Diagramme de classes de la catégorie "COURRIER"

Figure 23. DCL de la catégorie "COURRIER"

Diagramme de classes de la catégorie "CLASSEMENT"

Figure 24. DCL de la catégorie "CLASSEMENT"

Ce qui nous donne le diagramme de classe global suivant :

Possède

COMPTE

LogInPassWord

: :

CréerCOMPTE ()SupprimerCOMPTE ()

AGENT

MatriculeNomPostnomAdresse

: : : :

CréerAGENT ()SupprimerAGENT ()AttribuerCOMPTE ()

0..* 1..*1..1 0..*

Placérangé

CLASSEUR

--

CodeClasseurClasseur

: :

++

Créer ()Selection RAYON ()

CLASSEMENT

--

N°ClassementDateClassement

: :

+++

Créer ()SelectionCOURRIER ()SelectionCLASSEUR ()

COURRIER

---

N°ordreNumRéfObjet

: : :

+ Créer ()

RAYON

- N°Rayon :

+ CréerRayon ()


49

Figure 25. Diagramme de classe du modèle statique

Possède

appartient

Concerne

enregistre

1..1 0..*1..1 0..*

1..1

0..*

0..* 1..*

0..*

1..1

Placérangé

CLASSEUR


: :

Créer ()Selection RAYON ()

RAYON

N°Rayon :

CréerRayon ()

CLASSEMENT


: :

Créer ()SelectionCOURRIER ()SelectionCLASSEUR ()

COMPTE

LogInPassWord

: :

CréerCOMPTE ()SupprimerCOMPTE ()

AGENT


: : : :

CréerAGENT ()SupprimerAGENT ()AttribuerCOMPTE ()

COURRIER


: : :

Créer ()

COURRIERENTRANT

EmetteurDateReception

: :

COURRIERSORTANT

Destinataire :

TYPECOURRIER

N°TypeType

: :

CréerType ()ModifierType ()

TRANSMISSION

N°TransmissionDateTransmissionDateRéceptionOrientationObservation

: : : : :

CréerTransmission ()FEEDBACK

NumFeedbackNumTransmissionDateTransmissionDateRéponseNumCourrierreçu

: : : : :

CréerFeedback ()


50

2.3. DEVELOPPEMENT DU MODELE DYNAMIQUE

Le développement du modèle dynamique est la troisième étape de

l'analyse. C'est une étape qui se base sur la description des cas d'utilisation

réalisée au cours de la capture des besoins fonctionnels et le modèle obtenu lors

du développement du modèle statique.

2.3.1 Identification et formalisation des scénarios

Lors de la capture des besoins fonctionnels, le scenario représentait

les interactions entre le système et ses acteurs, et le système était vu comme une

boîte noire. Dans le modèle dynamique, le système est éclaté.

Roques retient plusieurs types de scénarios, à savoir :

- nominaux : ces scénarios réalise les post-conditions du cas d'utilisation

d'une façon naturelle et fréquente.

- Alternatifs : ils remplissent les post-conditions mais prenant des chemins

rares.

- Aux limites : ils réalisent les post-conditions mais modifient le système de

telle sorte que la prochaine exécution du cas d'utilisation provoquera une

erreur.

- D'erreur : ne réalisent pas les cas d'utilisation.


51

Voici la description de certains cas d'utilisation :

Le cas d’utilisation "GérerCourrierEntrant" (GCE) présente des scénarios

dont les plus importants sont :

a. Scénario nominaux

� GCE-N1 : Création Courrier

� GCE-N2 : Annulation Courrier

b. Scénario alternatifs � GCE-A1 : Modification Courrier par modification du destinataire, de l'objet. c. Scénario d’exception

� GCE-E1 : non validation du courrier suite à la saisie d'un Numéro de

courrier existant.

� GCE-E2 : non validation du courrier suite au nom respect du format.

Formalisation de scénario

Scénario : Création du courrier

� L’agent saisit le Numéro d'ordre.

� Le contrôleur vérifie si ce numéro d'ordre n’a pas déjà été attribué. Si c’est

déjà attribué, il affiche un message et demande la modification du numéro

d'ordre saisi.

� L’agent saisit le Numéro de référence du courrier, l'émetteur, le destinataire, le

résumé du courrier, le type du courrier, le degré de priorité du courrier et

une observation.

� L’agent valide la création du courrier.

� Le contrôleur enregistre la date et les coordonnées de l’agent qui a enregistré

le courrier.

Pour décrire ce scénario, nous avons les lignes de vie suivantes :

- un acteur Agent,

- un courrier créé au cours du scénario : nouveauCourrier,

- un objet Courrier,


52

Le scénario GCE_N1 est présenté dans le diagramme de

séquence que voici :

Figure 26. Diagramme de séquence de GCE_N1

Il existe un autre diagramme UML qui permet de suivre les

messages selon leurs chronologies; c'est le diagramme de communication. Ce

diagramme permet d'avoir une vue à plat du système.

Création Courrier

NumOrdre Existant N°ordre Ko

retour à l'étape de saisie NumOrdre

retour à l'étape de saisie Courrier

Format incorrect Format incorrect

Vérifier FormatValiderValider

SaisirCourrier(émetteur, Réf, résumé,...)

NumOrdre Valide

NumOrdre Invalide

alt

Rechercher NumOrdreNumOrdreSaisir NumOrdre

Activer

Activer

Agent<<Boundary>>

Interface Courrier<<Control>>

Controleur<<Entity>>

Courrier<<Boundary>>

Interface d'accueil

Format Ok

Format Ko

altNouveau CourrierCreate Courrier

NumOrdre Existant N°ordre Ko

Format incorrect Format incorrect

Vérifier FormatValiderValider

SaisirCourrier(émetteur, Réf, résumé,...)

Rechercher NumOrdreNumOrdreSaisir NumOrdre

Activer

Activer

Create Courrier


53

En ne retenant que le déroulement normal du scénario de création

d'un courrier, nous aurons le diagramme de communication suivant :

Figure 27. Diagramme de communication de GCE_N1

Le cas d’utilisation "GérerClassement" (GCL) réalise des scénarios dont les

plus importants sont :

a. Scénario nominaux

� GCL-N1 : Création Classement � GC-N2 : Annulation Classement

b. Scénario alternatifs � GCL-A1 : Création d'un classeur. � GCL-A2 : Création d'un rayon c. Scénario d’exception

� GCL-E1 : non validation du courrier suite à la saisie d'un Numéro de

courrier inexistant.

� GCL-E2 : non validation du courrier suite à la saisie d'un numéro de

classement existant.

1: Activer 1.1.: Activer

4: Valider

3: SaisirCourrier(Réf, Objet, ...)

2: Saisir NumOrdre4.1: Valider

2.1: NumOrdre

2.2: Reseach (NumOrdre)

4.2: Create Courrier (N°Ordre, Réf,...)

<<Entity>>

Courrier

Agent

<<Boundary>>

Interface Accueil

<<Control>>

Controleur

<<Boundary>>

Interface CourrierNouveau Courrier


54


Scénario : Enregistrement d'un classement

� L’agent saisit le Numéro de classement.

� Le contrôleur vérifie si ce numéro de classement n’a pas déjà été attribué. Si

c’est déjà attribué, il affiche un message et demande la modification du

numéro saisi.

� L’agent saisit le Numéro d'ordre du courrier à classer,

� Le contrôleur vérifie si ce numéro d'ordre existe. S'il n'existe pas, il affiche un

message demandant la saisie d'un numéro d'ordre existant,

� l'agent saisit le code du classeur où sera classé le courrier

� L’agent valide le classement.

� Le contrôleur enregistre la date de classement du courrier.

Les lignes de vie suivantes décrivent le scénario :

- un acteur Agent,

- un objet courrier,

- un objet classeur

- un objet Classement

- une nouvelle instance de classement


55

Le scénario GCL_N1 donne le diagramme de séquence que

voici :

Figure 28. Diagramme de séquences de GCL_N1

La création d'un classeur est une option pour l'agent parce que

l'agent peut ne pas créer de classeur. Cela ne modifiera en rien le processus

normal. Le scénario de création d'un classeur conduit à une manipulation de

rayon. C'est dans ce scénario (création d'un classeur) que créer un rayon est une

option.

Création Classement

Nouveau Classement

ClassementExistant ClassementExistant

CourrierInexistant CourrierInexistant

Créer Classeur Créer classeur

CreateValiderValider

CodeClasseur Ok

CodeClasseur Ko

alt

Affichage NomClasseur

Classeur(Nom,...)

ReseachCodeClasseurSaisir CodeClasseur

Affichage courrier(N°Ordre, ...)

Courrier(N°Ordre,,...)

Reseach N°OrdreN°OrdreSaisir N°Ordre

ReseachN°ClassementSaisir N°Classement

ActiverActiver

retour à la saisie N°Classement

Agent <<Control>>

Controleur<<Boundary>>

Interface Classement<<Entity>>

Classeur<<Boundary>>

Interface d'accueil<<Entity>>

Courrier<<Entity>>

Classement

N°Classement Valide

N° Classement Invalide

alt

N°Ordre Ok

N° Ordre Ko

alt

[Création Classeur]opt

ClassementExistant ClassementExistant

CourrierInexistant CourrierInexistant

Créer Classeur Créer classeur

CreateValiderValider

Affichage NomClasseur

Classeur(Nom,...)

ReseachCodeClasseurSaisir CodeClasseur



Reseach N°OrdreN°OrdreSaisir N°Ordre

ReseachN°ClassementSaisir N°Classement

ActiverActiver


56

Le déroulement normal du scénario de création d'un classement

donne le diagramme de communication suivant :

Figure 29. Diagramme de communication de GCL_N1

Le cas d’utilisation "GérerTransmission" (GT) réalise des scénarios dont les

plus importants sont :

d. Scénario nominaux

� GT-N1 : Création Transmission � GT-N2 : Annulation Transmission

e. Scénario d’exception

� GT-E1 : non validation du courrier suite à la saisie d'un Numéro de courrier

inexistant.

� GT-E2 : non validation du courrier suite à la saisie d'un numéro de

transmission existant.

1: Activer2: Activer

5: Valider4: saisirCodeClasseur

3: saisir N°Ordre

2.1: SaisirN°classement

5.1: Valider4.1: CodeClasseur

3.1: N°Ordre

2.2: N°Classement

2.3: Reseach

5.2: Create

3.2: Reseach

4.2: Reseach<<Boundary>>

Interface Accueil

Agent

<<Boundary>>

Interface Classement

<<Control>>

Controleur

<<Entity>>

Classement

Nouveau classement

<<Entity>>

Courrier<<Entity>>

Classeur


57


Scénario : Enregistrement d'une transmission

� L’agent saisit le Numéro de Transmission.

� Le contrôleur vérifie si ce numéro de transmission n’a pas déjà été attribué. Si

c’est déjà attribué, il affiche un message et demande la modification du

numéro saisi.

� L’agent saisit le Numéro d'ordre du courrier à transmettre,

� Le contrôleur vérifie si ce numéro d'ordre existe. S'il n'existe pas, il affiche un

message demandant la saisie d'un numéro d'ordre existant,

� l'agent saisit le destinataire puis valide.

� Le contrôleur enregistre la date de transmission ainsi que les coordonnées de

l'utilisateur.


- un acteur Agent,

- un objet courrier,

- un objet Transmission

- une nouvelle instance de transmission


58

Le scénario GT_N1 se formalise dans le diagramme de séquence

comme suit :

Figure 30. Diagramme de séquence de GT_N1

Le déroulement normal du scénario de création d'une

transmission se représentera dans le diagramme de communication suivant :

Transmission Courrier

Enreg Date

ActiverActiver

Saisir N°Transmission N°Transmission Reseach

Saisir N°Ordre N°Ordre Reseach N°Ordre



Saisir Destinataire

Valider Valider

CourrierInexistantCourrierInexistant

N°TransExistantTransmissionExistant

Nouvelle Transmission

<<Entity>>

TransmissionAgent <<Boundary>>

Interface Transmission<<Control>>

Controleur<<Entity>>

Courrier<<Boundary>>

Interface d'accueil

N°Transmission Valide

N° Transmission Invalide

alt

N°Ordre Ok

N° Ordre Ko

alt

Create

Enreg Date

ActiverActiver

Saisir N°Transmission N°Transmission Reseach

Saisir N°Ordre N°Ordre Reseach N°Ordre



Saisir Destinataire

Valider Valider

CourrierInexistantCourrierInexistant

N°TransExistantTransmissionExistant

Create


59

Figure 31. Diagramme de communication de GT_N1

Le cas d’utilisation "GérerFeedback" (GF) réalise des scénarios dont les plus

importants sont :

f. Scénario nominaux

� GF-N1 : Création Feedback

g. Scénario d’exception

� GT-E1 : non validation du courrier suite à la saisie d'un Numéro de courrier

inexistant et non en attente de réponse.


Scénario : Enregistrement d'un Feedback

� L’agent saisit le Numéro du courrier qui attend une réponse,

� Le contrôleur vérifie si ce numéro d'ordre existe et attend une réponse. Si ce

n'est pas le cas, il affiche un message demandant la saisie d'un numéro

d'ordre en attente de réponse,

� L’agent saisit le Numéro d'ordre du courrier (FeedBack) puis valide,

� Le contrôleur enregistre le Numéro d'ordre de la réponse.

1: Activer2: Activer

4: Valider

2.1: SaisirTransmission

3: SaisirN°ordre4.1: Valider

3.1: N°Ordre

2.2: N°Transmission2.3: Reseach

4.2: Create


Interface Accueil

Agent

<<Boundary>>

Interface Transmission

<<Control>>

Controleur <<Entity>>

Transmission

Nouvelle transmission

<<Entity>>

Courrier


60


- un acteur Agent,

- un objet Liste des courriers Feedback,

- un objet FeedBack

Le scénario GT_N1 donne le diagramme de séquence suivant :

Figure 32. Diagramme de séquence de GF_N1

Le déroulement normal du scénario de validation d'une réponse

courrier donne le diagramme de communication suivant :

Feedback

NumOrdre Inexistant N°ordreKo

delite

Update

ActiverActiver

Saisir NumOrdreNumOrdre Rechercher NumOrdre

SaisirCourrier(Feedback)

Valider

Valider

Agent <<Control>>

Controleur<<Boundary>>

Interface Feedback<<Entity>>

ListeCourrierFeedback<<Boundary>>

Interface d'accueil<<Entity>>

Feedback

NumOrdre Valide

NumOrdre Invalide

alt

NumOrdre Inexistant N°ordreKo

delite

Update

ActiverActiver

Saisir NumOrdreNumOrdre Rechercher NumOrdre

SaisirCourrier(Feedback)

Valider

Valider


61

Figure 33. Diagramme de communication de GF_N1

2.3.2 Construction et validation des diagrammes d'états

D'après Pascal Roques, après la formalisation des scéanrios, la

connaissance de l’ensemble des interactions entre objets permet de se représenter

les règles de gestion dynamique du système. Il faut cependant se focaliser sur les

classes aux comportements les plus riches de manière à développer précisément

certaines de ces règles dynamiques.

Cette vue locale d’un objet, décrivant comment il réagit à des

événements en fonction de son état courant et passe dans un nouvel état, est

représentée graphiquement sous forme d’un diagramme d’états.

Il poursuit en disant qu'un état représente une situation durant la

vie d’un objet pendant laquelle :

� il satisfait une certaine condition ;

� il exécute une certaine activité ;

� ou bien il attend un certain événement.

Un objet passe par une succession d’états durant son existence.

Un état a une durée finie, variable selon la vie de l’objet, en particulier en fonction

des événements qui lui arrivent.

Franck Vallée nous dit qu'en UML, un événement spécifie qu’il

s’est passé quelque chose de significatif, localisé dans le temps et dans l’espace.

Suppression de l'instance sur la liste des courriers en attente de réponse

1: Activer

2: Activer

2.1: Saisir NumOrdre

3: SaisirFeedback

3.1: Valider

2.2: NumOrdre

3.2: Valider

3.3: Update

3.4: Delete


Interface Accueil

Agent

<<Boundary>>

Interface Feedback

<<Control>>

Controleur

<<Entity>>

Feedback

Courrier

<<Entity>>

ListeCourrierFeedback


62

UML propose de distinguer plusieurs sortes d’événements :

• la réception d’un signal envoyé par un autre objet, ou par un acteur. L’envoi

d’un signal est en général asynchrone ;

• l’appel d’une opération (call event) sur l’objet récepteur. L’événement

d’appel est en général synchrone ;

• le passage du temps (time event), qui se modélise en utilisant le mot-clé after

suivi d’une expression représentant une durée, décomptée à partir de

l’entrée dans l’état courant ;

• un changement dans la satisfaction d’une condition (change event). On

utilise alors le mot-clé when, suivi d’une expression booléenne.

L’événementde changement se produit lorsque la condition passe à vrai.

Il est alors question de se poser une question fondamentale; à savoir : Comment trouver les états d’une classe ?

Pascal Roques dit qu'il y a trois démarches complémentaires qui

peuvent être mises en œuvre; à savoir :

• la recherche intuitive qui repose sur l’expertise métier. Certains états

fondamentaux font partie du vocabulaire des experts du domaine et sont

identifiables a priori (par exemple : en vol et au sol pour un avion) ;

• l’étude des attributs et des associations de la classe peut donner des

indications précieuses : il faut cherchez des valeurs seuils d’attributs qui

modifient la dynamique, ou les comportements qui sont induits par l’existence

ou l’absence de certains liens ;

• une démarche systématique peut également être utilisée : classe par classe, il

faut cherchez le diagramme d’interaction le plus représentatif du

comportement des instances de cette classe, puis associez un état à chaque

intervalle entre événements émis ou reçus par une instance et placez les

transitions. Reproduire ensuite cette démarche avec tous les scénarios faisant

intervenir des instances de la classe, afin d’ajouter de nouvelles transitions ou

de nouveaux états. La difficulté principale consiste à trouver ensuite les

boucles dans le diagramme, afin de ne pas multiplier les états.


63

Il poursuit en disant, pour élaborer le diagramme d’états, il faut

utiliser une approche Incrémentale fondée sur les étapes suivantes :

• représentez d’abord la séquence d’états décrivant le comportement nominal

d’un objet, de sa naissance à sa mort, avec les transitions associées ;

• ajoutez progressivement les transitions correspondant aux comportements

alternatifs ;

• puis intégrez, de la même façon, celles concernant les comportements

d’erreur ;

• complétez en indiquant les effets sur les transitions et les activités dans les

états ;

• structurez en sous-états, si le diagramme est devenu trop complexe.

Sur base de ces critères, nous avons le diagramme d'état

transitions de l'objet Courrier (cas des courriers entrants):

Figure 34. Diagramme d'Etat-transition de l'objet Courrier

- L'état Reçu : est l'état initial d'un courrier à sa réception. Mais cet état n'est

pas formalisable parce qu'étant un état abstrait dans le système d'étude.

- L'état Enregistré : le courrier est enregistré quand il passe par la validation.

- L'état Annoté : l'état "Annoté" est un état abstrait. Il montre le traitement

effectué par le Directeur des Services Administratifs. Cet état est formalisable

mais non étudié dans notre système.

- La transmition ou le classement d'un courrier sont les états finals de ce

diagramme.


64

Pascal Roques afirme qu'àprès la contruction du diagramme

d'états il faut le valider avec les diagrammes d’interactions en étudiant la

conplémentarité entre les diagrammes d'interaction (séquence et communication)

et les diagrammes d'états.

Cette complémentarité est fondamentale. En effet, les diagrammes

d’états apportent précision et exhaustivité, et permettent de valider et de compléter

les diagrammes d’interactions. Ils peuvent également inciter à créer de nouveaux

diagrammes d’interactions pour compléter ceux qui existent déjà. Il faut toutefois

vérifier que les diagrammes d’états des classes impliquées dans les diagrammes

d’interactions prennent bien en compte tous les scénarios décrits, et qui plus est de

façon correcte.

2.3.3 Confrontation des modèles statique et dynamique

Après avoir eu les relations diverses qui existent entre les

principaux concepts du modèle statique (objet, classe, association, attribut et

opération) et les principaux concepts dynamiques (message, événement, état et

activité), Vallée nous demande de synthétiser les correspondances les plus

importantes; à savoir :

� un message peut être un appel d’opération sur un objet (le récepteur) par un autre objet (l’émetteur) ;

� un événement ou un effet sur une transition peuvent correspondre à l’appel d’une opération ;

� une activité dans un état peut concerner l’exécution d’une opération complexe ou d’une succession d’opérations ;

� un diagramme d’interactions met en jeu des objets (ou des rôles) ; � une opération peut être décrite par un diagramme d’interaction ou

d’activité;

� une condition de garde et un change event peuvent consulter des attributs ou des liens statiques ;

� un effet sur une transition peut manipuler des attributs ou des liens statiques ;

� le paramètre d’un message peut être un attribut ou un objet entier.

Cette confrontation nous permet de définir certains attributs et/ou

opérations qui n'ont pas été trouvé lors de l'élaboration du modèle statique afin

d'avoir un diagramme de classes complété.


65

En rapport avec ces principes, nous pouvons retenir les points suivant :

Figure 35. Diagramme de confrontation

De la confrontation des deux modèles de GESTCOUR nous remarquons que les

états Courrier réorienté et courrier transmis correspondent à une opération de

création d'une transmission dans le modèle statique. L'état courrier enregistré

correspond à l'opération de création d'un courrier dans la table Courrier. D'où,

notre diagramme de classes obtenu au niveau du modèle statique est complété.

Concerne

Modèle dynamique

Modèle statique

1..1 0..* 1..1 0..*appartient

COURRIER

---


: : :

+ Créer ()

COURRIERENTRANT

--


: :

COURRIERSORTANT

- Destinataire :

TYPECOURRIER

--

N°TypeType

: :

++

CréerType ()ModifierType ()

TRANSMISSION

-----


: : : : :

+ CréerTransmission ()

Traiter

Transmission

Si annotation = réorienté

Si annotation = SuspendSi annotation = Classé

TraiterEnregistrerCourrier reçu Courrier enregistré Courrier annoté

Courrier transféré

Courrier en suspendCourrier à classer Courrier réorienté


66

2.4. CONCEPTION GENERIQUE

D'après Roques, la conception générique consiste à développer la

solution qui répond aux spécifications techniques obtenues pendant la capture des

besoins techniques. Elle est générique parcequ'elle est entièrement indépendante

des aspects fonctionnels spécifiés en branche gauche.

Dans la conception générique il faut développer :

- la vue logique du système en organisant le modèle logique tout en étudiant les

contraintes de réutilisation.

- la vue d'exploitation en organisant les composants du système.

- La vue de la configuration logicielle

2.4.1 Modèle logique de conception technique

Le modèle logique de conception technique est un modèle qui

organise les classes par packages qui représentent les frameworks développés pour

résoudre les problèmes purement techniques. Le modèle logique est organisé

suivant les dépendances qui s'établissent entre frameworks techniques.

Un Framework est un réseau de classes qui collaborent à la

réalisation d'une responsabilité qui dépasse celle de chacune des classes qui y

participent [UML-UG 99].

2.4.2 Modèle d'exploitation de conception technique

Pascal Roques dit que pour établir un modèle d'exploitation, nous

avons besoin de distinguer deux niveaux de composant : les composants

d'exploitation représentés au niveau de la capture des besoins techniques, et les

composants qui servent à la configuration logicielle :

• "executable" représente un exécutable capable de fonctionner sur une des

machines du système physique. Cette caractéristique en fait un composant

d'exploitation ;

• "library" correspond à une librairie statique ou dynamique. Seules les

librairies dynamiques peuvent être assimilées à un composant d'exploitation

dans la mesure où elles sont explicitement installées par l'ingénieur

d'exploitation

La vue des composants d'exploitation vient compléter la

conception générique. Elle permet d'identifier les premiers éléments du système


67

logiciel et définit les règles de déploiement et d'intégration des différentes

composantes.

La vue d'exploitation précise par exemple l'ordre dans lequel

l'exploitant (acteur technique) doit initialiser les applications en fonction de leurs

dépendances réciproques.

GESTCOUR étant un système qui ne présente qu'une seule

application, le devéloppement de ces différentes vues n'est pas nécessaire.

2.4.3 Modèle de configuration logicielle de la conception technique

Jacobson, cité par Roques, dit qu'En UML, un sous-système

correspond à un regroupement d'éléments de modélisation dont le but est de

fournir une même unité de comportement au sein du système.

Un sous-système se caractérise donc par un procédé de

fabrication indépendant. Un sous-système de caractérise en outre par un numéro

de version qui fixe son état d'évolution au sein de la construction globale du

système.

Le modèle de configuration logicielle n'a d'intérêt que pour des

systèmes conséquents. Lorsqu'il s'agit de réaliser des applications qui, à terme, ne

produisent qu'un ou deux composants de déploiement, l'expression d'un modèle

de configuration logicielle est facultative. D'où, pour GESTCOUR ce modèle ne

sera pas réalisé.

2.4.4 Développement d'un prototype

Un prototype est un modèle. Le développement d'un prototype

doit conduire à répondre aux fonctionnalités techniques demandées par le

système. Pour ce faire, il faut répondre à la question suivante :" Que mettre dans

mon prototype ?"

Le prototype de GESTCOUR doit au moins valider :

- le mécanisme CRUD des objets (Créate, Retrieve, Update, Delete); - l'intégrité des données; - la synchronisation entre Crystal Report et l'application.


68

CHAP III: CONCEPTION OBJET

3.1. CONCEPTION PRELIMINAIRE

La conception préliminaire est l’étape la plus délicate du

processus 2TUP. Elle réalise la fusion des études fonctionnelles et techniques.

3.1.1 Conception du modèle de déploiement

Le déploiement d’une solution client /serveur se traduit sur la

définition des postes de travail. Le poste de travail représente un ou plusieurs

acteurs pouvant être localisés sur une machine d’un type particulier et remplissant

une fonction identifiée dans l’entreprise.

Un poste de travail ne représente pas toujours une machine

physique, mais peut consister en plusieurs machines, à condition qu'elles donnent

lieu au même type de déploiement. Les postes de travail de GESTCOUR seront

repartis de la manière suivante :

Figure 36. Modèle de déploiement détallé de GESTCOUR

Les postes de travail s'articule autour du serveur GESTCOUR. Un serveur de

messagerie permet de recevoir/envoyer des courriers en passant par le Web. Le

LAN

Node_9

DMZ

<<Serveur>>

Messagerie<<Serveur>>

Web

<<Serveur>>

GESTCOURImprimante

<<Poste>>

Départemental

<<Poste>>

Secrétaire

<<Poste>>

Administration

<<Poste>>

Classement

<<Serveur>>

Proxy


69

serveur de messagerie et le serveur web sont dans la zone de démilitarisée. Il sont

accessible par tout le monde tandis que la partie du bas n'est accéssible que par

les utilisateurs de GESTCOUR.

3.1.2 Elaboration du modèle d'exploitation

Le modèle d'exploitation commence à la phase de la conception

générique. A partir du modèle de déploiement obtenu, il est possible de le

compléter en fonction des machines et des postes de travail, tout en intégrant les

besoins exprimés en analyse. Le modèle d'exploitation va donc définir les

applications installées sur les postes de travail, les composants métier déployés sur

les serveurs et les instances de bases de données implantées sur des serveurs afin

d'optimiser la distribution et éventuellement énumérer les interfaces utilisateurs .

Dans le cadre de GESTCOUR, nous avons le diagramme

d'exploitation suivant :

Figure 37. Modèle d'exploitation GESTCOUR

Nous avons repartis les différents composants de GESTCOUR en fonction des

fonctions de chaque utilisateur tout en respectant la définition des postes (le

diagramme de déploiement détaillé) déjà établie.

LAN

LANLAN

LAN

LAN

LAN

LANLAN

Node_9

DMZ

<<Serveur>>GESTCOUR

<<BD>>

GESTCOUR

Imprimante

<<Application>>

Imprimante

<<Poste>>Classement

<<Application>>

Classement, Mozilla

<<Poste>>Administration

<<Application>>

Courrier, Mozilla

<<Poste>>Secrétaire

<<Application>>

Feedback, Mozilla

<<Poste>>Départemental

<<Application>>

Courrier, Mozilla

<<Serveur>>Proxy

<<application>>

Zone Alarm, Anti-Spay, Av ast

<<Serveur>>Web

<<application>>

Application

<<Serveur>>Messagerie

<<Application>>

OutLoook


70

Ensuite tous les packages établis au niveau du découpage en

catégorie du système deviennent des composants métier du modèle d'exploitation.

Une première ébauche des interfaces peut être définie en termes de regroupement

de responsabilité.

Figure 38. Consolidation de l'application GESTCOUR

Ce schéma est illustré dans le tableau suivant : Composant Interface Description des responsabilités

ICourrier Création, modification, transmission des instances des entités courrier et transmission

Courrier IFeedBack

Validation des courriers ayant reçus de réponse de l'entité Feedback, relance des courriers en attente de réponse

Classement IClassement

Création, modification d'un classement de l'entité Classement, d'un classeur de l'entité Classeur. Modification du placement d'un classeur dans un rayon.

Agent IAgent Création, suppression agent de l'entité Agent, attribution d'un compte. Création, suppression des comptes de l'entité Compte

Tableau 4 : Tableau des composants

3.1.3 Développement du modèle logique de conception

Le développement du modèle logique de conception développe

les classes nécessaires au codage. Une catégorie de conception est une catégorie

qui organise des classes techniques et contribue à la réutilisation et à

IClassement

ICourrier

IAgent

IFeedback

<<BD>>

GESTCOUR

<<Application>>

Agent

<<Application>>

Courrier

<<Application>>

Classement


71

l'optimisation d'un système à développer. C'est à ce niveau que le découpage du

système en sous-système peut se réaliser.

Il s'agit d'étudier chaque package (composant) indépendamment

des autres, par rapport aux 5 couches logiques.

Par exemple : les composants de GESTCOUR aurons, pour la

couche présentation, les catégories suivantes :

Figure 39. Catégories de la couche présentation

Le composant "Courrier" a deux catégories dans la couche présentation : la

catégorie Courrier et la catégorie transmission.

3.1.4 Création des interfaces des catégories

Les interfaces de catégories se construisent à partir des interfaces

déjà identifiées des composants d'exploitation. Leur définition nécessite d'être

précisée et doit prendre en compte les opérations identifiées dans le modèle

d'analyse. Ces opérations sont reparties sur les couches application, métier ou

accès aux données en fonction de leur spécialité.

<<layer>>

Présentation

<<catégorie>>

Courrier

<<catégorie>>

Transmission

<<catégorie>>

Classement

<<catégorie>>

Agent


72

Le tableau ci-dessous donne quelques opérations d'analyse de GESTCOUR

Opération d'analyse

Description Positionnement

AttribuerCOMPTE

Créer un compte pour un agent, ce qui déclenche la vérification de l'existence de cet agent.

C'est un service applicatif du composant Agent qui entre dans la définition de l'interface IAgent.

VérifierCourrier Vérification de l'existence du courrier. Cette opération est déclenchée par la saisie du n°ordre du courrier.

C'est un service applicatif du composant Courrier qui en entre en compte dans la définition de l'interface ICourrier.

Tableau 5 : Opération d'analyse

Les opérations de la couche Métier du composant Classement est

: la validation du classement, la validation (création) du classeur et la validation du

rayon.

Pour la couche Applicative, nous avons les opérations suivantes :

la recherche du courrier, la recherche du classeur, la sélection du courrier, la

selection du classeur, la recherche du rayon et la selection du rayon.

Figure 40. Vue des commandes de la couche Applicative :: Classement

3.1.5 Mise au point de la présentation des applications

La mise au point de la présentation des applications est l'étape qui

structure la présentation des applications ainsi que des interfaces qui permettent

aux différentes catégories de communiquer entre elles. Elle donne une première

maquette des IHM à élaborer.

Commandes de la couche Applicative sur

l'interface du composant Classement<<Interface>>

IClassement

<Interface>IClassementCmdRechercherCourrie

CmdRechercherClasseur

CmdSelectionnerCourrier

CmdSelectionnerClasseur

CmdSelectionnerRayonCmdRechercherRayon

ComposantClassement


73

GESTCOUR aura donc, pour une première maquette, les

interfaces suivants : Courrier, Transmission, Classement et Agent.

3.1.6 Organisation de la configuration logicielle

La conception préliminaire s'achève par la définition des unités de

fabrication du logiciel.

Organiser la configuration logicielle revient à consolider le

modèle logique avec les réutilisations de code détectées et de compléter la

configuration logicielle. Chaque catégorie se transforme en un sous-système de

configuration logicielle ou Module.

Pour GESTCOUR, nous aurons les sous-systèmes suivants :

- un sous-système principal de démarrage de l'application (Submain)

- un sous-système de connexion (ouverture et fermeture de (s) table (s)) à la

base de données

- un sous-système de gestion de FeedBack,

3.2. CONCEPTION DETAILLEE

Pascal Roques et Franck Vallée définissent la conception

détaillée comme étant une activité qui s’inscrit dans l’organisation définie par la

conception préliminaire.

Ils poursuivent en disant que le modèle logique y est

particulièrement important dans la mesure où c’est en conception détaillée que

l’on génère le plus gros volume d’informations.

Il est ainsi possible de confier les catégories à des personnes

différentes, qui pourront travailler indépendamment les unes des autres. La

conception détaillée s’appuie donc sur les catégories de conception organisées à la

fois suivant les frameworks techniques et les regroupements propres au métier.

Nous devons alors construire les classes, les vues d’IHM, les

interfaces, les tables et les méthodes qui vont donner une image « prête à coder »

de la solution. Et en dernier lieu, nous devons préciser le contenu des sous-

systèmes de manière à compléter la configuration logicielle. Toutes les questions

relatives à l’agencement et aux détails de la solution doivent être modélisées ainsi

que les interrogations restantes concernent la bonne utilisation des langages et des

outils de développement.


74

Le niveau d’abstraction visé par l’étape de conception détaillée est

d’avoir une idée la plus précise possible pour la fabrication et l’assemblage des

sous-systèmes de configuration logicielle. La conception détaillée précède la phase

de codage.

3.2.1 Conception détaillée du modèle logique

Le micro-processus de conception du modèle logique concerne la

définition des classes à implémenter afin de pouvoir produire un diagramme de

classes détaillées.

La conception détaillée est une activité centré sur le modèle

logique qui combine les diagrammes UML suivant :

� principalement les diagrammes de classes pour préciser la structure des

classes de développement,

� les diagrammes d'interactions pour préciser les communications entre

objets,

� et les diagrammes d'activités pour exprimer les algorithmes des méthodes.

Le micro-processus est une itération des étapes suivantes :

� la conception des classes consiste à transformer des concepts provenant de

l’analyse, tels que les métaclasses ou les classes à états parallèles, en

techniques disponibles avec les langages et les outils de développement.

� La conception des associations définit la façon d’exploiter chaque

association et les techniques qui seront employées dans le codage.

� La conception des attributs nécessite essentiellement d’identifier les

structures de données, les itérations et d’autres types complexes permettant

de représenter les attributs d’analyse avec le langage utilisé.

� La conception des opérations permet de déterminer le contenu des

méthodes complexes et d’identifier en cascade de nouvelles classes et

opérations dans la catégorie.

� La Validation du modèle. A la sortie de ce cycle le modèle donne l’image

prête à coder de ses composants de configuration logicielle.

Appliquer ces phases à GESTCOUR, nous avons le diagramme de

classes détaillée suivant :


75

Figure 41. Diagramme de classes détaillées

rangé1..10..*

1..1 0..*

1..1

0..*

0..*

1..1

Placé0..* 1..*

Possède

appartient

Concerne enregistre

RAYON

+ N°Rayon : Byte

+ CréerRayon () : void

CLASSEUR

++


: String: String

+--

CréerClasseur ()GetN°Rayon ()LetN°Rayon ()

: Object: Byte: Byte

COMPTE

++

LogInPassWord

: String: String

+ CréerCOMPTE () : Object

AGENT

++++


: String: String: String: String

+--++

CréerAGENT ()GetLogIn ()LetLogIn ()GetPassword ()LetPassword ()

: Object: String: String: String: String

COURRIER

+++


: String: String: String

+--

CréerCourrier ()GetType ()LetType ()

: Object: String: String

COURRIERENTRANT

++


: String: Date

COURRIERSORTANT

+ Destinataire : String

TYPECOURRIER

++

N°TypeType

: String: String

+ CréerType () : Object

TRANSMISSION

+++++


: String: Date: Date: String: String

+--

CréerTransmission ()GetN°Ordre ()LetN°Ordre ()


CLASSEMENT

--


: String: Date

+++++

CréerClassement ()GetN°Ordre ()LetN°Ordre ()GetCodeClasseur ()LetCodeClasseur ()

: Object: String: String: String: String

FEEDBACK

+++++


: String: String: Date: Date: String

+--

CréerFeedback ()GetN°Ordre ()LetN°Ordre ()



76

Etant dans le modèle logique, chaque table du schéma ci-haut

sera reparti selon les couches logiques.

Une classe gère ainsi les activités et les transitions attachées à

l’état qu’elle représente. Voici quelques uns des diagrammes Etats que nous avons

conçus :

Figure 42. Classes Courrier et états

Les classes CourrierEntrant et CourrierSortant qui se généralise dans la classe

Courrier délèguent la gestion de leurs états aux interfaces CourrierEntrant et

CourrierSortant et leurs implémentations aux états de création ci-haut.

EtatCréationCourrierEntrant

+++++

N°OrdreNumRéfObjetEmetteurDateReception

: String: String: String: String: Date

+++++++++++++

CreateCourrier ()GetType ()LetType ()GetN°Ordre ()LetN°Ordre ()GetNumRéf ()LetNumRéf ()GetObjet ()LetObjet ()GetEmetteur ()LetEmetteur ()GetDateReception ()LetDateReception ()

: Object: String: String: String: String: String: String: String: String: String: String: Date: Date

COURRIER

+++


: String: String: String

+--

<<Implement>> CréerCourrier ()GetType ()LetType ()

: Object: Typecourrier: Typecourrier

COURRIERSORTANT

+ Destinataire : String

COURRIERENTRANT

++


: String: Date

Interface_COURRIERSORTANT

+ CréerCourrier () : Object

Interface_COURRIERENTRANT

+ CréerCourrier () : Object

EtatCréationCourrierSortant

++++

N°OrdreNumRéfObjetDestinataire

: String: String: String: String

+++++++++++

CreateCourrier ()GetType ()LetType ()GetN°Ordre ()LetN°Ordre ()GetNumRéf ()LetNumRéf ()GetObjet ()LetObjet ()GetDestinataire ()LetDestinataire ()

: Object: String: String: String: String: String: String: String: String: String: String


77

La classe classement délègue la gestion de ses états à l’interface classement et son

implémentation.

Figure 43. Classe Classement et états

La classe Transmission délègue la gestion de ses états à l’interface Transmission et

son implémentation.

Figure 44. classe Transmission et ses états

Les états de la classe Feedback délége ses états à l’interface Feedback et son

implémentation.

EtatCréation

++


: String: Date

+++++++++

CreateClassement ()GetN°Ordre ()LetN°Ordre ()GetCodeClasseur ()LetCCodelasseur ()GetN°Classement ()LetN°Classement ()GetDateClassement ()LetDateClassement ()

: Object: String: String: String: String: String: String: String: String

CLASSEMENT

++


: String: Date

+----

<<Implement>> CréerClassement ()GetN°Ordre ()LetN°Ordre ()GetCodeClasseur ()LetCodeClasseur ()

Interface_CLASSEMENT

+ CréerClassement () : Object

EtatCréation

+++++



+++++++++++++

CreateTransmission ()GetN°Ordre ()LetN°Ordre ()GetN°Transmission ()LetN°Transmission ()GetDateTransmission ()LetDateTransmission ()GetDateRéception ()LetDateRéceptionnt ()GetOrientation ()LetOrientation ()GetObservation ()LetObservation ()

: Object: String: String: String: String: Date: Date: Date: Date: String: String: String: String

TRANSMISSION

+++++



+--

<<Implement>> CréerTransmission ()GetN°Ordre ()LetN°Ordre ()

Interface_TRANSMISSION

+ CréerTransmission () : Object


78

Figure 45. classe Feedback et ses états

A partir de cette décomposition, nous avons les Etats qui seront placés dans la

couche présentation (interface), la couche métier (implémentation) et une idée sur

la couche persistance.

3.2.2 Conception de la couche présentation

D'après Vallée, la première étape de conception d'une IHM

concerne la définition visuelle des fênetres ou des pages. L'existence d'un modèle

objet d'analyse permet d'influencer cette conception : à partir d'un diagramme de

classes, un générateur de code pourait générer des fênetres ou des pages pour

l'affichage et la saisie de chaque élément du modèle.

� Une fenêtre ou plusieurs pages pour chaque classe afin d'en éditer les

instances : création, modification des attributs et des relations, simple

consultation et suppression;

� Une fenêtre ou plusieurs pages pour certaines associations complexes afin d'en

éditer les liens.

Ainsi donc, dans notre cas d’étude, selon les Classes Etats

interfaces trouvés grace à Power AMC, nous avons les fenêtres à réaliser dans le

langage choisi (Visual Basic 6.0). Notons cependant qu'il faut parfois doubler les

interfaces car l'affichage (visualisation) et la saisie (création, modification,

suppression) utilisent des techniques différentes.

FEEDBACK

+++++



+--

<<Implement>> CréerFeedback ()GetN°Ordre ()LetN°Ordre ()

EtatCréerFEEDBACK

+++++



+++++++++++

ValiderFeedback ()GetN°Ordre ()LetN°Ordre ()GetNumFeedback ()LetNumFeedback ()GetDateTransmission ()LetDatetransmission ()GetDateRéponse ()LetDateRéponse ()GetNumCourrierreponse ()LetNumCourrierreponse ()

: void: String: String: String: String: Date: Date: Date: Date: String: String

Interface_FEEDBACK

+ CréerFeedback () : void


79

Fenêtre CourrierEntrant

Figure 46. IHM de la classe interface CourrierEntrant

Fenêtre Classement

Figure 47. IHM de la classe interface Classement

Interface_COURRIERENTRANT

+ CréerCourrier () : void

Interface_CLASSEMENT

+ CréerClassement () : Void


80

Fenêtre Feedback

Figure 48. IHM de la classe interface Feedback

3.2.3 Conception de la couche persistance

La réalisation d’un stockage des instances varie suivant le mode

de stockage retenu. Dans tous les cas, la réalisation d’un modèle objet facilite la

maintenance des données stockées.

D'après Pascal Roques, il existe aujourd’hui plusieurs modes de

stockage possibles.

- Le système de fichiers est le moyen le plus rudimentaire de stockage. Cependant, il ne permet que de lire ou d’écrire une instance par des moyens externes à l’application et il n’a aucune capacité à administrer ou à établir des requêtes complexes sur les données.

- La base de données relationnelle ou SGBDR est un moyen déjà plus

sophistiqué. Il existe aujourd’hui une large gamme de SGBDR répondant à des

Interface_FEEDBACK

+ CréerFeedback () : void


81

besoins de volume, de distribution et d’exploitation différents. Le SGBDR permet d’administrer les données et d’y accéder par des requêtes complexes.

- La base de données objet ou SGBDO constitue la méthode la plus élaborée de

toutes. Cette technique élude la conception d’un stockage des données puisqu’elle permet de stocker et d’administrer directement des instances de classe.

- La base de données XML ou SGBDX est un concept émergeant qui répond au

besoin croissant de stocker des documents XML sans risque d’altération de ces derniers.

Pascal Roques dit que la conception du stockage des données

consiste à étudier sous quelle forme les instances sont sauvegardées sur un support

physique.

Pour notre cas d’étude, nous retenons le mode de stockage le plus

répondue; le SGBDR.

La réalisation d'un modèle relationnelle ne sera pas directe vu

que les modèles développés dans la conception sont des modèles objets d'où il

faut utiliser des principes de rapprochement objet-relationnel.

Le passage du Modèle Objet au Modèle Relationnel

L’utilisation d’un SGBDR impose un changement de

représentation entre la structure des classes et la structure des données

relationnelles; les deux structures ayant des analogies, des équivalences [Blaha

97].

Une classe définit une structure de données à laquelle souscrivent

des instances; elle correspond donc à une table du modèle relationnel : chaque

attribut donne lieu à une colonne, chaque instance stocke ses données dans une

ligne et son OID sert de clé primaire. Selon le type d'association il y a création de

(s) colonne (s) (étrangères ) dans certaines relations, fusion de certaines classes en

une table (relation).

Certains attributs de type complexe ne correspondent à aucun des

types de SQL ; on rencontre fréquemment ce cas pour les attributs représentant

une structure de données. Un type complexe peut être conçu ;

� soit avec plusieurs colonnes, chacune correspondant à un champ de la

structure ;

� soit avec une table spécifique dotée d’une clé étrangère pour relier les

instances aux valeurs de leur attribut complexe.


82

UML définit spécifiquement un stéréotype table pour représenter

la table d’un schéma relationnel.

En appliquant les règles de transformation à GESTCOUR, nous

avons les relations suivantes :

La conception du stockage des classes Courrier, CourrierEntrant

et CourrierSortant en rapport avec la régle d'héritage définit par Pierre Alain Muller

ainsi que pour tous les autres types d'associations et de multiplicités des classes,

nous donne le code SQL suivant :

CREATE TABLE TYPECOURRIER (N°Type String, Type String NOT NULL)

PRIMARY KEY N°Type;

CREATE TABLE COURRIER (N°Ordre String, NumRéf String NOT NULL, Objet

StringNOT NULL, N°Type String)

PRIMARY KEY N°Ordre

FOREING KEY N°Type REFERENCES TYPECOURRIER;

CREATE TABLE COURRIERENTRANT(N°Ordre String, Expéditeur String NOT NULL,

DateRéception Date)


FOREING KEY N°Ordre REFERENCES COURRIER;

CREATE TABLE COURRIERSORTANT(N°Ordre String, Destinataire String NOT NULL)



CREATE TABLE TRANSMISSION (N°Transmission String, DateTransmission Date NOT

NULL, DateRéception Date NOT NULL, Orientation String, Observation String, N°Ordre

String)

PRIMARY KEY N°Transmission


CREATE TABLE CLASSEUR (CodeClasseur String, Classeur String NOT NULL,, N°Rayon

Byte)

PRIMARY KEY CodeClasseur

FOREING KEY N°Rayon REFERENCES RAYON;

CREATE TABLE RAYON (N°Rayon Byte) PRIMARY KEY;

CREATE TABLE CLASSEMENT (N°Classement String, N°Ordre String, CodeClasseur

String, DateClassement Date)

PRIMARY KEY (N°Ordre, CodeClasseur)

FOREING KEY N°Ordre REFERENCES COURRIER

FOREING KEY CodeClasseur REFERENCES CLASSEUR;


83

CREATE TABLE AGENT (Matricule String, Nom String, Postnom String, Adresse String,

LogIn String, Password String )

PRIMARY KEY Matricule;

3.2.4 Conception de la couche applicative

D'après Pascal Roques le rôle de la couche de l’application est de

piloter les processus d’interactions entre l’utilisateur et le système. Il s’agit

généralement de mettre en oeuvre toutes les règles nécessaires au maintien d’une

application cohérente et à l’optimisation des échanges client/serveur et/ou des

requêtes http.

D'une manière précise, les mécanismes d’une application assurent :

� L’existence de différentes fenêtres ou pages synchronisées sur les mêmes

données ;

� La cohérence entre les objets distribués et les multiples façons de les

représenter au travers des IHM ;

� L’optimisation des chargements pour un déploiement en client léger ou sur

le poste client pour un déploiement client/serveur ;

� La mise en œuvre des concepts applicatifs : typiquement les sorties de

rapports sur imprimante.

Le diagramme de séquence du scénario de création d'un

classement résume les rôles et responsabilités des différents objets intervenant

dans la création de l'objet Classement :

Dans la couche présentation :

� l'interface transforme les événements de l'utilisateur en action, elle restitue

par ailleurs les éléments du courrier et du classeur.

� Le contrôleur centralise l'action déclenchée depuis l'IHM, il vérifie si toutes

les règles sont respectés (Format des données à enregistrer, ….) et ensuite il

crée la commande correspondante à l'action qui est dans notre cas la

demande de création d'un classement et la place en file d'exécution auprès

de l'invocateur applicatif.

Dans la couche métier :

� l'invocateur exécute la commande de création d'un classement.

� Il restitue la réponse au contrôleur qui l'envoi à l'interface.


84

Ces différents états donnent des algorithmes. Le diagramme

d'activité par couloir de responsabilité formalise le mieux ce type d'algorithme. Il

sépare clairement les responsabilités et l'imbrication des déclenchements entre les

commandes applicatives.

Voici un exemple illustrant les responsabilités et l'inbrications des

déclenchements entre les commandes applicatives du cas de création d'un

classement.

Figure 49. Algorithme de création d'un classement.

Le diagramme d'activité par couloir de responsabilité de la création d'un

classement peut s'étendre jusqu'à une commande qui permet d'annuler un

classement lors de la création.

3.2.5 Conception de la couche métier Distribuée

Pascal Roques dit que la conception de la couche Métier consiste

à identifier les objets entités et sessions qu'il convient de développer au vu des

classes et des opérations métier à distribuer. Le concept d'objets distribués pose

également le problème de la distribution des liens d'un ensemble d'objets. Pour

cela deux techniques s'opposent :

� soit les objets sont distribués unitairement, et la demande d'un objet lié ou

de sa référence déclenche une nouvelle demande de transaction. Cette

pratique convient bien à l'édition d'objets métier.

Commande vérifierCourrier

Commande Ouvrir/Fermer Editeur

Commande vérifierClasseur

Commande Valider Classement

ValiderClassement

SaisirCodeClasseur

Decision

SaisirN°Ordre

Test

OuvrirIHMClassement

FermerIHMClassement

Test4SaisirAnnotation


85

� Soit un ensemble complet d'objets liés est préalablement chargé dans le

contexte mémoire de la couche présentation. Cette technique s'utilise de

préférence pour réaliser la présentation des éléments composites.

La distribution du métier nous pousse à étudier quel type

d'architecture C/S nous devons choisir pour GESTCOUR afin de mieux gérer les

transactions entre le client et le serveur.

Les 4 modèles de repartition d'une architecture client/serveur sont

:

- C/S de présentation : c'est dit d'un système qui utilise la présentation au

niveau du client, et le code applicatif ainsi que les données sur le Serveur,

- C/S de données : c'est dit d'un système qui utilise la présentation et le code

applicatif au niveau du client et au niveau du serveur il n'y a que les donnée,

- C/S de procédures : cela est dit d'un système qui utilise la présentation et une

partie du code applicatif au niveau Client et le niveau Serveur utilise l'autre

partie du code applicatif et les données

- C/S Système reparti : c'est un système qui utilise la présentation, une partie du

code applicatif et une partie des données au niveau Client et au niveau

Serveur il utilise l'autre partie du code applicatif et toutes les données

Figure 50. Architecture Client/Serveur

Etant donné que GESTCOUR ne sera utilisé que par un seul

département , nous optons pour le Client/Serveur de données. Ainsi tous les

utilisateurs du système se partegérons une même base de données.


86

CONCLUSION GENERALE

La gestion des courriers au sein du Département des Services

Administratifs Sud (DSA/S) posse souvent des problème de pertes de données suite

au manque de classement, de transmission, de traitement des courriers reçus, de

suivi,…

Face cette réalité, nous avons utilisé l'analyse du système afin de

voir dans quelle mesure l'outil informatique peut porter une solution à ce

problème. De cette analyse métier, nous avons aboutit à la réalisation d'une

application de gestion des courriers.

Cette application permet d'enregistrer les courriers tant émis que

reçus, il permet d'assurer le suivi des courriers en attente de réponse (feedback) ou

en suspend par un système de rapppel avant l'échéance. Il enregistre aussi la

transmission des courriers ainsi que leur classement et la recherche est aussi

possible. Cette application est utilisé sous une architecture Client/Serveur des

données; seulles les données sont partagées entre les utilisateurs du système

(Départemental, Secrétaire, Attaché Bureau D'administration, Attaché au bureau

d'archivage).

Dans le cas où le système devrait être utilisé par toute la

GECAMINES, la meilleur solution serait un système client/serveur réparti. Ainsi

chaque niveau aura à traiter et stocker ses données à sont niveau quitte à

consullter le serveur pour appel des données qui ne sont pas dans son domaine

d'action et selon les responsabilités (Exemple d'une demande de consultation des

courriers d'un autre département).

Pour un tel système, la dématérialisation totale du courrier peut

être une solution envisagaeable. La GECAMINES pourait utilisé une solution

simple et puissante, adaptée à la gestion des courriers. Destiné aussi bien aux

collectivités, administrations et grandes entreprises ce logiciel s’adapterait

également aux besoins des PME.

Grâce à une interface très intuitive accessible sur chaque poste de

l'entreprise, ce logiciel prmettrait non seulement le suivi chrono, mais gèrerait

également le classement des courriers par département et de la correspondance

générée par la hiérarchie

Élaboré en mode client-serveur ce logiciel fonctionnerait sous

Windows 95, 98, 2000, NT, XP et Vista. Construit sur une base de données, il


87

serait possible d’effectuer des requêtes SQL, qui s’ajouteraient à celles existantes et

permetrait de personnaliser les interrogations aux besoins spécifiques de chaque

département.

Le logiciel gérerait la sécurité en s'appuyant entièrement sur la

sécurité du serveur utilisé (2003, 2000, NT, Novell ou autre…). Les permissions

sont celles déjà mises en place par l'administrateur ; si un utilisateur essaie

d’accéder à un document interdit, une fenêtre apparaîtra lui indiquant qu’il ne

possède pas les permissions suffisantes. A chaque utilisateur de l’application il est

associé un profil : Administrateur, Superviseur, Utilisateur, consultation.

Les Fonctionnalités qu'offrirait le logiciel sont : - Compteur automatique, avec personnalisation de ce dernier

- Bouton Export vers Excel dans les courriers entrants et sortants.

- Possibilité de protéger une table attachée par mot de passe

- Possibilité de crypter une base de données

- Routage par mail de la pièce jointe, si le document arrivé est scanné il est

distribué automatiquement

- Filtre dans Gestion des courriers entrants

- Gestion des modèles de documents

- Gestion des lieux avec plan d’accès

- Sécurité avec gestion des profils d’utilisateur

Il rend les documents accessibles à distance, en utilisant des

technologies très novatrices basées sur la notion de client léger, tout en utilisant

l’infrastructure Internet (Avec une adresse IP fixe) vous pourrez accéder à tous vos

documents, quelque soit l’endroit ou vous vous trouvez.

Au lieu de faire une copie papier du document arrivé et de la

placer dans la case courrier de chaque utilisateur, il est possible de scanner ce

courrier et de l’envoyer par mail soit à une liste de diffusion, soit à des personnes

de votre organisation. Le routage par messagerie est également disponible depuis

le départ, ainsi vous pouvez communiquer aux différents collaborateurs, la

réponse faite à un courrier.


88

BIBLIOGRAPHIE 1. Pierre Alain Muller, Modélisation objet avec UML, Eyrolles, 1999. 2. Ivar Jacobson, Object-Oriented Software Enginneering, A Use Case Driven

Approach, Addison-Wesley, 1992. 3. [Roques & Vallée, 2006] : UML 2 en action : De l'analyse des besoins à la

conception, Pascal Roques et Franck Vallée, 2007, Eyrolles. 4. [Vallée 04] : UML est les décideurs, Franck Vallée, 2004, Eyrolles 5. [Booch 96] :Object Solutions : Managing the Object-Oriented Project, G.

Booch, 1996, Addison-Wesley 6. Pascal Roques, UML 2 par la pratique : Etudes de cas et exercices corrigés,

Eyrolles, 2006. 7. Christian SOUTOU, de UML à SQL, Eyrolles.


89

TABLE DES TABLEAUX Tableau 1 : Contexte dynamique de GESTCOUR...................................................... 14 Tableau 2 : Cas d'utilisation de GESTCOUR .............................................................. 18 Tableau 3 : Package des cas d'utilisation. ................................................................... 34 Tableau 4 : Tableau des composants .......................................................................... 70 Tableau 5 : Opération d'analyse................................................................................. 72

TABLE DES FIGURES Figure 1. Organigramme du Département DSS de la GCM (Source : DSA/S) ................... 8 Figure 2. Le processus de développement en Y.............................................................. 11 Figure 3. Diagramme de Contexte dynamique............................................................... 15 Figure 4. Diagramme d'Activité "CourrierSortant".......................................................... 16 Figure 5. Diagramme d'activités "CourrierEntrant"......................................................... 17


90

Figure 6. Diagramme de Cas d’utilisation ...................................................................... 21 Figure 7. Diagramme de séquences du cas d’utilisation « GérerCourrierEntrant » ......... 24 Figure 8. Diagramme de séquences du cas d’utilisation « GérerArchivage ».................. 27 Figure 9. Diagramme de séquences du cas d’utilisation « GérerTransmission »............. 29 Figure 10. Diagramme de Séquences du cas d'Utilisation "GererFeedback".................... 31 Figure 11. Cas d'utilisation généralisés. ........................................................................... 32 Figure 12. Uses case dans GérerCourrier ........................................................................ 33 Figure 13. Cas d'utilisation inclus dans Gérer transmission.............................................. 33 Figure 14. Diagramme de Classes participantes du CU "Gérertransmission".................... 35 Figure 15. Diagramme de Classes participantes du CU "Gérerclassement" ...................... 35 Figure 16. Diagramme de cas d'utilisation organisés........................................................ 36 Figure 17. Diagramme de déploiement GESTCOUR....................................................... 38 Figure 18. Configuration réseau de GESTCOUR .............................................................. 39 Figure 19. Diagramme de cas d'utilisation techniques ..................................................... 42 Figure 20. Packages de GESTCOUR................................................................................. 44 Figure 21. Diagramme de package d'analyse ................................................................... 45 Figure 22. DCL de la catégorie "AGENT"......................................................................... 48 Figure 23. DCL de la catégorie "COURRIER"................................................................... 48 Figure 24. DCL de la catégorie "CLASSEMENT"............................................................... 48 Figure 25. Diagramme de classe du modèle statique ....................................................... 49 Figure 26. Diagramme de séquence de GCE_N1 ............................................................. 52 Figure 27. Diagramme de communication de GCE_N1 ................................................... 53 Figure 28. Diagramme de séquences de GCL_N1........................................................... 55 Figure 29. Diagramme de communication de GCL_N1 .................................................. 56 Figure 30. Diagramme de séquence de GT_N1 .............................................................. 58 Figure 31. Diagramme de communication de GT_N1 .................................................... 59 Figure 32. Diagramme de séquence de GF_N1 .............................................................. 60 Figure 33. Diagramme de communication de GF_N1..................................................... 61 Figure 34. Diagramme d'Etat-transition de l'objet Courrier .............................................. 63 Figure 35. Diagramme de confrontation........................................................................... 65 Figure 36. Modèle de déploiement détallé de GESTCOUR.............................................. 68 Figure 37. Modèle d'exploitation GESTCOUR................................................................ 69 Figure 38. Consolidation de l'application GESTCOUR ................................................... 70 Figure 39. Catégories de la couche présentation .............................................................. 71 Figure 40. Vue des commandes de la couche Applicative :: Classement.......................... 72 Figure 41. Diagramme de classes détaillées ..................................................................... 75 Figure 42. Classes Courrier et états .................................................................................. 76 Figure 43. Classe Classement et états .............................................................................. 77 Figure 44. classe Transmission et ses états ....................................................................... 77 Figure 45. classe Feedback et ses états ............................................................................ 78 Figure 46. IHM de la classe interface CourrierEntrant ..................................................... 79 Figure 47. IHM de la classe interface Classement ........................................................... 79 Figure 48. IHM de la classe interface Feedback ............................................................... 80 Figure 49. Algorithme de création d'un classement. ........................................................ 84 Figure 50. Architecture Client/Serveur ............................................................................. 85

TABLE DES MATIERES INTRODUCTION GENERALE ............................................................................. 1

1. PROBLEMATIQUE................................................................................................. 1


91

2. HYPOTHESE.......................................................................................................... 2 3. CHOIX ET INTERET DU SUJET .............................................................................. 2 4. METHODES ET TECHNIQUES............................................................................... 2 5. SUBDIVISION DU TRAVAIL ................................................................................. 3

CHAP I : MODELISATION DES BESOINS........................................................... 4

1.1. ETUDE PRÉLIMINAIRE........................................................................................... 4 1.1.1 Recueil des besoins fonctionnels ................................................................... 4 1.1.2 Choix techniques ......................................................................................... 10 1.1.3 Identification des acteurs ............................................................................. 12 1.1.4 Identification des messages.......................................................................... 13

1.2. ANALYSE FONCTIONNELLE............................................................................... 15 1.2.1 Détermination des cas d’utilisation.............................................................. 18 1.2.2 Description détaillée des cas d’utilisations .................................................. 21 1.2.3 Organisation des cas d’utilisations............................................................... 32 1.2.4 Identification des classes candidates............................................................ 34 1.2.5 Validation et consolidation .......................................................................... 36

1.3. CAPTURE DES BESOINS TECHNIQUES.............................................................. 37 1.3.1 Spécification technique du point de vue matériel ........................................ 37 1.3.2 Spécification d’architecture et influence sur le modèle de déploiement ...... 40 1.3.3 Élaboration et organisation du modèle de spécification logicielle ............... 41 1.3.4 Description des couches logicielles ............................................................. 42 1.3.5 Description d’un cas d’utilisation technique................................................ 43

CHAP II : ANALYSE OBJET & CONCEPTION DE L'ARCHITECTURE TECHNIQUE..........................................................................................................................44

2.1. NOTIONS DE CATEGORIES................................................................................ 44 2.1.1 Découpage en catégories............................................................................. 44 2.1.2 Dépendance entre catégorie ........................................................................ 45

2.2. DEVELOPPEMENT DU MODELE STATIQUE ...................................................... 46

2.3. DEVELOPPEMENT DU MODELE DYNAMIQUE ................................................. 50 2.3.1 Identification et formalisation des scénarios ................................................ 50 2.3.2 Construction et validation des diagrammes d'états ..................................... 61 2.3.3 Confrontation des modèles statique et dynamique ...................................... 64

2.4. CONCEPTION GENERIQUE................................................................................ 66 2.4.1 Modèle logique de conception technique.................................................... 66 2.4.2 Modèle d'exploitation de conception technique.......................................... 66 2.4.3 Modèle de configuration logicielle de la conception technique .................. 67 2.4.4 Développement d'un prototype................................................................... 67

CHAP III: CONCEPTION OBJET........................................................................68 3.1. CONCEPTION PRELIMINAIRE ............................................................................ 68

3.1.1 Conception du modèle de déploiement....................................................... 68 3.1.2 Elaboration du modèle d'exploitation .......................................................... 69 3.1.3 Développement du modèle logique de conception .................................... 70 3.1.4 Création des interfaces des catégories.......................................................... 71 3.1.5 Mise au point de la présentation des applications ..................................... 72 3.1.6 Organisation de la configuration logicielle ................................................. 73

3.2. CONCEPTION DETAILLEE .................................................................................. 73


92

3.2.1 Conception détaillée du modèle logique ..................................................... 74 3.2.2 Conception de la couche présentation......................................................... 78 3.2.3 Conception de la couche persistance........................................................... 80 3.2.4 Conception de la couche applicative........................................................... 83 3.2.5 Conception de la couche métier Distribuée................................................. 84

CONCLUSION GENERALE ................................................................................86

BIBLIOGRAPHIE ...............................................................................................88

TABLE DES TABLEAUX ......................................................................................89

TABLE DES FIGURES .........................................................................................89

TABLE DES MATIERES ......................................................................................90

Date post:	28-Jul-2015
Category:	Documents
Upload:	jldk007
View:	1,615 times
Download:	3 times

Gestion des courriers assistée par ordinateur avec Visual Studio.Net sous Windows (cas de la GCM)

Documents