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
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 passs au tamtam, l'envoi des courriers, la tlphonie,.jusqu' l'changes des messages par tlphones, internet et autres nouvelles technologies.
L'entreprise tant aussi une personne morale, se doit d'changer des messages avec des entits externes ou internes. Pour y parvenir elle utilise le courrier. Ces courriers qui proviennent de diffrents endroits doivent tre organiss (transmission, classement,) afin de pouvoir en tirer les informations ncessaires dont l'entreprise a besoin. Un dpartement est charg d'assurer la gestion de ces courriers.
Cest dans cette optique que nous nous sommes penchs sur la gestion des courriers du dpartement des services administratifs de la Gcamines.
1. PROBLEMATIQUE
La Gcamines est lune de grandes entreprises qui compte en son sein un grand nombre dagents rpartis dans diffrents siges. Ces diffrents
siges, pour le bon fonctionnement de l'entreprise, envoient ou reoivent des courriers qui proviennent de l'extrieure (SNEL, REGIDESO,..) ou de l'entreprise. Le dpartement des services administratifs, face cette masse d'informations qui lui parvient, n'arrive pas toujours mieux grs 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 rduit et une accessibilit rapide aux rsultats. Alors comment arriver se rappeler des courriers qui ont t mis en suspend ?
Gestion des courriers assiste par ordinateur avec Visual Studio.Net sous Windows (cas de la GCM)
Comment savoir que tel courrier doit recevoir sa rponse dans peu de temps ? Comment rappeler aux destinataires qu'il y a une attente de rponse dans le systme ? Comment rechercher facilement un courrier dans une pile des courriers classs ou transmis ? Comment arriver liminer les tches inutiles, gagner en temps de travail en ayant un accs rapide aux informations relatives au courrier ?
2. HYPOTHESE
Nous pensons que pour rsoudre ces problmes il faudra analyser ce systme dinformation afin darriver voir de quelle manire linsertion dun outil informatique est capable de rpondre tous ces besoins.
Ltude de la gestion des courriers doit nous permette darriver mettre sur pied une application de gestion des courriers. Cette application facilitera le classement, la transmission, le suivi des courriers qui attendent de rponse, 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. Lintrt de ce sujet est que le rsultat (application) aidera le dpartement mieux grer ses courriers.
4. METHODES ET TECHNIQUES
Comme tout travail scientifique exige une mthode de travail, nous utiliserons de mthodes descriptives et analytiques bases sur le langage de modlisation UML 2.0 dans la dmarche 2TUP. La rcolte des donnes s'est faite grce aux techniques suivantes :
Lobservation participative, qui nous a permis de porter un regard sur les ralits et davoir en vue les moindres dtails.
Linterview libre, qui a permis une rcolte de donnes prcises.

2
La documentation, qui a port sur les documents crits se rapportant au sujet dtude.
5. SUBDIVISION DU TRAVAIL
Notre travail est subdivis, hormis lintroduction gnrale et la conclusion gnrale, en 3 chapitres savoir :
CHAPITRE I : MODELISATION DES BESOINS, Dans ce chapitre nous avons prsent 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 prsentons les scnarios des cas d'utilisations obtenus au niveau du premier chapitre et les diagrammes dynamiques qui ressortent de cette analyse, nous rtudions les classes participantes et la conception gnrique.
CHAPITRE III : CONCEPTION OBJET, dans ce chapitre nous prsentons la conception dtaille du systme qui abouti au codage.
CHAP I : MODELISATION DES BESOINS

1.1. ETUDE PRLIMINAIRE
La premire phase lors de ltude dun systme est ltude prliminaire. Celle-ci se base sur la recherche des besoins fonctionnels et oprationnels, en utilisant principalement des diagrammes simplifis et une description textuelle. Elle prpare les activits formelles de capture des besoins fonctionnels et de capture techniques.
1.1.1 Recueil des besoins fonctionnels

Plusieurs recherches ont t effectues pour identifier au mieux les besoins des utilisateurs afin de rpondre leurs attentes. Nous avons recueilli les informations au sein du Dpartement des Services Administratives Sud (DSA/S) pour bien dfinir le primtre de notre systme. Toutes les informations trouves nous ont permis dtablir le cahier des charges suivant : Le Dpartement DSA/S reoit des courriers provenant de Directions, Dpartements, Divisions et Services de la GCM ; des socits partenaires ; des individus ou des agents n'engageant pas leur Service, A l'arrive du courrier, le Secrtaire du DSA/S rceptionne et lit les indications mentionnes sur l'enveloppe. Il se renseigne dlicatement 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 Secrtaire du DSS le remet en mains propre au DSS/DIR. Et dans le second cas, il prend connaissance du contenu du courrier, en vrifiant le degr de priorit puis le transmet au bureau d'administration. L'agent charg d'horodatage et enregistrement des courriers (Bureau d'administration du Secrtariat) tiens jour le registre des courriers reus. Pour chaque courrier reu, il enregistre dans l'ordre:
1)
la date de rception du courrier (qu'il inscrit sur le courrier reu);
2)
le numro d'ordre d'arrive du courrier (qu'il attribue chaque courrier reu) le numro d'ordre est renouvel chaque dbut d'annes pour les nouveaux courriers.
3) 4) 5) 6)
le numro de rfrence du courrier (de l'expditeur); l'expditeur du courrier; l'objet du courrier ou le rsum explicatif; le destinataire; Aprs enregistrement, le courrier est remis au Secrtaire pour la
prsentation au Dpartemental. Si le courrier reu fait rfrence un autre courrier dj archiv et class auparavant, celui-ci sera retir du classeur par le charg de saisies et classement. Deux courriers seront alors placs cte cte dans le signataire. Le signataire sera ensuite dpos DSS/DIR. Les courriers portant la mention "Urgent" sur l'enveloppe, sont prsents dans un signataire distinctif. Aprs 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 Secrtaire transmet le courrier tudi et annot au bureau d'administration du Secrtariat pour le classement, la rorientation ou l'dition d'un document de rponse selon l'esprit des annotations. L'agent charg d'horodatage et enregistrement des courriers poursuit l'enregistrement des informations supplmentaires dans le registre de courriers reus, de chaque courrier trait. Les donnes enregistres sont : l'angle gauche du bureau du
7) 8)
la date de sortie du courrier du bureau DSS/DIR le classement du courrier; Lorsque les annotations ordonnent le classement d'un courrier, le
bureau d'administration du Secrtariat procde au classement du courrier aprs enregistrement du code du classeur dans le registre de courriers reus.
Dans le cas d'une rorientation, un carnet de transmission est complt au bureau d'administration du secrtariat. Le courrier et le carnet sont remis l'agent Huissier qui s'occupera de la transmission du courrier vers la nouvelle destination. Les lments mis en vidence dans ce carnet sont :
1) 2) 3) 4) 5) 6) 7) 8)
La date de transmission du courrier Le numro d'ordre cit plus haut Le numro de rfrence du courrier cit plus haut L'objet du courrier (celui mentionn dans le registre) Les annotations (mentionnes par le DSA) Le destinataire (rorient) d'aprs les annotations du DSS/DIR La date d'accuse de rception du courrier La signature de l'agent accusant rception du courrier Le Dpartement DSS met galement des courriers vers d'autres
Directions, Dpartements, Divisions et Services de la GCM. Lorsque le document est prt pour l'expdition, le bureau administratif du Secrtariat DSS prend bon soin de noter les indications ncessaires dans le registre des courriers expdies. Il s'agit des donnes signaltiques suivantes :
1) 2) 3) 4) 5)
La date d'expdition du courrier ; le numro de rfrence du courrier. donn par CID chaque anne ; le destinataire ; l'objet du courrier ; l'observation. Ds que tout est prt pour l'expdition du courrier, l'agent
huissier du Secrtariat 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 rception. Les ressources hardware et software de la Direction DSS Pour assurer une bonne prestation, le Dpartement DSS a mis la disposition de son Secrtariat un certain nombre d'outils de travail dont une solution informatique.
a. Les Matriels (hardware) Il s'agit des tous les appareils utiliss par le Secrtariat 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 tlfax 3 tlphones 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 systme d'exploitation et l'environnement de travail ou logiciels utilitaires. Parmi les logiciels utiliss, nous pouvons citer : o Le systme dexploitation : Il y a 2 systmes d'exploitation Windows XP Pro dj installs 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 Dpartement DSS

Dpartement des Services Administratifs du groupe SUD DSS/DIR
DSS/SEC
DSS/ADM-BDG+RCT
Division Enseignement du Groupe Sud ENS/DIR ENS/SEC
Division Administration du Groupe Sud AGS/DIR
AGS/SEC
PRIM
ADM
SGX
SEC
SAS
Figure 1. Organigramme du Dpartement DSS de la GCM (Source : DSA/S) Sigles : DSS DSS/DIR DSS/SEC ADM-BDG+RCT AGS AGS/DIR AGS/SEC ENS : Dpartement des Services Administratifs du Groupe Sud : Directeur du Dpartement DSS : Secrtariat de la Direction DSS : Administration, Budget & Recrutement du DSS : Division de lAdministration du Groupe Sud : Directeur de la Division AGS : Secrtariat de la Division AGS : Division de l'Enseignement du Groupe Sud
SPL
ENS/DIR ENS/SEC ADM SEC PRIM SAS SGX SPL
: Directrice de Division ENS : Secrtariat de la Division ENS : Service administratif de la Division ENS : Service de l'enseignement SECONDAIRE Groupe SUD : Service de l'enseignement PRIMAIRE Groupe SUD : Service d'Actions Sociales Groupe Sud : Services Gnraux : Service du Personnel
Les agents en charge des courriers ont mis les besoins suivants : La facilitation de la recherche dun courrier : le systme doit tre en mesure de permettre, en un temps rduit, la recherche dun courrier pris en rfrence ou recherch pour tre annex ou ventuellement pour une consultation. Le suivi des courriers en attente de rponse (FeedBack) : le systme doit tre en mesure de rappeler en temps rel les courriers qui attendent une rponse selon un dlai dattente. Le rappel des courriers mis en suspend : le systme doit tre capable de rappeler les courriers mis en attente pour traitement et cela un jour avant la date requise pour le traitement. Le systme doit permettre, tout moment de la journe, au Dpartemental de connatre le nombre de courriers quil a traiter. Le modle, 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 rponses. Elle doit aussi permettre de suivre la transmission des courriers ainsi que leur classement ou archivage. Pour rpondre aux besoins soulevs ci-haut, des mthodes et des techniques doivent tre opres.
1.1.2 Choix techniques

Plusieurs techniques et mthodes existent pour lanalyse et la conception dun systme. Dans cette tude, nous avons opt pour les techniques suivantes: - UML. Dans sa deuxime version pour la modlisation du systme. - Une programmation oriente objet dans une architecture 3 couches - Visual Basic 6.0 pour la programmation de l'application. - Le systme de gestion de base de donnes SQL Server pour l'laboration d'une base de donnes. - Utilisation des ateliers de gnie logiciel PaceStar UML et Power Designer pour la reprsentation des modles UML ainsi que Visio et Packet Tracer pour la prsentation des modles rseaux. Plusieurs dmarches utilisant UML sont prsentes : 2TUP, XP, Scrum, RUP,). De toutes ces dmarches, nous avons opt pour la mthode 2TUP cause de son originalit et son agilit. Cette mthode se base sur les principes du processus UP. Un processus dfinit une squence dtapes, en partie ordonnes, qui concourent lobtention dun systme logiciel ou lvolution dun systme existant. Lobjet dun processus de dveloppement est de produire des logiciels de qualit qui rpondent aux besoins de leurs utilisateurs dans des temps et des cots prvisibles. [Roques & Valle, 2004]. 2TUP signifie 2 Track Unified Process .Cest un processus qui rpond aux caractristiques du Processus Unifi. Le processus 2TUP apporte une rponse aux contraintes de changement continuel imposes aux systmes dinformation de lentreprise. En ce sens, il renforce le contrle sur les capacits dvolution et de correction de tels systmes. 2 Track signifient littralement que le processus suit deux chemins : fonctionnel et technique. Ces deux chemins correspondent aux deux axes de changement imposs au systme dinformation. La branche fonctionnelle (partie gauche) se base sur la connaissance du mtier de lentreprise. Les fonctions du systme dinformation sont indpendantes des technologies utilises. Cette branche comporte les tapes suivantes :
10
- La capture des besoins fonctionnels, bas sur le mtier des utilisateurs. - Lanalyse 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 gnrique. La branche du milieu : lissue des volutions du modle fonctionnel et de larchitecture technique, la ralisation du systme consiste fusionner les rsultats des 2 branches. Cette branche comporte les tapes suivantes : la conception prliminaire, la conception dtaille, le codage et lintgration. Cette fusion conduit lobtention dun processus en forme de Y.
Figure 2. Le processus de dveloppement en Y Le processus 2TUP sappuie sur UML tout au long du cycle de dveloppement, car les diffrents diagrammes de ce dernier permettent de part leur facilit et clart, de bien modliser le systme chaque tape.
11
1.1.3 Identification des acteurs

Dans un systme donn, il y a des acteurs qui agissent. Un acteur reprsente l'abstraction d'un rle jou par des entits externes (utilisateur, dispositif matriel ou autre systme) qui interagissent directement avec le systme tudi [Roques & Valle, 2004].
.
Pour rduire la complexit du systme de gestion de courriers, nous avons restreint notre champ d'application sur la gestion de courriers uniquement dans un dpartement. Notre primtre est le Dpartement DSS dans sa gestion de courriers. Il y a 7 acteurs qui apparaissent dans ce primtre, savoir : - Le Dpartemental : Le dpartemental traite tous les courriers qui entrent et sortent de son bureau. Il appose des annotations en rapport avec la transmission, la rorientation ou le classement de ces courriers. - Le Secrtaire : le secrtaire rceptionne les courriers, il vrifie la prsentation et transfre pour enregistrement. Il rappelle les courriers en suspend pour le traitement et effectue le suivi des courriers qui attendent une rponse. - Lattach au Bureau Administration : il enregistre les courriers mis ou reus. - Lattach au Bureau Archivage : il archive les courriers selon un mode classement. - L'Huissier : il achemine les courriers vers les destinataires respectifs. - LExpditeur : envoi des courriers au dpartement - Le Destinataire : reoit les courriers en provenance du Dpartement. Mais le systme ne sera utilis que par 5 acteurs : Le Dpartemental, le secrtaire, l'attache au bureau d'administration, l'attache au bureau d'archivage et l'expditeur. de
12
1.1.4 Identification des messages

"Un message reprsente la spcification d'une communication unidirectionnelle entre objets qui transporte de l'information avec l'intention de dclencher une activit chez le rcepteur" [Roques et Valle, 2006]. Un message est normalement associ deux occurrences
d'vnements : un Evnement
d'envoi et un vnement de rception. Cette
notion de message est galement tout fait applicable pour dcrire les interactions de plus haut niveau entre les acteurs et le systme. Pour notre tude de cas GESTCOUR, nous avons les messages suivants entre le systme et ses acteurs : Le systme GESTCOUR met : Les courriers mis en attente de traitement, Les courriers archivs, Les courriers transmis, Les courriers en attente de feedBack (rponse) Le systme GESTCOUR reoit : Les crations, modifications des courriers, Lenregistrement du classement des courriers, Les crations de classeurs, Les informations de suivi dun courrier (FeedBack), Les connexions au systme Les visualisations des courriers (recherche, visualisation pure)
13
Diagramme de contexte dynamique de GESTCOUR

A partir des informations obtenues lors des deux prcdentes tapes, nous allons modliser le contexte de notre application. Ceci nous permettra de dfinir les besoins fonctionnels de chaque acteur dans le systme (Tableau 1) :
Utilisateurs
Dpartemental Attache au administration Secrtaire Attache archivage au
Description des besoins fonctionnels

Le systme GESTCOUR permettra au Dpartemental : de s'authentifier de consulter les courriers qu'il doit traiter de consulter les courriers qui attendent une rponse. de rechercher un courrier dj class ou transmis. de s'authentifier, de grer les courriers entrants/sortants et transmettre. S'authentifier de consulter les courriers que le dpartemental doit traiter de consulter les courriers qui attendent une rponse.
bureau GESTCOUR permettra l'Attache du bureau administration :
GESTCOUR permettra au Secrtaire :
de rechercher un courrier dj class ou transmis.

bureau GESTCOUR permettra l'Attache au bureau archivage : de s'authentifier
de grer les classeurs et l'archivage des courriers.

Destinataire/Expditeur GESTCOUR permettre au Destinataire :
de recevoir/envoyer son courrier

Tableau 1 : Contexte dynamique de GESTCOUR
14
Le diagramme de contexte de GESTCOUR est le suivant :

S'authentifier Consulter les courriers traiter Consulter rponse courriers (FeedBack) Rechercher courriers
Dpartemental
S'authentifier Crer , Modifier Courrier E/S Crer transmition courrier Attache Bur.Admin
Liste courriers en attente Liste courriers Feedback
GESCOUR
Secrtaire
S'authentifier Consulter les courriers traiter Consulter rponse courriers (FeedBack) Rechercher courriers
S'authentifier Crer classeurs Crer Archivage courrier Recevoir courrier
Attache. Bur. Archiv
Destinataire
Figure 3. Diagramme de Contexte dynamique
1.2. ANALYSE FONCTIONNELLE

La capture des besoins fonctionnels est la premire tape de la branche gauche du cycle en Y. Elle formalise et dtaille ce qui a t bauch au cours de ltude prliminaire nous dit Roques. Cette capture peut tre facilite par un diagramme d'activits reprsentant toutes les activits de chaque utilisateur du systme. ce diagramme d'activits est appel diagramme d'activits par couloir de responsabilit.
15
Cas d'un courrier sortant.
Figure 4. Diagramme d'Activit "CourrierSortant" Dans ce premier diagramme, partir des activits numres, nous voyons que certaines activits peuvent tre regroupes en une vue gnrale. Du poste du dpartemental jusqu'au poste du secrtaire, il apparat des activits qui peuvent tre regroups en une vue "GrerCourrierSortant". Cette gestion du courrier concerne plus le bureau dadministration vu que cest ce dernier qui attribue un numro dentre et effectue l'auto-datant de ces courriers. Il apparat aussi la transmission des courriers. Cette partie sera explicit dans le deuxime diagramme d'activits.
16
Cas d'un courrier entrant
Figure 5. Diagramme d'activits "CourrierEntrant"
Dans ce second diagramme, on peut avoir une gestion de larchivage des courriers, la transmission des courriers, la gestion des courriers entrants ainsi que la gestion des FeedBack (si il y a une attente de rponse).
17
1.2.1 Dtermination des cas dutilisation

Un cas dutilisation (use case) reprsente un ensemble de squences dactions ralises par le systme et produisant un rsultat observable intressant pour un acteur particulier [UML 2 en action]. Un cas dutilisation modlise un service rendu par le systme. Il exprime les interactions acteurs/systme. Chaque cas dutilisation spcifie un comportement attendu du systme considr comme un tout, sans imposer le mode de ralisation de ce comportement. Il permet de dcrire ce que le futur systme devra faire, sans spcifier comment il le fera. Le cas dutilisation met en valeur les interactions mtier entre les acteurs et le systme (au niveau fonctionnel). Le tableau ci-dessous montre les cas dutilisation retenus dans le systme GESTCOUR
Acteur principal, acteurs secondaires Attache au Bureau dadministration Destinataire GrerArchivage Attach au Bureau archivage GrerTransmission Attache au bureau dadministration Huissier GrerFeedBack Secrtaire Dpartemental GrerCourrierSuspend Secrtaire Dpartemental GrerCourrierSortant Attache au bureau d'administration Reoit : Accus Rception Emet : Mise jour des courriers en attente de rponse Reoit : Etat final des courriers en attente de rponse Emet : Mise jour des courriers en suspend Reoit : Etat final des courriers en suspend Emt : Cration, modification des courriers sortants. Emet : Cration, mise jour des transmissions
Cas d'utilisation GrerCourrierEntrant
Messages mis/reus par les acteurs Emet : Cration, mise jour, annulation des courriers entrants. Reoit : Condition du courrier Reoit : Rponse (si cest ncessaire) Emet : Cration, mise jour Classeurs
Tableau 2 :
Cas d'utilisation de GESTCOUR
18
Description prliminaire des cas dutilisations Voici une description prliminaire des cas dutilisations numrs ci-haut : 1. GrerCourrierEntrant : - Intention : Grer tous les courriers entrants au sein du dpartement. - Actions : Pour les courriers entrants; le bureau d'administration effectue l'auto-datage, enregistre les lments signaltiques des courriers dans le systme ainsi que lexpditeur. 2. GrerCourrierEntrant : - Intention : Grer tous les courriers Sortant au sein du dpartement. - Actions : Pour les courriers sortants, il enregistre, comme pour les courriers entrants, les lments signaltiques et le destinataire.Le bureau d'administration modifie galement les lments d'un courrier s'ils ont t mal saisis. 3. GrerTransmission - Intention : Assur le suivi dune transmission dun courrier - Actions : En rapport avec les annotations mises sur les courriers par le Dpartemental, le bureau d'administration gre la transmission des courriers en enregistrant les courriers transmettre. Le huissier est charg de revenir avec un accus rception dans le systme. 4. GrerArchivage : - Intention : Grer le classement des courriers - Actions : Le bureau archivage est charg de classer les courriers en suivant un mode de classement dj tablit. Il cre 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 rfrencs, etc.
19
5.
GrerFeedBack - Intention : assurer le suivi des courriers en attente de rponse - Actions : Le secrtaire est charg de valider les courriers ayant reues une rponse ou changs dtat (de ltat en attente ltat rpondu).
6.
GrerCourrierSuspend - Intention : assurer le suivi des courriers en suspend - Actions : Le secrtaire est charg de valider les courriers en suspend qui ont t traits et de rappeler au dpartemental les courriers qui doivent tre traits selon la date de traitement prvue. Le Dpartemental utilise ces deux derniers cas dutilisation en
consultation. Il a une vue gnrale des courriers qui attende un feedback pour insister sur lurgence des rponses ces courriers. Il peut galement consulter les courriers qui attendent d'tre traits ou ventuellement rechercher un courrier.
20
Ce qui donne le diagramme de cas dutilisation suivant :

GrerCourrierEntrant
Expditeur GrerCourrierSortant Att. Bur.Admin
GrerTransmission
Destinataire GrerFeedBack GrerArchivage
Secrtaire Att. Bur.Archiv GrerCourrierSuspend
Dpartemental
Figure 6. Diagramme de Cas dutilisation
1.2.2 Description dtaille des cas dutilisations

Valle nous dit que la description du cas dutilisation dcrit lintention de lacteur lorsquil utilise le systme et les squences dactions principales quil est susceptible deffectuer. Les descriptions se prsentent comme suit : - Un sommaire didentification rsumant les proprits du cas dutilisation. - Une description dtaille prsentant les Pr-conditions qui entrane le dclenchement du cas dutilisation jusqu sa ralisation. - Les diagrammes apportent une comprhension supplmentaire dutilisation. Mais ils sont optionnels. au cas
Cette description des cas dutilisation se prsente sur une fiche appel fiche didentification. Dans notre cas d'tude nous avons retenu les fiches suivantes :
21
Fiche d'identification du cas dutilisation : "GrerCourrierEntrant" Titre : But : Rsum : Acteurs : Date de cration : Date de mise jour : Version : Responsable : GrerCourrierEntrant Grer les courriers reus. Cration, modification d'un courrier Attache au bureau dadministration 3/05/2009 12/07/2009 1.0 Diane NGOIE
Description des enchanements Prcondition : L'attache au bureau dadministration s'est dj authentifie. Enchainements nominaux : Ce cas d'utilisation commence lorsqu'il y a un courrier Entrant, Alors l'attache au bureau dadministration demande au systme la cration d'un courrier. Enchanement (a) Crer un courrier Entrant L'attach saisit le Numro dentre du courrier. Le systme vrifie si ce numro existe. Si le numro saisie existe alors excution de [Exception 1 : NumCourrierExistant]. L'agent saisit ensuite toutes les informations lies au courrier (le numro de rfrence du courrier, le rsum du courrier, lexpditeur) et demande la validation du courrier. Le systme vrifie le format des donnes. Si le format nest pas conforme ; alors excuter [Exception 2 : ErreurFormat]. Enchainement (b) Valider Cration courrier L'attache valide la cration du courrier. Le systme attribue une date de cration du courrier.
22
Enchainements alternatifs : Enchainement (c) Annuler Cration Courrier Lors de la cration dun courrier, il peut se faire que ce courrier soit adress un autre dpartement ou une des divisions du dpartement, alors lattache au bureau dadministration annule la cration du courrier dans le systme. Enchainementd) Modifier Courrier Lors de la cration du courrier, il se peut que lattache ait mal saisie les lments du courrier, le systme lui permet de modifier ce qui a t mal saisie. Le cas dutilisation GrerCourrierEntrant prend fin quand lattache valide la cration du courrier ou lannulation. Le courrier contient le numro dentre, la date, le rsum, lexpditeur et le numro de rfrence.
Exceptions : [Exception 1 : NumCourrierExistant] : Le systme affiche un message d'erreur et demande la saisie dun nouveau numro de courrier. Il dsactive la validation du courrier jusqu la saisie du nouveau numro de courrier. [Exception 2: ErreurFormat] : Le systme affiche un message d'erreur et demande la modification du format des donnes selon ceux qui sont dfinis. Post-conditions - Le courrier valid a un numro denregistrement, - les donnes saisies respectent les formats dfinis.
23
Voici le diagramme de squences reprsentant les messages changs, pour le cas dutilisation "GrerCourrierEntrant", entre le systme et l'attache au bureau d'administration.
Figure 7. Diagramme de squences du cas dutilisation GrerCourrierEntrant Le systme est vu, ce niveau, comme une bote noire. Fiche d'identification du cas dutilisation : "GrerCourrierSortant" La fiche d'identification du cas d'utilisation "GrerCourriersortant" est identique la fiche d'identification du cas d'utilisation "GrerCourrierEntrant". Mais la petite diffrence est qu' la cration d'un courrier sortant, l'expditeur est remplac par le destinataire.
24
Fiche d'identification du cas dutilisation : "GrerArchivage" Titre But Rsum Acteurs Date de cration Date de mise jour Version Responsable : : : : : : : : GrerArchivage Grer le classement des courriers reus. Cration, modification d'un classement. Attache au bureau darchivage 3/05/2009 12/07/2009 1.0 Diane NGOIE
Description des enchanements Prcondition : L'attache au bureau darchivage s'est dj authentifie. Il existe au moins un courrier enregistr dans le systme. Enchainements nominaux : Ce cas d'utilisation commence lorsqu'il y a un courrier Entrant classer, Alors l'attache au bureau darchivage demande au systme l'archivage d'un courrier. Enchanement (a) Crer un Archivage. L'attach saisit le Numro du courrier. Le systme vrifie si ce numro existe. Si le numro saisie n'existe pas alors excution de [Exception 1 : NumCourrierInexistant] L'agent saisit le code du classeur. Le systme vrifie si ce classeur existe. S'il n'existe pas alors [Exception 2 : CodeClasseurInexistant]. Enchainement (b) Valider Cration Archivage L'attache valide l'archivage du courrier. Le systme attribue une date d'archivage et un numro d'archivage.
25
Enchainements alternatifs : Enchainement (c) Crer un nouveau classeur Lors de l'archivage dun courrier, il peut se faire que ce courrier soit archiver dans un classeur qui n'existe pas dans le systme. dans ce cas, il faudra d'abord crer un classeur. Le cas dutilisation GrerArchivage prend fin quand lattache au bureau archivage valide l'archivage du courrier ou lannulation. L'archivage contient le numro du courrier, le classeur et la date de l'archivage.
Exceptions : [Exception 1 : NumCourrierInexistant] : Le systme affiche un message d'erreur et demande la saisie dun numro de courrier existant. Il dsactive la validation jusqu la saisie du numro de courrier. [Exception 2: CodeClasseurInexistant] : Le systme affiche un message d'erreur et demande la modification du CodeClasseur. Post-conditions - Le courrier trait est archiv, - il existe au moins un classeur.
26
Le diagramme de squences qui illustre cette description est :
Figure 8. Diagramme de squences du cas dutilisation GrerArchivage Fiche d'identification du cas dutilisation : "GrerTransmission" Titre But Rsum Acteurs Date de cration Date de mise jour Version Responsable : : : : : : : : GrerTransmission Grer la transmission des courriers E/S. Cration Transmission. Attache au bureau dadministration 3/05/2009 12/07/2009 1.0 Diane NGOIE
27
Description des enchanements Prcondition : L'attache au bureau dadministration s'est dj authentifie. Il existe au moins un courrier enregistr dans le systme. Enchainements nominaux : Ce cas d'utilisation commence lorsqu'il y a un courrier Entrant/Sortant transmettre, Alors l'attache au bureau dadministration demande au systme l'enregistrement de la transmission du courrier. Enchanement (a) Crer une transmission d'un courrier. L'attach saisit le Numro du courrier. Le systme vrifie si ce numro existe. Si le numro saisie n'existe pas alors excution de [Exception 1 : NumCourrierInexistant]. L'agent saisit le destinataire Enchainement (b) Valider Transmission courrier. L'attache valide la transmission du courrier. Le systme attribue une date de transmission et un numro de transmission.
Enchainements alternatifs : Enchainement (c) Modifier une transmission Lors de l'enregistrement de la transmission dun courrier ou pour un courrier dont la transmission est dj valide, il peut se faire que le destinataire ait t mal saisi. dans ce cas, il faudra modifier le destinataire puis (re) valider. Le cas dutilisation GrerTransmission prend fin quand lattache au bureau administration valide la transmission du courrier ou l'annulation de la transmission. L'archivage contient le numro du courrier, le destinataire et la date de transmission. Exceptions : [Exception 1 : NumCourrierInexistant] : Le systme affiche un message d'erreur et demande la saisie dun numro de courrier existant. Il dsactive la validation jusqu la saisie d'un numro de courrier valide. Post-conditions 1. Le courrier est transmis
28
La description du cas d'utilisation peut tre aussi reprsente par un modle UML.
Figure 9. Diagramme de squences du cas dutilisation GrerTransmission Fiche d'identification du cas dutilisation : "GrerFeedback" Titre But Rsum Acteurs Date de cration Date de mise jour Version Responsable : : : : : : : : GrerFeedback Grer les rponses des courriers transmis. Validation d'une rponse au courrier transmis Secrtaire 3/05/2009 12/07/2009 1.0 Diane NGOIE
29
Description des enchanements Prcondition : Le secrtaire s'est dj authentifi. Au moins un courrier attend une rponse. Enchainements nominaux : Ce cas d'utilisation commence lorsqu'un courrier transmis reoit une rponse, Alors le secrtaire demande au systme la validation de la rponse. Enchanement (a) Valider FeedBack L'attach saisit le Numro du courrier transmis. Le systme vrifie si ce numro existe. Si le numro saisie n'existe pas ou existe mais n'a pas t transmis, alors excution de [Exception 1 : CourrierNonTransmis]. L'agent saisit ensuite toutes le numro de rfrence du courrier reu en rponse et valide.
Exceptions : [Exception 1 : CourrierNonTransmis] : Le systme affiche un message d'erreur et demande la saisie dun numro de courrier transmis. Il dsactive la validation jusqu la saisie du numro de courrier. Post-conditions Validation de la rponse au courrier transmis
30
Voici le diagramme de squences reprsentant les messages changs, pour le cas dutilisation "GrerFeedback", entre le systme et le secrtaire.
Figure 10. Diagramme de Squences du cas d'Utilisation "GererFeedback" Fiche d'identification du cas dutilisation : "GrerCourrierSuspend"
Dans la gestion des courriers en suspend, le secrtaire a une vue de tous les courriers qui sont mis en suspend. De la mme faon qu'il valide les rponses aux courriers transmis, il valide aussi le traitement d'un courrier qui a t mis en suspend.
31
1.2.3 Organisation des cas dutilisations

Les cas dutilisation peuvent tre organiss de deux faons diffrentes et complmentaires, dit Pascal Roques, savoir : en ajoutant des relations dinclusion, dextension, et de gnralisation entre les cas dutilisation ; en les regroupant en packages, afin de dfinir des blocs fonctionnels de plus haut niveau. UML dfinit trois types de relations standardises entre cas dutilisation : une relation dinclusion, formalise par un mot-cl <<include>>, une relation dextension, formalise par un mot-cl <<extend>>, une relation de gnralisation/spcialisation. Dans notre cas d'tude, nous retrouvons uniquement l'inclusion et la gnralisation. Les Uses case "GrerCourrierEntrant" et "GrerCourrierSortant" peuvent tre gnraliss en un cas d'utilisation abstrait "GrerCourrier".
GrerCourrier
<<Gnralisation>> <<Gnralisation>>
GrerCourrierEntrant
GrerCourrierSortant Att. Bur.Admin
Figure 11. Cas d'utilisation gnraliss.
Les uses case "GrerTransmission" et "GrerClassement" sont des cas qui tendent la gestion des courriers. Les points d'extensions sont la transmission et le classement. "GrerCourrierSuspend" est un cas inclus dans la gestion de courrier parce que tout courrier enregistr est en suspend.
32
Secrtaire
GrerCourrierSuspend
GrerArchivage
<<Include>>
Point d'extension : Transmettre Courrier

<<Extend>>
<<Extend>>
Att. Bur.Archiv
GrerCourrier
Point d'extension : Classer Courrier
GrerTransmission
<<Gnralisation>> <<Gnralisation>>
GrerCourrierEntrant
GrerCourrierSortant
Att. Bur.Admin
Figure 12. Uses case dans GrerCourrier
Le cas d'utilisation "GrerTransmission" gre aussi les rponses qui proviennent des courriers transmis, d'o le cas d'utilisation "GrerFeedback" est un cas inclus dans le cas d'utilisation "GrerTransmission".
GrerFeedBack Secrtaire
<<Include>>
GrerTransmission Att. Bur.Admin
Figure 13. Cas d'utilisation inclus dans Grer transmission. Ces cas d'utilisation organiss doivent tre regroups en package. Les lments contenus dans un package : doivent reprsenter un ensemble fortement cohrent, sont gnralement de mme nature et de mme niveau smantique Le critre de regroupement retenu pour le systme GESTCOUR correspond un dcoupage par ensemble dacteurs fortement relis. En reprenant le tableau prliminaire et en affectant chaque cas dutilisation un package, nous obtenons ce qui suit :
33
Diane NGOIE, TFE, Licence professionnelle en informatique de gestion, ISS Cas dutilisation GrerCourrierEntrant GrerCourrierSortant GrerCourrierSuspend Grer Classement GrerTransmission GrerFeedBack Acteurs Attache Bur. Admin Expditeur Attache Bur. Admin Destinataire Secrtaire Attache Bur. Archiv Attache Bur. Admin Secrtaire Package
Gestion Courrier
Gestion classement courrier Gestion transmission courrier
Tableau 3 :
Package des cas d'utilisation.
Chaque package de cas dutilisation occasionne la cration dun diagramme de cas d'utilisation.
1.2.4 Identification des classes candidates

L'identification des classes candidate courriers (les objets mtier). Exemple : CourrierEntrant, CourrierSortant, CourrierSuspend, est fonction des concepts
connus; c'est--dire, ceux qui sont utiliss couramment dans la gestion des
transmission, classement, registre, TypeCourrier, etc. Nous ajouterons dans un second temps des concepts applicatifs , lis linformatisation. Exemples pour ltude de cas : Profil utilisateur, etc.
De la description de chaque cas d'utilisation, il y a des classes participantes qui en dcoulent, soit par les concepts connu ou les concepts applicatifs, comme dit ci-haut. Nous formalisons ensuite ces concepts mtier sous forme de classes et dassociations rassembles dans un diagramme statique pour chaque cas dutilisation. Ces diagrammes de classes participantes, appels diagrammes prliminaires, nont pas dobjectif exhaustif. Ils servent uniquement dmarrer la dcouverte des classes du modle danalyse pour la partie de lapplication.
34
Voici les diagrammes de classes participantes de certains cas d'utilisation : Diagramme de classes participantes du cas d'utilisation "GrerTransmission"
TypeCourrier
1..1
appartient
0..*
CourrierEntrant
1..1
Concerne
0..*
Transmission
1..*
reoit
1..1
Accuse Rception
Reu
Pas reu
Figure 14. Diagramme de Classes participantes du CU "Grertransmission" La transmission, l'accuse rception, reu et pas reu, le courrierEntrant (ou courrier sortant) apparaissent en classes dans le diagramme. La classe Accuse rception est une classe abstraite ayant pour instance les classes reu et pas reu sont des classes abstraites qui se gnralisent dans la classe Accuse rception. Les classes courrierEntrant et courrierSortant sont des classes qui se gnralisent dans la classe Courrier qui est une classe abstraite. Diagramme de classes participantes du cas d'utilisation "GrerClassement"
TypeCourrier
1..1
appartient
Courrier
0..*
1..1
subit
Classement
1..*
1..*
Concerne
Classeur
1..1
0..*
CourrierSortant CourrierEntrant
est rang
1..1
Rayon
Figure 15. Diagramme de Classes participantes du CU "Grerclassement"
35
Un courrier peut tre class dans plusieurs classeurs selon qu'il est adress plusieurs destinataires. Ce qui entraine la cration de la classe classement. Un classeur est rang dans un rayon.
1.2.5 Validation et consolidation

Dans le cadre dun dveloppement itratif et incrmental, il est trs utile de recourir au dcoupage en cas dutilisation pour dfinir les itrations. cet effet, il convient en premier lieu didentifier les cas dutilisation les plus critiques en termes de gestion des risques. Ces cas dutilisation devront tre traits prioritairement afin de lever au plus tt les risques majeurs. Il sera galement demand au client daffecter une priorit fonctionnelle chaque cas dutilisation, afin de livrer dabord les cas dutilisation les plus demands.1 Franck dit que nous peuvons aussi prendre en compte les ventuelles relations entre cas dutilisation : dvelopper plutt les cas factoriss (<include>) avant ceux qui les utilisent, dvelopper plutt les cas qui tendent (<extend>) aprs les cas de base Ce qui explique l'organisation suivante du diagramme de cas d'utilisation :
(Itration 5)
GrerFeedBack
<<Include>>
(Itration 4)
Secrtaire GrerCourrierSuspend Dpartemental
(Itration 2)
GrerTransmission Att. Bur.Archiv
<<Extend>>
(Itration 1)
<<Include>>
GrerCourrier
<<Gnralisation>>
<<Extend>>
GrerArchivage GrerCourrierEntrant
<<Gnralisation>>
(Itration 3)
Att. Bur.Admin
Expditeur
GrerCourrierSortant Destinataire
Figure 16. Diagramme de cas d'utilisation organiss
36
1.3. CAPTURE DES BESOINS TECHNIQUES

Par rapport aux besoins fonctionnels, les besoins techniques viennent en complment. Ils interessent les contraintes autres que la description mtier et la description applicative. La spcification technique est ncessaire pour la conception darchitecture. Cette capture des besoins interesse deux aspects : l'aspect logiciel et l'aspect matriel. Les matriels a utiliser dans le systme doivent tre dfinis suivant la structure logiciel prvue.1
1.3.1 Spcification technique du point de vue matriel

Dans la spcification des mthodes et techniques de
dveloppement, nous avons fait des choix en rapport avec la configuration logiciel et matriel a utiliser pour le cas d'tude. Cette configuration se base sur la scurit du systme, son utilisation, l'accs aux donnes, Pour notre cas d'tude l'architecture deux niveaux (local et dpartemental) est celle qui rpondra favorablement. Les attentes (techniques) du systme GESTCOUR, selon
l'architecture choisie, nous donne les nuds suivants : Un poste qui fera office de serveur de base de donnes o sera install GESTCOUR; Un serveur de messagerie local o les courriers provenant de l'intrieure de l'entreprise seront reus (par mail); 4 postes de travail pour les acteurs internes au systme; 1 switch; Un serveur Web pour permettre aux destinataires/expditeurs externes l'entreprise d'envoyer leurs courriers via internet. Un serveur proxy pour protger GESTCOUR des autres utilisateurs du systme. Une photocopieuse pour garder les traces des courriers importants transmis. GESTCOUR sera utilis dans chaque bureau de l'entreprise d'une faon autonome (niveau local). La direction de la GCM aura une vue gnrale sur les courriers qui circulent dans l'entreprise (niveau dpartemental).
P Roques, F Valle, UML 2 en action, Ed Eyrolles, 2006.

37
<LAN> SERVEUR MESSAGERIE SERVEUR WEB
<LAN> Firewall
POSTE IMPRIMANTE SERVEUR GESTCOUR (Number = 4)
Figure 17. Diagramme de dploiement GESTCOUR Le serveur de messagerie et le serveur Web sont spars du serveur GESTCOUR pour ne pas permettre d'autres personnes qui n'ont pas l'autorisation d'accder au informations contenues dans ce serveur. Cette sparation est rendu possible par un Pare-Feu. Le dpartement tire sa connexion partir du 7ime routeur.
38
Figure 18. Configuration rseau de GESTCOUR
39
1.3.2 Spcification darchitecture et influence sur le modle de dploiement

Pascal Roques et Franck Valle nous dissent que le choix d'une architecture influence aussi le choix du modle de dploiement. Ce choix conditionne la faon dont seront organiss et dploys les composants dexploitation du systme. Plusieurs composants sont donc utiliss dans le systme selon les rles qu'ils exercent. Les uns font office de bases de donnes et les autres des applications qui sollicitent les bases de donnes. Un composant dexploitation est une partie du systme logiciel qui doit tre connue, installe, dclare et manipule par les exploitants du systme. Un composant dexploitation doit tre interchangeable entre diffrentes versions et peut tre arrt ou dmarr sparment. Il assume des fonctions bien identifies dans le systme, de sorte quen cas de dysfonctionnement, le composant incrimin est facilement reprable1. Le style darchitecture en tiers (tier signifie partie en anglais) spcifie lorganisation des composants dexploitation mis en oeuvre pour raliser le systme. Chaque partie indique une responsabilit technique laquelle souscrivent les diffrents composants dexploitation dun systme. Roques dit que le choix d'une architecture client/serveur 3-tiers amne la rpartition des composants dexploitation selon : L'utilisation d'un moteur de base de donnes relationnel la rpartition des diffrents mtiers est faite sur plusieurs composants mtier la ralisation des applications correspondantes aux diffrents composants dexploitation retenus.
40
1.3.3 laboration et organisation du modle de spcification logicielle

L'laboration et l'organisation du modle de spcification logicielle se base sur les fonctionnalits propres du systme technique. Ces fonctionnalits forment des cas dutilisation d'une manire diffrente que pour la spcification fonctionnelle , dit Valle. Il poursuit en disant que les acteurs de ces cas d'utilisations techniques sont appels des exploitants. Tout systme informatique possde au minimum un exploitant qui est lutilisateur du systme . il sagit ici de lutilisateur dans son sens le plus gnral, indpendamment des fonctions ou du mtier quil ralise au travers de lapplication. Dans ce cadre, tout utilisateur se connecte au systme ou utilise l'internet. Ce sont les fonctionnalits purement techniques dont il bnficie en tant quexploitant. Le modle de spcification logicielle est construit sous deux tapes. La premire consiste repertorier tous les besoins des exploitants du systme et extraire les cas dutilisation techniques partir de ces besoins. La deuxime tape rorganise en couches les responsabilits techniques1.
chaque fonction observable pour lexploitant, correspond en effet une cascade de responsabilits techniques qui se dploient sur les diffrentes couches logicielles. Chaque couche produisant des services pour les niveaux suprieurs contient en consquence des cas dutilisation pilots par les couches exploitantes.
41
Les cas d'utilisations technique retenus pour GESTCOUR ainsi que leurs exploitants sont : L'utilisateur : Utiliser des objets Suivre les rgles de scurit du systme Consulter l'aide pour bien utiliser le systme L'ingnieur d'exploitation (l'Administrateur systme) Grer la scurit en utilisation du systme entretenir les performances du systme.
GrerScurit
Administrateur Sys
EntretenirPerformances
UtiliserObjets
SuivreRglesScurit
Utilisateur
ConsulterAide
Figure 19. Diagramme de cas d'utilisation techniques
1.3.4
Description des couches logicielles

La responsabilit affecte chaque couche du modle logicielle
(prsentation, application, mtier, accs aux donnes, stockage de donnes) donne une identification pousse des cas dutilisation techniques. cela permet de poser de manire plus prcise des problmes traiter. Dune part, les cas dutilisation techniques peuvent se spcialiser suivant les couches sur lesquelles ils vont sexcuter ; dautre part, de nouveaux
42
cas dutilisation peuvent apparatre pour rpondre la particularit dune des couches1. Le cas de GESTCOUR offre une illustration de ces diffrents cas.Par exemple : Manipuler des objets va donner lieu plusieurs cas dutilisation qui vont senchaner depuis la couche de prsentation jusqu la couche daccs aux donnes. Par ailleurs, pour manipuler des objets, il est ncessaire de grer des transactions avec la base de donnes relationnelle. Il sagit donc dun nouveau cas dutilisation spcifique pour la couche de stockage des donnes. Pour obtenir une spcification technique dtaille de notre cas d'tude, les lments retenus sont : la recherche d'un objet au niveau de la prsentation ncessite de sappuyer directement sur lexploitation du schma de donnes dune classe (ou Tuplets) au niveau de la couche daccs aux donnes ; l'excution d'un service au niveau de la couche mtier repose sur lexploitation de requtes spcifiques au niveau de la couche daccs aux donnes, qui utilise systmatiquement la gestion des transactions.
1.3.5 Description dun cas dutilisation technique

D'aprs Franck Valle, la description dun cas dutilisation technique est analogue celle des cas dutilisation de la spcification fonctionnelle. Dans ce cadre, on utilise un premier niveau de description, compos dune fiche textuelle et dun diagramme dactivit. Un second niveau de description objet complte ventuellement la spcification. On utilise alors un diagramme de classes et un diagramme dinteractions. Les concepts utiliss pour dcrire les cas dutilisation appartiennent la couche logicielle considre et font lobjet dune dfinition dans le dictionnaire des termes techniques. Exemple : Accs aux donnes :: GrerClasse. Cette exemple illustre la manire dont les classes sont grr au niveau de la couche d'accs aux donnes.
43
CHAP II : ANALYSE OBJET & CONCEPTION DE L'ARCHITECTURE TECHNIQUE

2.1. NOTIONS DE CATEGORIES
2.1.1 Dcoupage en catgories
D'aprs Pascal Roques, une catgorie est un regroupement logique de classes forte cohrence interne et faible couplage externe.La cration d'une catgorie est fonction du regroupement des classes smantiquement proches. Elle se base sur les critres suivants : La finalit : les classes rendent des services de mme nature aux utilisateurs L'volution : sparation des classes mtiers (classes stables) des classes applicatives (classes qui voluent au cours du projet). Le cycle de vie des objets : permet de distinguer; de grer diffremment les classes dont les objets ont des dures de vie trs diffrentes.
Dans notre cadre d'tude, en se basant sur le premier point, GESTCOUR peut tre repartis en trois catgories : le package "CLASSEMENT", le package "COURRIER" et le package "AGENT".
Figure 20. Packages de GESTCOUR Ce dcoupage en package nous permet d'avoir une vision sur le dveloppement de GESTCOUR en terme de module, de rutilisabilit, etc.
44
2.1.2 Dpendance entre catgorie

La dpendance entre catgorie est fonction de la visibilit des catgories et aussi de l'importation de certains lments visibles d'un package par d'autres packages. Le sens de cette importation est rendu visible par les diagrammes de classes d'analyse par catgorie qui montre clairement quelles sont les classses qui sollicitent des classes appartenant d'autres catgorie (exemple de la classe classement qui sollicite la classse courrier) . Deux visibilits sont retenues, savoir : - Public : lment utilisable par tout package reli par une dpendance - Private : lment utilisable que par son package parent. Il faut aussi retenir que les dpendances entre catgories 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 catgorie "COURRIER" importe des donnes de la catgorie "AGENT" lors de l'enregistrement d'un courrier dans le systme. cela pour permettre de savoir qui a enregistrer le courrier (traabilit).
45
La catgorie "CLASSEMENT" tire des donnes de la catgorie "COURRIER" parce qu'elle ne peut classer que des courriers qui ont ts enregistrs dans le systme et applique aussi le mme principe que la catgorie "COURRIER" pour la catgorie "AGENT".
2.2. DEVELOPPEMENT DU MODELE STATIQUE

Le dveloppement du modle statique se base sur les diagrammes des classes participantes (dj prsents selon les cas d'utilisation) et le dcoupage en catgorie. Il vient complter, dtailler et optimiser ces deux prcdentes parties pour produire des diagrammes de classes affins[UML 2 en action]. D'aprs Roques, les classes identifies lors de l'tude des cas d'utilisation puis reparties dans des catgories sont maintenant rtudier, d'une manire dtaille afin de voir s'il faut en ajouter ou en supprimer certaines. Cet ajout ou suppression de classes se base sur les critres suivant : L'limination des classes redondantes c'est--dire les classes reprsentants les mmes concepts (souvent dans le cas d'un progs raliss par plusieurs groupes d'analystes.); L'limination des classes vagues : des classes trop gnrales et pas trop prcises; L' limination des classes la place d'attribut : ces classes expriments des concepts quantifiables; L'limination des classes la place d'un rle : elles expriment un rle dans une association particulire; L'limination des classes reprsentant des acteurs sauf si le systme gre des informations sur l'acteur. L'limination les classes de conception parce qu'elles introduisent trop tt le choix de ralisation. L'limination des classes reprsentant des groupes d'objets (cas des classes associatives). La subdivision des classes ayant trop de responsabilits pour reduire le nombre d'associations, d'attribut ou d'oprations. Ne pas confrondre une entit de sa decription.
46
Aprs avoir affin les classes, l'tude des associations est la deuxime tape.
Dans l'tude des associations, il faut tenir compte des paramtres suivants : - enlever les associations transitives. ressortir les associations dites "Agrgation" ou "composition" identifier leurs rgles de gestion (gestion de la suppression :AddOnly , refus de modification, ) La fin de l'tude des associations, amne la troisime tape qui est celle d'ajouter les attributs. Un attribut est une proprit nomme d'une classe qui dcrit un domaine de valeurs possibles partag par tous les objets de la classe1. Un attribut peut tre simple, driv, un qualificatif, etc. La quatrime tape vient ajouter les oprations. Cette tape est optionnelle. Une opration est un service, un traitement qui peut tre demand n'importe quel objet d'une classe. Valle nous dit qu'il est possible d'identifier les oprations par l'analyse textuelle du cahier de charge et des fiches de description de cas d'utilisation. La dernire tape est l'optimisation de la gnralisation. cette phase, il faut rtudier les classes possdant des caractristiques communes en rapport avec les attributs, les associations et les oprations afin de pouvoir rassembler les attributs et/ou oprations communes dans une super-classe, et de laisser les attributs et/ou oprations dans chaque classe spcifique.
En appliquant toutes ces rgles aux diffrents diagrammes de classes prliminaires par catgories, nous avons les diagrammes de classes suivants :
47
Diagramme de classes de la catgorie "AGENT"

AGENT COMPTE
LogIn : PassWord : CrerCOMPTE () SupprimerCOMPTE () Matricule : Nom : Postnom : Adresse : CrerAGENT () SupprimerAGENT () AttribuerCOMPTE ()
Possde
Figure 22. DCL de la catgorie "AGENT" Diagramme de classes de la catgorie "COURRIER"
Figure 23.
DCL de la catgorie "COURRIER"
Diagramme de classes de la catgorie "CLASSEMENT"
COURRIER - Nordre : - NumRf : - Objet : + Crer ()

0..*
CLASSEUR Plac
1..*
RAYON rang
0..*
- CodeClasseur : 1..1 - Classeur : + Crer () + Selection RAYON ()
- NRayon : + CrerRayon ()
CLASSEMENT - NClassement : - DateClassement : + Crer () + SelectionCOURRIER () + SelectionCLASSEUR ()
Figure 24. DCL de la catgorie "CLASSEMENT" Ce qui nous donne le diagramme de classe global suivant :
48
AGENT TRANSMISSION NTransmission : DateTransmission : DateRception : Orientation : Observation : CrerTransmission () : : : : :

0..*
enregistre Concerne
1..1 0..*
1..1
Matricule : Nom : Postnom : Adresse : CrerAGENT () SupprimerAGENT () AttribuerCOMPTE () CLASSEUR
COMPTE
Possde
LogIn : PassWord : CrerCOMPTE () SupprimerCOMPTE ()
FEEDBACK NumFeedback NumTransmission DateTransmission DateRponse NumCourrierreu CrerFeedback ()
TYPECOURRIER NType : Type : CrerType () ModifierType ()

1..1
COURRIER appartient
0..*
RAYON
1..1
Nordre : NumRf : Objet : Crer ()
0..*
Plac
1..*
CodeClasseur : Classeur : Crer () Selection RAYON ()
rang
0..*
NRayon : CrerRayon ()
CLASSEMENT NClassement : DateClassement : Crer () SelectionCOURRIER () SelectionCLASSEUR ()
COURRIERENTRANT Emetteur : DateReception :
COURRIERSORTANT Destinataire :
Figure 25. Diagramme de classe du modle statique
49
2.3. DEVELOPPEMENT DU MODELE DYNAMIQUE

Le dveloppement du modle dynamique est la troisime tape de l'analyse. C'est une tape qui se base sur la description des cas d'utilisation ralise au cours de la capture des besoins fonctionnels et le modle obtenu lors du dveloppement du modle statique.
2.3.1 Identification et formalisation des scnarios

Lors de la capture des besoins fonctionnels, le scenario reprsentait les interactions entre le systme et ses acteurs, et le systme tait vu comme une bote noire. Dans le modle dynamique, le systme est clat. Roques retient plusieurs types de scnarios, savoir : nominaux : ces scnarios ralise les post-conditions du cas d'utilisation d'une faon naturelle et frquente. Alternatifs : ils remplissent les post-conditions mais prenant des chemins rares. Aux limites : ils ralisent les post-conditions mais modifient le systme de telle sorte que la prochaine excution du cas d'utilisation provoquera une erreur. D'erreur : ne ralisent pas les cas d'utilisation.
50
Voici la description de certains cas d'utilisation : Le cas dutilisation "GrerCourrierEntrant" (GCE) prsente des scnarios dont les plus importants sont : a. Scnario nominaux GCE-N1 : Cration Courrier GCE-N2 : Annulation Courrier b. Scnario alternatifs GCE-A1 : Modification Courrier par modification du destinataire, de l'objet. c. Scnario dexception GCE-E1 : non validation du courrier suite la saisie d'un Numro de courrier existant. GCE-E2 : non validation du courrier suite au nom respect du format. Formalisation de scnario Scnario : Cration du courrier Lagent saisit le Numro d'ordre. Le contrleur vrifie si ce numro d'ordre na pas dj t attribu. Si cest dj attribu, il affiche un message et demande la modification du numro d'ordre saisi. Lagent saisit le Numro de rfrence du courrier, l'metteur, le destinataire, le rsum du courrier, le type du courrier, le degr de priorit du courrier et une observation. Lagent valide la cration du courrier. Le contrleur enregistre la date et les coordonnes de lagent qui a enregistr le courrier. Pour dcrire ce scnario, nous avons les lignes de vie suivantes : - un acteur Agent, - un courrier cr au cours du scnario : nouveauCourrier, - un objet Courrier,
51
Le scnario GCE_N1 est squence que voici :

Cration Courrier
prsent dans le diagramme de
<<Boundary>>
<<Boundary>>
Agent
Interface d'accueil Activer
Interface Courrier
<<Control>>
<<Entity>>
Controleur
Courrier
Activer Saisir NumOrdre NumOrdre alt

NumOrdre Valide
Rechercher NumOrdre
SaisirCourrier(metteur, Rf, rsum,...) Valider retour l'tape de saisie Courrier alt

Format Ok
Valider Vrifier Format

Nouveau Courrier
Create Courrier
Format Ko
Format incorrect
Format incorrect
NumOrdre Invalide
NumOrdre Existant
Nordre Ko
retour l'tape de saisie NumOrdre
Figure 26. Diagramme de squence 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 systme.
52
En ne retenant que le droulement normal du scnario de cration d'un courrier, nous aurons le diagramme de communication suivant :
<<Boundary>>
Interface Accueil 1: Activer 1.1.: Activer

<<Control>>
2.2: Reseach (NumOrdre)
2.1: NumOrdre 2: Saisir NumOrdre Agent 3: SaisirCourrier(Rf, Objet, ...) 4: Valider

<<Boundary>>
Controleur
<<Entity>>
Courrier
4.1: Valider 4.2: Create Courrier (NOrdre, Rf,...)

Nouveau Courrier
Interface Courrier
Figure 27. Diagramme de communication de GCE_N1 Le cas dutilisation "GrerClassement" (GCL) ralise des scnarios dont les plus importants sont : a. Scnario nominaux GCL-N1 : Cration Classement GC-N2 : Annulation Classement b. Scnario alternatifs GCL-A1 : Cration d'un classeur. GCL-A2 : Cration d'un rayon c. Scnario dexception GCL-E1 : non validation du courrier suite la saisie d'un Numro de courrier inexistant. GCL-E2 : non validation du courrier suite la saisie d'un numro de classement existant.
53
Formalisation de scnario Scnario : Enregistrement d'un classement Lagent saisit le Numro de classement. Le contrleur vrifie si ce numro de classement na pas dj t attribu. Si cest dj attribu, il affiche un message et demande la modification du numro saisi. Lagent saisit le Numro d'ordre du courrier classer, Le contrleur vrifie si ce numro d'ordre existe. S'il n'existe pas, il affiche un message demandant la saisie d'un numro d'ordre existant, l'agent saisit le code du classeur o sera class le courrier Lagent valide le classement. Le contrleur enregistre la date de classement du courrier. Les lignes de vie suivantes dcrivent le scnario : un acteur Agent, un objet courrier, un objet classeur un objet Classement une nouvelle instance de classement
54
Le scnario GCL_N1 donne le diagramme de squence que voici :

Cration Classement
Agent
<<Boundary>>
<<Boundary>>
<<Control>>
<<Entity>>
<<Entity>>
<<Entity>>
Interface d'accueil
Interface Classement
Controleur
Classement Courrier
Classeur
Activer Activer Saisir NClassement

alt
NClassement Valide
NClassement
Reseach
Saisir NOrdre
alt
N Ordre Ok
NOrdre Courrier(NOrdre,,...)
Reseach NOrdre
Affichage courrier(NOrdre, ...) Saisir CodeClasseur

alt
CodeClasseur Ok
CodeClasseur
Reseach
Classeur(Nom,...)
Affichage NomClasseur Valider

CodeClasseur Ko
Nouveau Classement
Valider
Create
opt
[Cration Classeur]
Crer Classeur
Crer classeur
N Ordre Ko
CourrierInexistant
CourrierInexistant
N Classement Invalide
ClassementExistant
ClassementExistant
retour la saisie N Classement
Figure 28. Diagramme de squences de GCL_N1 La cration d'un classeur est une option pour l'agent parce que l'agent peut ne pas crer de classeur. Cela ne modifiera en rien le processus normal. Le scnario de cration d'un classeur conduit une manipulation de rayon. C'est dans ce scnario (cration d'un classeur) que crer un rayon est une option.
55
Le droulement normal du scnario de cration d'un classement donne le diagramme de communication suivant :
<<Entity>>
<<Entity>>
Classeur
3.2: Reseach
Courrier
<<Boundary>>
Interface Accueil 1: Activer 2: Activer
4.2: Reseach
2.3: Reseach
<<Entity>> <<Control>>
2.2: NClassement 2.1: SaisirNclassement 3: saisir NOrdre 3.1: NOrdre
Classement
Controleur 5.2: Create
Agent
4.1: CodeClasseur 5.1: Valider
4: saisirCodeClasseur 5: Valider
<<Boundary>>
Nouveau classement
Interface Classement
Figure 29. Diagramme de communication de GCL_N1 Le cas dutilisation "GrerTransmission" (GT) ralise des scnarios dont les plus importants sont : d. Scnario nominaux GT-N1 : Cration Transmission GT-N2 : Annulation Transmission e. Scnario dexception GT-E1 : non validation du courrier suite la saisie d'un Numro de courrier inexistant. GT-E2 : non validation du courrier suite la saisie d'un numro de transmission existant.
56
Formalisation de scnario Scnario : Enregistrement d'une transmission Lagent saisit le Numro de Transmission. Le contrleur vrifie si ce numro de transmission na pas dj t attribu. Si cest dj attribu, il affiche un message et demande la modification du numro saisi. Lagent saisit le Numro d'ordre du courrier transmettre, Le contrleur vrifie si ce numro d'ordre existe. S'il n'existe pas, il affiche un message demandant la saisie d'un numro d'ordre existant, l'agent saisit le destinataire puis valide. Le contrleur enregistre la date de transmission ainsi que les coordonnes de l'utilisateur. Les lignes de vie suivantes dcrivent le scnario : un acteur Agent, un objet courrier, un objet Transmission une nouvelle instance de transmission
57
Le scnario GT_N1 se formalise dans le diagramme de squence comme suit :

Transmission Courrier
Agent
<<Boundary>>
<<Boundary>>
<<Control>>
<<Entity>>
<<Entity>>
Interface d'accueil Interface Transmission
Controleur
Transmission
Courrier
Activer Activer Saisir NTransmission

alt
NTransmission Valide
NTransmission
Reseach
Saisir NOrdre
alt
N Ordre Ok
NOrdre Courrier(NOrdre,,...)
Reseach NOrdre
Affichage courrier(NOrdre, ...) Saisir Destinataire Valider Valider Enreg Date Create
Nouvelle Transmission
N Ordre Ko
CourrierInexistant
CourrierInexistant
N Transmission Invalide
TransmissionExistant
NTransExistant
Figure 30. Diagramme de squence de GT_N1 Le droulement normal du scnario de cration d'une transmission se reprsentera dans le diagramme de communication suivant :
58
<<Entity>>
Courrier 3.2: Reseach

<<Boundary>>
Interface Accueil 1: Activer 2: Activer 2.1: SaisirTransmission Agent 3: SaisirNordre 4: Valider

<<Boundary>>
2.3: Reseach 2.2: NTransmission 3.1: NOrdre

<<Control>>
Controleur
<<Entity>>
Transmission
4.1: Valider
4.2: Create
Nouvelle transmission
Interface Transmission
Figure 31. Diagramme de communication de GT_N1 Le cas dutilisation "GrerFeedback" (GF) ralise des scnarios dont les plus importants sont : f. Scnario nominaux GF-N1 : Cration Feedback g. Scnario dexception GT-E1 : non validation du courrier suite la saisie d'un Numro de courrier inexistant et non en attente de rponse.
Formalisation de scnario Scnario : Enregistrement d'un Feedback Lagent saisit le Numro du courrier qui attend une rponse, Le contrleur vrifie si ce numro d'ordre existe et attend une rponse. Si ce n'est pas le cas, il affiche un message demandant la saisie d'un numro d'ordre en attente de rponse, Lagent saisit le Numro d'ordre du courrier (FeedBack) puis valide, Le contrleur enregistre le Numro d'ordre de la rponse.
59
Les lignes de vie suivantes dcrivent le scnario : - un acteur Agent, - un objet Liste des courriers Feedback, - un objet FeedBack Le scnario GT_N1 donne le diagramme de squence suivant :
Feedback
Agent
<<Boundary>>
<<Boundary>>
<<Control>>
<<Entity>>
<<Entity>>
Interface d'accueil Activer
Interface Feedback
Controleur
ListeCourrierFeedback
Feedback
Activer Saisir NumOrdre NumOrdre Rechercher NumOrdre alt

NumOrdre Valide
SaisirCourrier(Feedback) Valider Valider Update delite
NumOrdre Invalide
NumOrdre Inexistant
NordreKo
Figure 32. Diagramme de squence de GF_N1
Le droulement normal du scnario de validation d'une rponse courrier donne le diagramme de communication suivant :
60
<<Entity>>
3.3: Update
<<Boundary>>
Feedback 2.3: Reseach
Interface Accueil 1: Activer 2: Activer 2.2: NumOrdre

<<Control>>
Controleur 2.1: Saisir NumOrdre Agent 3: SaisirFeedback 3.1: Valider <<Boundary>> Interface Feedback 3.2: Valider 3.4: Delete
<<Entity>>
ListeCourrierFeedback
Courrier
Suppression de l'instance sur la liste des courriers en attente de rponse
Figure 33. Diagramme de communication de GF_N1
2.3.2 Construction et validation des diagrammes d'tats

D'aprs Pascal Roques, aprs la formalisation des scanrios, la connaissance de lensemble des interactions entre objets permet de se reprsenter les rgles de gestion dynamique du systme. Il faut cependant se focaliser sur les classes aux comportements les plus riches de manire dvelopper prcisment certaines de ces rgles dynamiques. Cette vue locale dun objet, dcrivant comment il ragit des vnements en fonction de son tat courant et passe dans un nouvel tat, est reprsente graphiquement sous forme dun diagramme dtats. Il poursuit en disant qu'un tat reprsente une situation durant la vie dun objet pendant laquelle : il satisfait une certaine condition ; il excute une certaine activit ; ou bien il attend un certain vnement. Un objet passe par une succession dtats durant son existence. Un tat a une dure finie, variable selon la vie de lobjet, en particulier en fonction des vnements qui lui arrivent. Franck Valle nous dit qu'en UML, un vnement spcifie quil sest pass quelque chose de significatif, localis dans le temps et dans lespace.
61
UML propose de distinguer plusieurs sortes dvnements : la rception dun signal envoy par un autre objet, ou par un acteur. Lenvoi dun signal est en gnral asynchrone ; lappel dune opration (call event) sur lobjet rcepteur. Lvnement dappel est en gnral synchrone ; le passage du temps (time event), qui se modlise en utilisant le mot-cl after suivi dune expression reprsentant une dure, dcompte partir de lentre dans ltat courant ; un changement dans la satisfaction dune condition (change event). On utilise alors le mot-cl when, suivi dune expression boolenne. Lvnementde changement se produit lorsque la condition passe vrai. Il est alors question de se poser une question fondamentale; savoir : Comment trouver les tats dune classe ? Pascal Roques dit qu'il y a trois dmarches complmentaires qui peuvent tre mises en uvre; savoir : la recherche intuitive qui repose sur lexpertise mtier. 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) ; ltude des attributs et des associations de la classe peut donner des indications prcieuses : il faut cherchez des valeurs seuils dattributs qui modifient la dynamique, ou les comportements qui sont induits par lexistence ou labsence de certains liens ; une dmarche systmatique peut galement tre utilise : classe par classe, il faut cherchez le diagramme dinteraction le plus reprsentatif du comportement des instances de cette classe, puis associez un tat chaque intervalle entre vnements mis ou reus par une instance et placez les transitions. Reproduire ensuite cette dmarche avec tous les scnarios faisant intervenir des instances de la classe, afin dajouter 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.
62
Il poursuit en disant, pour laborer le diagramme dtats, il faut utiliser une approche Incrmentale fonde sur les tapes suivantes : reprsentez dabord la squence dtats dcrivant le comportement nominal dun objet, de sa naissance sa mort, avec les transitions associes ; ajoutez progressivement les transitions correspondant aux comportements alternatifs ; puis intgrez, de la mme faon, celles concernant les comportements derreur ; compltez en indiquant les effets sur les transitions et les activits dans les tats ; structurez en sous-tats, si le diagramme est devenu trop complexe. Sur base de ces critres, 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 Reu : est l'tat initial d'un courrier sa rception. Mais cet tat n'est pas formalisable parce qu'tant un tat abstrait dans le systme 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 systme. - La transmition ou diagramme. le classement d'un courrier sont les tats finals de ce
63
Pascal Roques afirme qu'prs la contruction du diagramme d'tats il faut le valider avec les diagrammes dinteractions en tudiant la conplmentarit entre les diagrammes d'interaction (squence et communication) et les diagrammes d'tats. Cette complmentarit est fondamentale. En effet, les diagrammes dtats apportent prcision et exhaustivit, et permettent de valider et de complter les diagrammes dinteractions. Ils peuvent galement inciter crer de nouveaux diagrammes dinteractions pour complter ceux qui existent dj. Il faut toutefois vrifier que les diagrammes dtats des classes impliques dans les diagrammes dinteractions prennent bien en compte tous les scnarios dcrits, et qui plus est de faon correcte.
2.3.3 Confrontation des modles statique et dynamique

Aprs avoir eu les relations diverses qui existent entre les principaux concepts du modle statique (objet, classe, association, attribut et opration) et les principaux concepts dynamiques (message, vnement, tat et activit), Valle nous demande de synthtiser les correspondances les plus importantes; savoir : un message peut tre un appel dopration sur un objet (le rcepteur) par un autre objet (lmetteur) ; un vnement ou un effet sur une transition peuvent correspondre lappel dune opration ; une activit dans un tat peut concerner lexcution dune opration complexe ou dune succession doprations ; un diagramme dinteractions met en jeu des objets (ou des rles) ; une opration peut tre dcrite par un diagramme dinteraction ou dactivit; 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 paramtre dun message peut tre un attribut ou un objet entier.
Cette confrontation nous permet de dfinir certains attributs et/ou oprations qui n'ont pas t trouv lors de l'laboration du modle statique afin d'avoir un diagramme de classes complt.
64
En rapport avec ces principes, nous pouvons retenir les points suivant :
Enregistrer Traiter
Courrier reu
Courrier enregistr
Courrier annot
Traiter
Si annotation = Class
Si annotation = Suspend
Modle dynamique
Si annotation = rorient
Courrier classer
Courrier rorient Courrier en suspend
Transmission
Courrier transfr
TYPECOURRIER - NType : - Type : + CrerType () + ModifierType ()

1..1 appartient 0..*
COURRIER - Nordre : - NumRf : - Objet : + Crer () 1..1 Concerne 0..* COURRIERSORTANT - Destinataire :
TRANSMISSION NTransmission DateTransmission DateRception Orientation Observation : : : : :
+ CrerTransmission () COURRIERENTRANT - Emetteur : - DateReception :
Modle statique
Figure 35. Diagramme de confrontation De la confrontation des deux modles de GESTCOUR nous remarquons que les tats Courrier rorient et courrier transmis correspondent une opration de cration d'une transmission dans le modle statique. L'tat courrier enregistr correspond l'opration de cration d'un courrier dans la table Courrier. D'o, notre diagramme de classes obtenu au niveau du modle statique est complt.
65
2.4. CONCEPTION GENERIQUE

D'aprs Roques, la conception gnrique consiste dvelopper la solution qui rpond aux spcifications techniques obtenues pendant la capture des besoins techniques. Elle est gnrique parcequ'elle est entirement indpendante des aspects fonctionnels spcifis en branche gauche. Dans la conception gnrique il faut dvelopper : - la vue logique du systme en organisant le modle logique tout en tudiant les contraintes de rutilisation. - la vue d'exploitation en organisant les composants du systme. - La vue de la configuration logicielle
2.4.1 Modle logique de conception technique

Le modle logique de conception technique est un modle qui organise les classes par packages qui reprsentent les frameworks dvelopps pour rsoudre les problmes purement techniques. Le modle logique est organis suivant les dpendances qui s'tablissent entre frameworks techniques. Un Framework est un rseau de classes qui collaborent la ralisation d'une responsabilit qui dpasse celle de chacune des classes qui y participent [UML-UG 99].
2.4.2 Modle d'exploitation de conception technique

Pascal Roques dit que pour tablir un modle d'exploitation, nous avons besoin de distinguer deux niveaux de composant : les composants d'exploitation reprsents au niveau de la capture des besoins techniques, et les composants qui servent la configuration logicielle : "executable" reprsente un excutable capable de fonctionner sur une des machines du systme physique. Cette caractristique en fait un composant d'exploitation ; "library" correspond une librairie statique ou dynamique. Seules les librairies dynamiques peuvent tre assimiles un composant d'exploitation dans la mesure o elles sont explicitement installes par l'ingnieur d'exploitation La vue des composants d'exploitation vient complter la conception gnrique. Elle permet d'identifier les premiers lments du systme
66
logiciel et dfinit les rgles de dploiement et d'intgration des diffrentes composantes. La vue d'exploitation prcise par exemple l'ordre dans lequel l'exploitant (acteur technique) doit initialiser les applications en fonction de leurs dpendances rciproques. GESTCOUR tant un systme qui ne prsente qu'une seule application, le devloppement de ces diffrentes vues n'est pas ncessaire.
2.4.3 Modle de configuration logicielle de la conception technique

Jacobson, cit par Roques, dit qu'En UML, un sous-systme correspond un regroupement d'lments de modlisation dont le but est de fournir une mme unit de comportement au sein du systme.
Un sous-systme se caractrise donc par un procd de fabrication indpendant. Un sous-systme de caractrise en outre par un numro de version qui fixe son tat d'volution au sein de la construction globale du systme. Le modle de configuration logicielle n'a d'intrt que pour des systmes consquents. Lorsqu'il s'agit de raliser des applications qui, terme, ne produisent qu'un ou deux composants de dploiement, l'expression d'un modle de configuration logicielle est facultative. D'o, pour GESTCOUR ce modle ne sera pas ralis.
2.4.4 Dveloppement d'un prototype

Un prototype est un modle. Le dveloppement d'un prototype doit conduire rpondre aux fonctionnalits techniques demandes par le systme. Pour ce faire, il faut rpondre la question suivante :" Que mettre dans mon prototype ?" Le prototype de GESTCOUR doit au moins valider : le mcanisme CRUD des objets (Crate, Retrieve, Update, Delete); l'intgrit des donnes; la synchronisation entre Crystal Report et l'application.
67
CHAP III: CONCEPTION OBJET

3.1. CONCEPTION PRELIMINAIRE
La conception prliminaire est ltape la plus dlicate du processus 2TUP. Elle ralise la fusion des tudes fonctionnelles et techniques.
3.1.1 Conception du modle de dploiement

Le dploiement dune solution client /serveur se traduit sur la dfinition des postes de travail. Le poste de travail reprsente un ou plusieurs acteurs pouvant tre localiss sur une machine dun type particulier et remplissant une fonction identifie dans lentreprise. Un poste de travail ne reprsente pas toujours une machine physique, mais peut consister en plusieurs machines, condition qu'elles donnent lieu au mme type de dploiement. Les postes de travail de GESTCOUR seront repartis de la manire suivante :
Node_9
DMZ
<<Serveur>>
<<Serveur>>
Messagerie
Web
LAN
<<Serveur>>
Proxy
<<Serveur>>
<<Poste>>
Imprimante
GESTCOUR
Dpartemental
<<Poste>>
Classement
<<Poste>>
<<Poste>>
Administration
Secrtaire
Figure 36. Modle de dploiement dtall 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
68
serveur de messagerie et le serveur web sont dans la zone de dmilitarise. Il sont accessible par tout le monde tandis que la partie du bas n'est accssible que par les utilisateurs de GESTCOUR.
3.1.2 Elaboration du modle d'exploitation

Le modle d'exploitation commence la phase de la conception gnrique. A partir du modle de dploiement obtenu, il est possible de le complter en fonction des machines et des postes de travail, tout en intgrant les besoins exprims en analyse. Le modle d'exploitation va donc dfinir les applications installes sur les postes de travail, les composants mtier dploys sur les serveurs et les instances de bases de donnes implantes sur des serveurs afin d'optimiser la distribution et ventuellement numrer les interfaces utilisateurs . Dans le cadre de GESTCOUR, nous avons le diagramme d'exploitation suivant :
Node_9
DMZ
<<Serveur>> Messagerie
<<Application>>
<<Serveur>> Web
<<application>>
OutLoook
Application
LAN
<<Serveur>> Proxy
<<application>>
Zone Alarm, Anti-Spay, Av ast
LAN
Imprimante
<<Application>> LAN
<<Serveur>> GESTCOUR
<<BD>>
LAN
Imprimante
LAN
LAN
<<Poste>> Dpartemental
<<Application>>
GESTCOUR
Courrier, Mozilla
LAN LAN
<<Poste>> Classement
<<Application>>
<<Poste>> Administration
<<Application>>
<<Poste>> Secrtaire
<<Application>>
Classement, Mozilla
Courrier, Mozilla
Feedback, Mozilla
Figure 37. Modle d'exploitation GESTCOUR Nous avons repartis les diffrents composants de GESTCOUR en fonction des fonctions de chaque utilisateur tout en respectant la dfinition des postes (le diagramme de dploiement dtaill) dj tablie.
69
Ensuite tous les packages tablis au niveau du dcoupage en catgorie du systme deviennent des composants mtier du modle d'exploitation. Une premire bauche des interfaces peut tre dfinie en termes de regroupement de responsabilit.
<<Application>>
IAgent
Agent
<<BD>> GESTCOUR
ICourrier
<<Application>> Courrier
IFeedback
<<Application>> Classement
IClassement
Figure 38. Consolidation de l'application GESTCOUR Ce schma est illustr dans le tableau suivant : Composant Description des responsabilits Cration, modification, transmission des instances ICourrier des entits courrier et transmission Validation des courriers ayant reus de rponse de IFeedBack l'entit Feedback, relance des courriers en attente de rponse Cration, modification d'un classement de l'entit Classement, d'un classeur de l'entit Classeur. IClassement Modification du placement d'un classeur dans un rayon. Cration, suppression agent de l'entit Agent, IAgent attribution d'un compte. Cration, suppression des comptes de l'entit Compte Tableau 4 : Tableau des composants Interface
Courrier
Classement
Agent
3.1.3 Dveloppement du modle logique de conception

Le dveloppement du modle logique de conception dveloppe les classes ncessaires au codage. Une catgorie de conception est une catgorie qui organise des classes techniques et contribue la rutilisation et
70
l'optimisation d'un systme dvelopper. C'est ce niveau que le dcoupage du systme en sous-systme peut se raliser. Il s'agit d'tudier chaque package (composant) indpendamment des autres, par rapport aux 5 couches logiques. Par exemple : les composants de GESTCOUR aurons, pour la couche prsentation, les catgories suivantes :
<<layer>>
Prsentation
<<catgorie>>
<<catgorie>>
Courrier
Transmission
<<catgorie>>
<<catgorie>>
Agent
Classement
Figure 39. Catgories de la couche prsentation Le composant "Courrier" a deux catgories dans la couche prsentation : la catgorie Courrier et la catgorie transmission.
3.1.4 Cration des interfaces des catgories

Les interfaces de catgories se construisent partir des interfaces dj identifies des composants d'exploitation. Leur dfinition ncessite d'tre prcise et doit prendre en compte les oprations identifies dans le modle d'analyse. Ces oprations sont reparties sur les couches application, mtier ou accs aux donnes en fonction de leur spcialit.
71
Le tableau ci-dessous donne quelques oprations d'analyse de GESTCOUR Opration d'analyse
Description
Positionnement
Crer un compte pour un agent, ce qui dclenche la AttribuerCOMPTE vrification de l'existence de cet agent. VrifierCourrier Vrification de l'existence du courrier. Cette opration est dclenche par la saisie du nordre du courrier. Tableau 5 :
C'est un service applicatif du composant Agent qui entre dans la dfinition de l'interface IAgent. C'est un service applicatif du composant Courrier qui en entre en compte dans la dfinition de l'interface ICourrier. Opration d'analyse
Les oprations de la couche Mtier du composant Classement est : la validation du classement, la validation (cration) du classeur et la validation du rayon. Pour la couche Applicative, nous avons les oprations suivantes : la recherche du courrier, la recherche du classeur, la slection du courrier, la selection du classeur, la recherche du rayon et la selection du rayon.
<<Interface>> IClassement
Commandes de la couche Applicative sur l'interface du composant Classement
CmdRechercherCourrie
<Interface> IClassement
Composant Classement
CmdRechercherRayon CmdSelectionnerRayon CmdSelectionnerCourrier CmdRechercherClasseur CmdSelectionnerClasseur
Figure 40. Vue des commandes de la couche Applicative :: Classement
3.1.5 Mise au point de la prsentation des applications

La mise au point de la prsentation des applications est l'tape qui structure la prsentation des applications ainsi que des interfaces qui permettent aux diffrentes catgories de communiquer entre elles. Elle donne une premire maquette des IHM laborer.
72
GESTCOUR aura donc, pour une premire maquette, les interfaces suivants : Courrier, Transmission, Classement et Agent.
3.1.6 Organisation de la configuration logicielle

La conception prliminaire s'achve par la dfinition des units de fabrication du logiciel. Organiser la configuration logicielle revient consolider le modle logique avec les rutilisations de code dtectes et de complter la configuration logicielle. Chaque catgorie se transforme en un sous-systme de configuration logicielle ou Module. Pour GESTCOUR, nous aurons les sous-systmes suivants : un sous-systme principal de dmarrage de l'application (Submain) un sous-systme de connexion (ouverture et fermeture de (s) table (s)) la base de donnes un sous-systme de gestion de FeedBack,
3.2. CONCEPTION DETAILLEE

Pascal Roques et Franck Valle dfinissent la conception dtaille comme tant une activit qui sinscrit dans lorganisation dfinie par la conception prliminaire. Ils poursuivent en disant que le modle logique y est particulirement important dans la mesure o cest en conception dtaille que lon gnre le plus gros volume dinformations. Il est ainsi possible de confier les catgories des personnes diffrentes, qui pourront travailler indpendamment les unes des autres. La conception dtaille sappuie donc sur les catgories de conception organises la fois suivant les frameworks techniques et les regroupements propres au mtier. Nous devons alors construire les classes, les vues dIHM, les interfaces, les tables et les mthodes qui vont donner une image prte coder de la solution. Et en dernier lieu, nous devons prciser le contenu des soussystmes de manire complter la configuration logicielle. Toutes les questions relatives lagencement et aux dtails de la solution doivent tre modlises ainsi que les interrogations restantes concernent la bonne utilisation des langages et des outils de dveloppement.
73
Le niveau dabstraction vis par ltape de conception dtaille est davoir une ide la plus prcise possible pour la fabrication et lassemblage des sous-systmes de configuration logicielle. La conception dtaille prcde la phase de codage.
3.2.1 Conception dtaille du modle logique

Le micro-processus de conception du modle logique concerne la dfinition des classes implmenter afin de pouvoir produire un diagramme de classes dtailles. La conception dtaille est une activit centr sur le modle logique qui combine les diagrammes UML suivant : principalement les diagrammes de classes pour prciser la structure des classes de dveloppement, les diagrammes d'interactions pour prciser les communications entre objets, et les diagrammes d'activits pour exprimer les algorithmes des mthodes.
Le micro-processus est une itration des tapes suivantes : la conception des classes consiste transformer des concepts provenant de lanalyse, tels que les mtaclasses ou les classes tats parallles, en techniques disponibles avec les langages et les outils de dveloppement. La conception des associations dfinit la faon dexploiter chaque association et les techniques qui seront employes dans le codage. La conception des attributs ncessite essentiellement didentifier les structures de donnes, les itrations et dautres types complexes permettant de reprsenter les attributs danalyse avec le langage utilis. La conception des oprations permet de dterminer le contenu des mthodes complexes et didentifier en cascade de nouvelles classes et oprations dans la catgorie. La Validation du modle. A la sortie de ce cycle le modle donne limage prte coder de ses composants de configuration logicielle. Appliquer ces phases GESTCOUR, nous avons le diagramme de classes dtaille suivant :
74
AGENT TRANSMISSION + + + + + + : String : String : Date : Date : String Object String String NTransmission DateTransmission DateRception Orientation Observation CrerTransmission GetNOrdre () LetNOrdre () : String : Date : Date : String : String () : Object : String : String + + + + + + + Matricule : String Nom : String Postnom : String Adresse : String CrerAGENT () : Object GetLogIn () : String LetLogIn () : String GetPassword () : String LetPassword () : String CLASSEUR + + + CodeClasseur : Classeur : CrerClasseur () GetNRayon () LetNRayon () String String : Object : Byte : Byte
0..*
COMPTE
Possde
0..*
Concerne
1..1
+ LogIn : String + PassWord : String + CrerCOMPTE () : Object
enregistre
1..1 0..*
FEEDBACK + + + + + + NumFeedback NumTransmission DateTransmission DateRponse NumCourrierreu CrerFeedback () : GetNOrdre () : LetNOrdre () :
COURRIER TYPECOURRIER + NType : String + Type : String + CrerType () : Object

1..1
RAYON rang
1..1
appartient
0..*
+ + + + -
Nordre : String NumRf : String Objet : String CrerCourrier () : Object GetType () : String LetType () : String
0..*
Plac
1..*
+ NRayon : Byte + CrerRayon () : void
CLASSEMENT - NClassement : String - DateClassement : Date + CrerClassement () : Object + GetNOrdre () : String + LetNOrdre () : String + GetCodeClasseur () : String + LetCodeClasseur () : String
COURRIERENTRANT + Emetteur : String + DateReception : Date
COURRIERSORTANT + Destinataire : String
Figure 41. Diagramme de classes dtailles
75
Etant dans le modle logique, chaque table du schma ci-haut sera reparti selon les couches logiques. Une classe gre ainsi les activits et les transitions attaches ltat quelle reprsente. Voici quelques uns des diagrammes Etats que nous avons conus :
Interface_COURRIERSORTANT
+ CrerCourrier () : Object
EtatCrationCourrierEntrant
+ + + + + + + + + + + + + + + + + + NOrdre : String NumRf : String Objet : String Emetteur : String DateReception : Date CreateCourrier () : Object GetType () : String LetType () : String GetNOrdre () : String LetNOrdre () : String GetNumRf () : String LetNumRf () : String GetObjet () : String LetObjet () : String GetEmetteur () : String LetEmetteur () : String GetDateReception () : Date LetDateReception () : Date
Interface_COURRIERENTRANT
+ CrerCourrier () : Object
COURRIER + + + + Nordre : String NumRf : String Objet : String <<Implement>> CrerCourrier () : Object GetType () : Typecourrier LetType () : Typecourrier
COURRIERENTRANT + Emetteur : String + DateReception : Date
EtatCrationCourrierSortant
COURRIERSORTANT + Destinataire : String + + + + + + + + + + + + + + + NOrdre : String NumRf : String Objet : String Destinataire : String CreateCourrier () : Object GetType () : String LetType () : String GetNOrdre () : String LetNOrdre () : String GetNumRf () : String LetNumRf () : String GetObjet () : String LetObjet () : String GetDestinataire () : String LetDestinataire () : String
Figure 42. Classes Courrier et tats Les classes CourrierEntrant et CourrierSortant qui se gnralise dans la classe Courrier dlguent la gestion de leurs tats aux interfaces CourrierEntrant et CourrierSortant et leurs implmentations aux tats de cration ci-haut.
76
La classe classement dlgue la gestion de ses tats linterface classement et son implmentation.
Interface_CLASSEMENT
EtatCration
+ CrerClassement () : Object
CLASSEMENT + NClassement : String + DateClassement : Date + <<Implement>> CrerClassement () GetNOrdre () LetNOrdre () GetCodeClasseur () LetCodeClasseur ()
+ + + + + + + + + + +
NClassement : String DateClassement : Date CreateClassement () : Object GetNOrdre () : String LetNOrdre () : String GetCodeClasseur () : String LetCCodelasseur () : String GetNClassement () : String LetNClassement () : String GetDateClassement () : String LetDateClassement () : String
Figure 43. Classe Classement et tats La classe Transmission dlgue la gestion de ses tats linterface Transmission et son implmentation.
EtatCration
+ + + + + + + + + + + + + + + + + + NTransmission : String DateTransmission : Date DateRception : Date Orientation : String Observation : String CreateTransmission () : Object GetNOrdre () : String LetNOrdre () : String GetNTransmission () : String LetNTransmission () : String GetDateTransmission () : Date LetDateTransmission () : Date GetDateRception () : Date LetDateRceptionnt () : Date GetOrientation () : String LetOrientation () : String GetObservation () : String LetObservation () : String
TRANSMISSION + + + + + + NTransmission : String DateTransmission : Date DateRception : Date Orientation : String Observation : String <<Implement>> CrerTransmission () GetNOrdre () LetNOrdre ()
Interface_TRANSMISSION
+ CrerTransmission () : Object
Figure 44. classe Transmission et ses tats Les tats de la classe Feedback dlge ses tats linterface Feedback et son implmentation.
77

Interface_FEEDBACK
+ CrerFeedback () : void
EtatCrerFEEDBACK FEEDBACK + + + + + + NumFeedback : NumTransmission : DateTransmission : DateRponse : NumCourrierreu : <<Implement>> String String Date Date String CrerFeedback () GetNOrdre () LetNOrdre () + + + + + + + + + + + + + + + + NumFeedback : String NumTransmission : String DateTransmission : Date DateRponse : Date NumCourrierreu : String ValiderFeedback () GetNOrdre () LetNOrdre () GetNumFeedback () LetNumFeedback () GetDateTransmission () LetDatetransmission () GetDateRponse () LetDateRponse () GetNumCourrierreponse () LetNumCourrierreponse ()
: : : : : : : : : : :
void String String String String Date Date Date Date String String
Figure 45. classe Feedback et ses tats A partir de cette dcomposition, nous avons les Etats qui seront placs dans la couche prsentation (interface), la couche mtier (implmentation) et une ide sur la couche persistance.
3.2.2 Conception de la couche prsentation

D'aprs Valle, la premire tape de conception d'une IHM concerne la dfinition visuelle des fnetres ou des pages. L'existence d'un modle objet d'analyse permet d'influencer cette conception : partir d'un diagramme de classes, un gnrateur de code pourait gnrer des fnetres ou des pages pour l'affichage et la saisie de chaque lment du modle. Une fentre ou plusieurs pages pour chaque classe afin d'en diter les instances : cration, modification des attributs et des relations, simple consultation et suppression; Une fentre ou plusieurs pages pour certaines associations complexes afin d'en diter les liens. Ainsi donc, dans notre cas dtude, selon les Classes Etats interfaces trouvs grace Power AMC, nous avons les fentres raliser dans le langage choisi (Visual Basic 6.0). Notons cependant qu'il faut parfois doubler les interfaces car l'affichage (visualisation) et la saisie (cration, modification, suppression) utilisent des techniques diffrentes.
78
Fentre CourrierEntrant
Interface_COURRIERENTRANT
+ CrerCourrier () : void
Figure 46. IHM de la classe interface CourrierEntrant Fentre Classement

Interface_CLASSEMENT
+ CrerClassement () : Void
Figure 47. IHM de la classe interface Classement
79
Fentre Feedback
Interface_FEEDBACK
+ CrerFeedback () : void
Figure 48. IHM de la classe interface Feedback
3.2.3 Conception de la couche persistance

La ralisation dun stockage des instances varie suivant le mode de stockage retenu. Dans tous les cas, la ralisation dun modle objet facilite la maintenance des donnes stockes. D'aprs Pascal Roques, il existe aujourdhui plusieurs modes de stockage possibles. - Le systme de fichiers est le moyen le plus rudimentaire de stockage. Cependant, il ne permet que de lire ou dcrire une instance par des moyens externes lapplication et il na aucune capacit administrer ou tablir des requtes complexes sur les donnes. - La base de donnes relationnelle ou SGBDR est un moyen dj plus sophistiqu. Il existe aujourdhui une large gamme de SGBDR rpondant des
80
besoins de volume, de distribution et dexploitation diffrents. Le SGBDR permet dadministrer les donnes et dy accder par des requtes complexes. - La base de donnes objet ou SGBDO constitue la mthode la plus labore de toutes. Cette technique lude la conception dun stockage des donnes puisquelle permet de stocker et dadministrer directement des instances de classe. - La base de donnes XML ou SGBDX est un concept mergeant qui rpond au besoin croissant de stocker des documents XML sans risque daltration de ces derniers. Pascal Roques dit que la conception du stockage des donnes consiste tudier sous quelle forme les instances sont sauvegardes sur un support physique. Pour notre cas dtude, nous retenons le mode de stockage le plus rpondue; le SGBDR. La ralisation d'un modle relationnelle ne sera pas directe vu que les modles dvelopps dans la conception sont des modles objets d'o il faut utiliser des principes de rapprochement objet-relationnel. Le passage du Modle Objet au Modle Relationnel Lutilisation dun SGBDR impose un changement de reprsentation entre la structure des classes et la structure des donnes relationnelles; les deux structures ayant des analogies, des quivalences [Blaha 97]. Une classe dfinit une structure de donnes laquelle souscrivent des instances; elle correspond donc une table du modle relationnel : chaque attribut donne lieu une colonne, chaque instance stocke ses donnes dans une ligne et son OID sert de cl primaire. Selon le type d'association il y a cration de (s) colonne (s) (trangres ) 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 frquemment ce cas pour les attributs reprsentant une structure de donnes. Un type complexe peut tre conu ; soit avec plusieurs colonnes, chacune correspondant un champ de la structure ; soit avec une table spcifique dote dune cl trangre pour relier les instances aux valeurs de leur attribut complexe.
81
UML dfinit spcifiquement un strotype table pour reprsenter la table dun schma relationnel. En appliquant les rgles de transformation GESTCOUR, nous avons les relations suivantes : La conception du stockage des classes Courrier, CourrierEntrant et CourrierSortant en rapport avec la rgle d'hritage dfinit par Pierre Alain Muller ainsi que pour tous les autres types d'associations et de multiplicits des classes, nous donne le code SQL suivant :
CREATE TABLE TYPECOURRIER (NType String, Type String NOT NULL) PRIMARY KEY NType; CREATE TABLE COURRIER (NOrdre String, NumRf String NOT NULL, Objet StringNOT NULL, NType String) PRIMARY KEY NOrdre FOREING KEY NType REFERENCES TYPECOURRIER; CREATE TABLE COURRIERENTRANT(NOrdre String, Expditeur String NOT NULL, DateRception Date) PRIMARY KEY NOrdre FOREING KEY NOrdre REFERENCES COURRIER; CREATE TABLE COURRIERSORTANT(NOrdre String, Destinataire String NOT NULL) PRIMARY KEY NOrdre FOREING KEY NOrdre REFERENCES COURRIER; CREATE TABLE TRANSMISSION (NTransmission String, DateTransmission Date NOT NULL, DateRception Date NOT NULL, Orientation String, Observation String, NOrdre String) PRIMARY KEY NTransmission FOREING KEY NOrdre REFERENCES COURRIER; CREATE TABLE CLASSEUR (CodeClasseur String, Classeur String NOT NULL,, NRayon Byte) PRIMARY KEY CodeClasseur FOREING KEY NRayon REFERENCES RAYON; CREATE TABLE RAYON (NRayon Byte) PRIMARY KEY; CREATE TABLE CLASSEMENT (NClassement String, NOrdre String, CodeClasseur String, DateClassement Date) PRIMARY KEY (NOrdre, CodeClasseur) FOREING KEY NOrdre REFERENCES COURRIER FOREING KEY CodeClasseur REFERENCES CLASSEUR;
82
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'aprs Pascal Roques le rle de la couche de lapplication est de piloter les processus dinteractions entre lutilisateur et le systme. Il sagit gnralement de mettre en oeuvre toutes les rgles ncessaires au maintien dune application cohrente et loptimisation des changes client/serveur et/ou des requtes http. D'une manire prcise, les mcanismes dune application assurent : Lexistence de diffrentes fentres ou pages synchronises sur les mmes donnes ; La cohrence entre les objets distribus et les multiples faons de les reprsenter au travers des IHM ; Loptimisation des chargements pour un dploiement en client lger ou sur le poste client pour un dploiement client/serveur ; La mise en uvre des concepts applicatifs : typiquement les sorties de rapports sur imprimante. Le diagramme de squence du scnario de cration d'un classement rsume les rles et responsabilits des diffrents objets intervenant dans la cration de l'objet Classement : Dans la couche prsentation : l'interface transforme les vnements de l'utilisateur en action, elle restitue par ailleurs les lments du courrier et du classeur. Le contrleur centralise l'action dclenche depuis l'IHM, il vrifie si toutes les rgles sont respects (Format des donnes enregistrer, .) et ensuite il cre la commande correspondante l'action qui est dans notre cas la demande de cration d'un classement et la place en file d'excution auprs de l'invocateur applicatif. Dans la couche mtier : l'invocateur excute la commande de cration d'un classement. Il restitue la rponse au contrleur qui l'envoi l'interface.
83
Ces diffrents tats donnent des algorithmes. Le diagramme d'activit par couloir de responsabilit formalise le mieux ce type d'algorithme. Il spare clairement les responsabilits et l'imbrication des dclenchements entre les commandes applicatives. Voici un exemple illustrant les responsabilits et l'inbrications des dclenchements entre les commandes applicatives du cas de cration d'un classement.
Commande vrifierCourrier Commande Ouvrir/Fermer Editeur OuvrirIHMClassement Commande vrifierClasseur Commande Valider Classement
SaisirNOrdre
Test
SaisirCodeClasseur
Test4
SaisirAnnotation
ValiderClassement FermerIHMClassement
Decision
Figure 49. Algorithme de cration d'un classement. Le diagramme d'activit par couloir de responsabilit de la cration d'un classement peut s'tendre jusqu' une commande qui permet d'annuler un classement lors de la cration.
3.2.5 Conception de la couche mtier Distribue

Pascal Roques dit que la conception de la couche Mtier consiste identifier les objets entits et sessions qu'il convient de dvelopper au vu des classes et des oprations mtier distribuer. Le concept d'objets distribus pose galement le problme de la distribution des liens d'un ensemble d'objets. Pour cela deux techniques s'opposent : soit les objets sont distribus unitairement, et la demande d'un objet li ou de sa rfrence dclenche une nouvelle demande de transaction. Cette pratique convient bien l'dition d'objets mtier.
84
Soit un ensemble complet d'objets lis est pralablement charg dans le contexte mmoire de la couche prsentation. Cette technique s'utilise de prfrence pour raliser la prsentation des lments composites. La distribution du mtier nous pousse tudier quel type d'architecture C/S nous devons choisir pour GESTCOUR afin de mieux grer les transactions entre le client et le serveur. Les 4 modles de repartition d'une architecture client/serveur sont : - C/S de prsentation : c'est dit d'un systme qui utilise la prsentation au niveau du client, et le code applicatif ainsi que les donnes sur le Serveur, - C/S de donnes : c'est dit d'un systme qui utilise la prsentation et le code applicatif au niveau du client et au niveau du serveur il n'y a que les donne, - C/S de procdures : cela est dit d'un systme qui utilise la prsentation et une partie du code applicatif au niveau Client et le niveau Serveur utilise l'autre partie du code applicatif et les donnes - C/S Systme reparti : c'est un systme qui utilise la prsentation, une partie du code applicatif et une partie des donnes au niveau Client et au niveau Serveur il utilise l'autre partie du code applicatif et toutes les donnes
Figure 50. Architecture Client/Serveur Etant donn que GESTCOUR ne sera utilis que par un seul dpartement , nous optons pour le Client/Serveur de donnes. Ainsi tous les utilisateurs du systme se partegrons une mme base de donnes.
85
CONCLUSION GENERALE
La gestion des courriers au sein du Dpartement des Services Administratifs Sud (DSA/S) posse souvent des problme de pertes de donnes suite au manque de classement, de transmission, de traitement des courriers reus, de suivi, Face cette ralit, nous avons utilis l'analyse du systme afin de voir dans quelle mesure l'outil informatique peut porter une solution ce problme. De cette analyse mtier, nous avons aboutit la ralisation d'une application de gestion des courriers. Cette application permet d'enregistrer les courriers tant mis que reus, il permet d'assurer le suivi des courriers en attente de rponse (feedback) ou en suspend par un systme de rapppel avant l'chance. 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 donnes; seulles les donnes sont partages d'archivage). Dans le cas o le systme devrait tre utilis par toute la GECAMINES, la meilleur solution serait un systme client/serveur rparti. Ainsi chaque niveau aura traiter et stocker ses donnes sont niveau quitte consullter le serveur pour appel des donnes qui ne sont pas dans son domaine d'action et selon les responsabilits (Exemple d'une demande de consultation des courriers d'un autre dpartement). Pour un tel systme, la dmatrialisation totale du courrier peut tre une solution envisagaeable. La GECAMINES pourait utilis une solution simple et puissante, adapte la gestion des courriers. Destin aussi bien aux collectivits, administrations et grandes entreprises ce logiciel sadapterait galement aux besoins des PME. Grce une interface trs intuitive accessible sur chaque poste de l'entreprise, ce logiciel prmettrait non seulement le suivi chrono, mais grerait galement le classement des courriers par dpartement et de la correspondance gnre par la hirarchie labor en mode client-serveur ce logiciel fonctionnerait sous Windows 95, 98, 2000, NT, XP et Vista. Construit sur une base de donnes, il
86
entre les utilisateurs du systme
(Dpartemental, Secrtaire, Attach Bureau D'administration, Attach au bureau
serait possible deffectuer des requtes SQL, qui sajouteraient celles existantes et permetrait de personnaliser les interrogations aux besoins spcifiques de chaque dpartement.
Le logiciel grerait la scurit en s'appuyant entirement sur la scurit du serveur utilis (2003, 2000, NT, Novell ou autre). Les permissions sont celles dj mises en place par l'administrateur ; si un utilisateur essaie daccder un document interdit, une fentre apparatra lui indiquant quil ne possde pas les permissions suffisantes. A chaque utilisateur de lapplication il est associ un profil : Administrateur, Superviseur, Utilisateur, consultation. Les Fonctionnalits qu'offrirait le logiciel sont : - Compteur automatique, avec personnalisation de ce dernier - Bouton Export vers Excel dans les courriers entrants et sortants. - Possibilit de protger une table attache par mot de passe - Possibilit de crypter une base de donnes - Routage par mail de la pice jointe, si le document arriv est scann il est distribu automatiquement - Filtre dans Gestion des courriers entrants - Gestion des modles de documents - Gestion des lieux avec plan daccs - Scurit avec gestion des profils dutilisateur Il rend les documents accessibles distance, en utilisant des technologies trs novatrices bases sur la notion de client lger, tout en utilisant linfrastructure Internet (Avec une adresse IP fixe) vous pourrez accder tous vos documents, quelque soit lendroit 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 lenvoyer par mail soit une liste de diffusion, soit des personnes de votre organisation. Le routage par messagerie est galement disponible depuis le dpart, ainsi vous pouvez communiquer aux diffrents collaborateurs, la rponse faite un courrier.
87
BIBLIOGRAPHIE
1. Pierre Alain Muller, Modlisation objet avec UML, Eyrolles, 1999. 2. Ivar Jacobson, Object-Oriented Software Enginneering, A Use Case Driven Approach, Addison-Wesley, 1992. 3. [Roques & Valle, 2006] : UML 2 en action : De l'analyse des besoins la conception, Pascal Roques et Franck Valle, 2007, Eyrolles. 4. [Valle 04] : UML est les dcideurs, Franck Valle, 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 corrigs, Eyrolles, 2006.
7. Christian SOUTOU, de UML SQL, Eyrolles.
88
TABLE DES TABLEAUX

Tableau 1 : Tableau 2 : Tableau 3 : Tableau 4 : Tableau 5 : Contexte dynamique de GESTCOUR...................................................... 14 Cas d'utilisation de GESTCOUR .............................................................. 18 Package des cas d'utilisation. ................................................................... 34 Tableau des composants .......................................................................... 70 Opration d'analyse................................................................................. 72
TABLE DES FIGURES

Figure 1. Figure 2. Figure 3. Figure 4. Figure 5. Organigramme du Dpartement DSS de la GCM (Source : DSA/S) ................... 8 Le processus de dveloppement en Y.............................................................. 11 Diagramme de Contexte dynamique............................................................... 15 Diagramme d'Activit "CourrierSortant".......................................................... 16 Diagramme d'activits "CourrierEntrant"......................................................... 17
89
Figure 6. Diagramme de Cas dutilisation ...................................................................... 21 Figure 7. Diagramme de squences du cas dutilisation GrerCourrierEntrant ......... 24 Figure 8. Diagramme de squences du cas dutilisation GrerArchivage .................. 27 Figure 9. Diagramme de squences du cas dutilisation GrerTransmission ............. 29 Figure 10. Diagramme de Squences du cas d'Utilisation "GererFeedback".................... 31 Figure 11. Cas d'utilisation gnraliss. ........................................................................... 32 Figure 12. Uses case dans GrerCourrier ........................................................................ 33 Figure 13. Cas d'utilisation inclus dans Grer transmission.............................................. 33 Figure 14. Diagramme de Classes participantes du CU "Grertransmission".................... 35 Figure 15. Diagramme de Classes participantes du CU "Grerclassement" ...................... 35 Figure 16. Diagramme de cas d'utilisation organiss........................................................ 36 Figure 17. Diagramme de dploiement GESTCOUR....................................................... 38 Figure 18. Configuration rseau 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 catgorie "AGENT"......................................................................... 48 Figure 23. DCL de la catgorie "COURRIER"................................................................... 48 Figure 24. DCL de la catgorie "CLASSEMENT"............................................................... 48 Figure 25. Diagramme de classe du modle statique ....................................................... 49 Figure 26. Diagramme de squence de GCE_N1 ............................................................. 52 Figure 27. Diagramme de communication de GCE_N1 ................................................... 53 Figure 28. Diagramme de squences de GCL_N1........................................................... 55 Figure 29. Diagramme de communication de GCL_N1 .................................................. 56 Figure 30. Diagramme de squence de GT_N1 .............................................................. 58 Figure 31. Diagramme de communication de GT_N1 .................................................... 59 Figure 32. Diagramme de squence 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. Modle de dploiement dtall de GESTCOUR.............................................. 68 Figure 37. Modle d'exploitation GESTCOUR ................................................................ 69 Figure 38. Consolidation de l'application GESTCOUR ................................................... 70 Figure 39. Catgories de la couche prsentation .............................................................. 71 Figure 40. Vue des commandes de la couche Applicative :: Classement.......................... 72 Figure 41. Diagramme de classes dtailles ..................................................................... 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 cration d'un classement. ........................................................ 84 Figure 50. Architecture Client/Serveur ............................................................................. 85
TABLE DES MATIERES

INTRODUCTION GENERALE ............................................................................. 1
1. PROBLEMATIQUE................................................................................................. 1
90
2. 3. 4. 5.
HYPOTHESE .......................................................................................................... 2 CHOIX ET INTERET DU SUJET .............................................................................. 2 METHODES ET TECHNIQUES............................................................................... 2 SUBDIVISION DU TRAVAIL ................................................................................. 3
CHAP I : MODELISATION DES BESOINS ........................................................... 4

1.1. ETUDE PRLIMINAIRE........................................................................................... 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 Dtermination des cas dutilisation.............................................................. 18 1.2.2 Description dtaille des cas dutilisations .................................................. 21 1.2.3 Organisation des cas dutilisations............................................................... 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 Spcification technique du point de vue matriel........................................ 37 1.3.2 Spcification darchitecture et influence sur le modle de dploiement ...... 40 1.3.3 laboration et organisation du modle de spcification logicielle ............... 41 1.3.4 Description des couches logicielles ............................................................. 42 1.3.5 Description dun cas dutilisation technique................................................ 43
CHAP II : ANALYSE OBJET & CONCEPTION DE L'ARCHITECTURE TECHNIQUE ..........................................................................................................................44

2.1. NOTIONS DE CATEGORIES................................................................................ 44 2.1.1 Dcoupage en catgories............................................................................. 44 2.1.2 Dpendance entre catgorie ........................................................................ 45 2.2. DEVELOPPEMENT DU MODELE STATIQUE ...................................................... 46 2.3. DEVELOPPEMENT DU MODELE DYNAMIQUE ................................................. 50 2.3.1 Identification et formalisation des scnarios ................................................ 50 2.3.2 Construction et validation des diagrammes d'tats ..................................... 61 2.3.3 Confrontation des modles statique et dynamique ...................................... 64 2.4. CONCEPTION GENERIQUE................................................................................ 66 2.4.1 Modle logique de conception technique.................................................... 66 2.4.2 Modle d'exploitation de conception technique.......................................... 66 2.4.3 Modle de configuration logicielle de la conception technique .................. 67 2.4.4 Dveloppement d'un prototype ................................................................... 67
CHAP III: CONCEPTION OBJET........................................................................68

3.1. CONCEPTION PRELIMINAIRE ............................................................................ 68 3.1.1 Conception du modle de dploiement....................................................... 68 3.1.2 Elaboration du modle d'exploitation .......................................................... 69 3.1.3 Dveloppement du modle logique de conception .................................... 70 3.1.4 Cration des interfaces des catgories.......................................................... 71 3.1.5 Mise au point de la prsentation des applications ..................................... 72 3.1.6 Organisation de la configuration logicielle ................................................. 73 3.2. CONCEPTION DETAILLEE .................................................................................. 73
91
3.2.1 3.2.2 3.2.3 3.2.4 3.2.5
Conception dtaille du modle logique ..................................................... 74 Conception de la couche prsentation......................................................... 78 Conception de la couche persistance........................................................... 80 Conception de la couche applicative........................................................... 83 Conception de la couche mtier Distribue................................................. 84
CONCLUSION GENERALE ................................................................................86 BIBLIOGRAPHIE ...............................................................................................88 TABLE DES TABLEAUX ......................................................................................89 TABLE DES FIGURES .........................................................................................89 TABLE DES MATIERES ......................................................................................90
92

Gestion Des Courriers Assistée Par Ordinateur Avec Visual Studio - Net Sous Windows (Cas de La GCM)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Gestion Des Courriers Assistée Par Ordinateur Avec Visual Studio - Net Sous Windows (Cas de La GCM)

Uploaded by

Copyright:

Available Formats

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

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

3. CHOIX ET INTERET DU SUJET

Linterview libre, qui a permis une rcolte de donnes prcises.

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

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

CHAP I : MODELISATION DES BESOINS

1.1.1 Recueil des besoins fonctionnels

la date de rception du courrier (qu'il inscrit sur le courrier reu);

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

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

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

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

Structure du Dpartement DSS

Division Enseignement du Groupe Sud ENS/DIR ENS/SEC

Division Administration du Groupe Sud AGS/DIR

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

ENS/DIR ENS/SEC ADM SEC PRIM SAS SGX SPL

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

1.1.2 Choix techniques

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

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

1.1.3 Identification des acteurs

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

1.1.4 Identification des messages

d'envoi et un vnement de rception. Cette

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

Diagramme de contexte dynamique de GESTCOUR

Description des besoins fonctionnels

bureau GESTCOUR permettra l'Attache du bureau administration :

GESTCOUR permettra au Secrtaire :

de rechercher un courrier dj class ou transmis.

de grer les classeurs et l'archivage des courriers.

de recevoir/envoyer son courrier

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

Le diagramme de contexte de GESTCOUR est le suivant :

Liste courriers en attente Liste courriers Feedback

S'authentifier Crer classeurs Crer Archivage courrier Recevoir courrier

Attache. Bur. Archiv

Figure 3. Diagramme de Contexte dynamique

1.2. ANALYSE FONCTIONNELLE

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

Cas d'un courrier sortant.

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

Cas d'un courrier entrant

Figure 5. Diagramme d'activits "CourrierEntrant"

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

1.2.1 Dtermination des cas dutilisation

Cas d'utilisation GrerCourrierEntrant

Cas d'utilisation de GESTCOUR

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

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

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

Ce qui donne le diagramme de cas dutilisation suivant :

Expditeur GrerCourrierSortant Att. Bur.Admin

Destinataire GrerFeedBack GrerArchivage

Secrtaire Att. Bur.Archiv GrerCourrierSuspend

Figure 6. Diagramme de Cas dutilisation

1.2.2 Description dtaille des cas dutilisations

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

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

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

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