Vous êtes sur la page 1sur 92

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)

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

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

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

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

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.

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

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

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

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

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

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.

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

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

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.

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

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

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,

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

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

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

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

SPL

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

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.

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

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

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 :
Gestion des courriers assiste par ordinateur avec Visual Studio.Net sous Windows (cas de la GCM)

10

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

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

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

11

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

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

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

12

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

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)

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

13

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

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

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

14

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

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.

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

15

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

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.

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

16

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

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

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

17

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

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

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

18

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

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.

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

19

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

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.

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

20

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

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 :

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

21

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

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.

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

22

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

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.

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

23

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

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.

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

24

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

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.

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

25

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

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.

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

26

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

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

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

27

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

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

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

28

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

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

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

29

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

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

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

30

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

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.

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

31

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

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.

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

32

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

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 :

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

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.

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

34

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

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"

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

35

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

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

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

36

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

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.


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

37

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

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

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

38

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

Figure 18. Configuration rseau de GESTCOUR

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

39

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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