Rapport - PFA Processus 2tup PDF

Ecole Nationale Suprieure dInformatique
et dAnalyse des Systmes

Mmoire de Projet de Fin de 2me anne

Sujet :
Conception Orient Objet et Ralisation du cas Agri
selon le processus 2tup

Ralis par : Encadr par :
Othmane MAHBOUB M. Abdelaziz KRIOUILE
Amine MAJDOUL

Anne Universitaire : 2012-2013

Remerciements

Projet de Fin dAnne 2012-2013 Page 3

Remerciements

Il nous est agrable de nous acquitter dune dette de reconnaissance auprs de toutes les
personnes dont lintervention au cours de ce projet a favoris son aboutissement.
Tout dabord nous adressons nos vifs remerciements notre encadrant Monsieur
KRIOUILE pour ses directives prcieuses et ses conseils pertinents qui nous ont t dun
appui considrable dans la ralisation de notre projet.
Nous ne saurions oublier dans nos remerciements tout le cadre professoral de lENSIAS,
pour la formation consistante quil nous a prodigue.
Que tous ceux qui nous ont aids, de prs ou de loin, trouvent ici lexpression de nos
sentiments les meilleurs.
Enfin, nous prsentons notre profond respect aux membres du jury notamment Monsieur
ELKETTANI pour leur bienveillance vouloir valuer notre travail

Rsum

Rsum :

Nous proposons dans le cadre de ce projet de fin dtudes, dappliquer la mthode 2TUP
au problme de la gestion des ventes de la socit AGRI.
La gestion dun cycle de vie de logiciel requit un grand sens de la rigueur et de
ladaptation aux changements continuels imposs au monde de lentreprise.
Cest pour a que nous avons choisi daxer notre travail sur une mthode de
dveloppement qui est ne de travaux pousss vers la standardisation et la flexibilit, et ce
pour rpondre aux contraintes actuelles de gestion des dveloppements.
Le mmoire sera dcoup en 5 grands chapitres :
1. Introduction : nous parlerons dans ce chapitre des objectifs que nous
voudrions atteindre, ainsi quun aperu des diffrentes mthodes
existantes.
2. La mthode 2TUP : ce chapitre contient les dfinitions des diffrents
concepts utiliss dans ce document.
3. Conception du logiciel : cest ici que nous allons appliquer la
mthode 2TUP au problme de la gestion des enseignements en
suivant les phases suivantes : ltude prliminaire,
Liste des abrviations

Liste des abrviations

Abrviation Signification
2TUP 2 Tracks Unified Process
UML Unified Modeling Language
CATA Catalogue des produits
BCDE
Bon de commande
BLIV Bon de livraison
UP Unified Process
MAJ Mis jour

Liste des figures
Figure 1:Le systme dinformation soumis deux types de contraintes ................................. 15
Figure 2:Le processus de dveloppement en Y ........................................................................ 16
Figure 3:Diagramme des cas dutilisations .............................................................................. 26
Figure 4: diagramme dactivit du cas sauthentifier ......................................................... 28
Figure 5:Diagramme dactivit du cas grer des infos client ............................................ 29
Figure 6:diagrame d'activit du cas grer la commande .................................................... 31
Figure 7:Diagramme dactivit du cas grer la livraison ................................................... 32
Figure 8:Diagramme dactivit du cas grer la facturation ................................................ 33
Figure 9:Diagramme dactivit du cas mettre jour le catalogue ....................................... 34
Figure 10:diagramme de dploiement ...................................................................................... 36
Figure 11:Diagramme de classes participantes au processus de ventes de la socit AGRI ... 37
Figure 12:Diagramme de squence du scnario Authentification ...................................... 38
Figure 13:Diagramme de squence du scnario Ajout/Modification dun profil .............. 39
Figure 14:Diagramme de squence du scnario Alimentation du stock ............................ 39
Figure 15:Diagramme de squence du scnario passer une commande .................................. 40
Figure 16:Diagramme de squence du scnario Etablir la facture ........................................... 40
Figure 17:Diagramme de squence du scnario cration du bon de livraison ........................ 41
Figure 18:Diagramme de squence du scnario Cration dune fiche client ........................... 41
Figure 19:Diagramme de squence du scnario Modification de la fiche client ..................... 42
Figure 20:Diagramme de squence du scnario Modifier catalogue ....................................... 42
Figure 21:Diagramme dtats-transitions de la classe Personne .............................................. 43
Figure 22:Diagramme dtats-transitions de la classe Catalogue ............................................ 43
Figure 23:Diagramme dtats-transitions de la classe Commande .......................................... 44
Figure 24:Diagramme dtats transitions de la classe Facture ................................................. 44
Figure 25:Diagramme dtats-transitions de la classe Client ................................................... 44
Figure 26:IDE Netbeans 6.9.1 .................................................................................................. 46
Figure 27:PowerAMC .............................................................................................................. 46
Figure 28:Classe Log qui permet de coder lauthentification de lutilisateur .......................... 48
Figure 29:Classe Saisie produit qui permet linsertion dun nouveau produit dans le catalogue
.................................................................................................................................................. 48
Figure 30: Classe LireEtEcrire qui permet la Srialisation (La sauvegarde et le chargement)
des donnes .............................................................................................................................. 49
Figure 31:Fentre daccueil ..................................................................................................... 49

Figure 32:Fentre didentification ............................................................................................ 50
Figure 33: Menu administrateur ............................................................................................... 50
Figure 34:Fentre de saisie de nouveaux produits ................................................................... 51
Figure 35: Fentre dajout de nouveau client ........................................................................... 51
Figure 36: Fentre de saison de la commande ......................................................................... 52
Figure 37:Fentre des Listes des clients ................................................................................... 52
Figure 38: Fentre du catalogue ............................................................................................... 53
Liste des tableaux
Tableau 1:description des besoins fonctionnels ....................................................................... 23
Tableau 2:identification des cas d'utilisation ........................................................................... 26


Tables des matires

Remerciements .......................................................................................................................... 3
Rsum : .................................................................................................................................... 4
Liste des abrviations ................................................................................................................. 5
Liste des figures ......................................................................................................................... 6
Liste des tableaux ....................................................................................................................... 7
Introduction gnrale .............................................................................................................. 10
1.1 Le contexte de travail ............................................................................................... 10
1.2 Objectifs ................................................................................................................... 10
1.3 Comparaison entre les diffrentes approches ........................................................... 11
1.3.1 Modlisation ..................................................................................................... 11
1.3.2 Conduite de projet ............................................................................................ 11
1.4 Prsentation de lapplication raliser ..................................................................... 11
Description de la mthode 2TUP ........................................................................................... 12
2.1 Dfinition dun processus de developpement logiciel ............................................. 13
2.2 Le processus unifi ................................................................................................... 13
2.3 Le processus 2TUP ................................................................................................... 14
2.4 Un processus de modlisation avec UML ................................................................ 16
Chapitre 1 ................................................................................................................................. 18
Analyse et Conception ............................................................................................................ 18
I-Etude prliminaire ................................................................................................................. 18
1-Prsentation du projet raliser ........................................................................................ 18
2-Recueil des besoins fonctionnels ...................................................................................... 18
3-Choix techniques ............................................................................................................... 19
4-Identification des acteurs .................................................................................................. 20
5-Identification des messages ............................................................................................... 21
6-Modlisation du contexte .................................................................................................. 21
II-Capture des besoins fonctionnels ......................................................................................... 23
1-Dterminer les cas dutilisations ....................................................................................... 23
1-1Utilisation doutils de gnration de diagrammes UML : .......................................... 23
1-2Identification des cas dutilisations ............................................................................. 24

2-Description dtaille des cas dutilisations ....................................................................... 26
Cas d'utilisation " Authentification (identification utilisateurs) " .................................... 27
Cas d'utilisation " Grer les profils: " ............................................................................... 28
Cas d'utilisation " Grer les infos clients " ....................................................................... 28
Cas d'utilisation " Grer la commande " .......................................................................... 30
Cas d'utilisation " Grer la livraison " .............................................................................. 31
Cas d'utilisation " Grer la facturation " ........................................................................... 32
Cas d'utilisation " Mettre jour le catalogue " ................................................................. 33
3-Structuration des cas dutilisations dans des packages ..................................................... 34
III-Capture des besoins techniques .......................................................................................... 36
1-Spcification technique du point de vue matriel ............................................................. 36
2-Configuration matriel du systme ................................................................................... 36
IV-Analyse ............................................................................................................................... 37
1-Dveloppement du modle statique .................................................................................. 37
2-Dveloppement du modle dynamique ............................................................................. 38
Construction des diagrammes dtats : ............................................................................. 42
Chapitre 2 ................................................................................................................................ 45
Ralisation ............................................................................................................................... 45
1-Outils de dveloppement : ................................................................................................ 45
1-1 NetBeans .................................................................................................................... 45
1-2PowerAMC ................................................................................................................. 46
1-3Langage de programmation : JAVA ........................................................................... 47
2-Prsentation de lapplication ralise :.............................................................................. 47
3-Conclusion : ...................................................................................................................... 53
Conclusion gnrale ................................................................................................................. 54


Introduction gnrale
1.1 Le contexte de travail
La complexit croissante des systmes informatiques a conduit les concepteurs sintresser
aux mthodes de dveloppement. Ces dernires ont toujours essay dapporter un contrle continu
sur un projet tout au long de son processus de vie.
Bien que des mthodes de dveloppement existent depuis 30 ans (Merise, SADT), nous ne
pouvons constater aujourdhui lexistence dune rgle qui soit la fois formelle et commune aux
diffrentes cultures.
Par ailleurs, des mthodes squentielles comme celles se basant sur le cycle en V, ont montr
leur limite dans un environnement rgi par des changements rguliers, impliquant une impossibilit
revenir en arrire, et de ce fait, laissant une trs petite marge lerreur.
Avec lavnement de la pense objet, de nouvelles mthodes sont apparues et diffrentes
notations ont t tablies. UML a ouvert le terrain de lunification en fusionnant ces notations et en
apportant prcision et rigueur la dfinition des concepts introduits.
Sur cet lan, les spcialistes ont aussi pens unifier non pas les processus, mais plus
exactement les meilleures pratiques de dveloppement orient objet.
1.2 Objectifs
Notre but est dappliquer une mthode rigoureuse de conduite dun projet rel. Le projet en
question concerne la gestion des ventes.
Ce projet a pour objectif principal de proposer une solution un problme concret, et ceci en
partant dune dfinition des besoins. Nous esprons travers celui-ci, dmontrer limportance de
lapplication dune mthodologie de dveloppement, et aussi permettre par la suite que ce produit
puisse tre volutif et facilement maintenable par des intervenants tiers.

1.3 Comparaison entre les diffrentes approches
1.3.1 Modlisation
Par le pass, le modle Entit-Relation reprsentait une grande partie des approches les plus
utilises.
Actuellement, les nouvelles technologies sappuient sur le modle objet.
En termes danalyse et de modlisation objet, UML est devenu un standard incontournable,
stabilis, industriel.
1.3.2 Conduite de projet
Au dbut, le cycle en cascade (ex : le cycle en V) tait trs utilis. Mais on a vite constat son
incapacit sadapter aux diffrents changements.
Une mthode semi-itrative est apparut (RAD) pour pallier aux carences de ce dernier.
Litratif sest ensuite impos, parce quil rduit la complexit de ralisation des phases, en
travaillant par approches successives et incrmentales.
Une mthode fortement axe sur litratif et le modle UML est alors apparut, il sagit de UP
(Unified Process). Cette mthode comme son nom lindique, a t le fruit de travail de plusieurs
personnes voulants unifier les diffrentes mthodes objets existantes ce moment comme
Booch, OMT et OOSE.
On constate aujourdhui, lmergence dune nouvelle approche : les mthodes agiles (Agile
Modeling). Cest des mthodes itratives planification souple qui leur permettent de sadapter la
fois aux changements du contexte et de spcifications du projet. (Chromatic, 2005)
1.4 Prsentation de lapplication raliser

De nos jours, une des tendances les plus en vue et qui concerne tout les secteurs de
dveloppement, est linformatisation.
Depuis lapparition de linformatique et son introduction dans le monde conomique, les
entreprises et entits publiques aspirent optimiser et rendre fiable la gestion de leur structure
interne.

La socit AGRI possde quelques milliers de clients quil est difficile de grer en continu.
Alors la tche de gestion est trs complexe.
Le projet que nous proposons nous permettra de faciliter la gestion de ventes de la socit,
travers la conception dun logiciel avec une mthode que nous allons prsenter.
Description de la mthode 2TUP
Devant le nombre de mthodes disponibles, le choix parmi elles devient difficile, beaucoup de
questions peuvent se poser un chef de projet lors dun dmarrage de projet :
Comment vais-je organiser les quipes de dveloppement ;
Quelles tches attribuer qui ;
Quel temps faudrait-il pour livrer le produit ;
Comment faire participer le client au dveloppement afin de capter les besoins de celui-ci
Comment viter des drives et de mauvaises estimations qui vont allonger les cots et le temps
de dveloppement.
Comment vais-je procder pour que le produit soit volutif et facilement maintenable.
Nous pouvons citer ce propos les mthodes de dveloppement objet suivantes : 2TUP, RUP,
XP, AUP et OpenUP.
Notre choix sest port vers la mthode 2TUP, du fait de son approche nouvelle, originale.
Notre projet est bas sur un processus de dveloppement bien dfini qui va de la dtermination
des besoins fonctionnels attendus du systme jusqu la conception et le codage final.
Ce processus se base lui-mme sur le Processus Unifi (Unified Process) qui est devenu un
standard gnral runissant les meilleures pratiques de dveloppement.
Cette mthode ne se base aucunement sur un processus linaire mais bien, sur un
dveloppement itratif et incrmental.
Nous allons dabord dfinir les diffrents concepts qui vont tre utiliss dans ce document.

2.1 Dfinition dun processus de developpement logiciel

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. (Rocques & Valle, 2004)
2.2 Le processus unifi
Le Processus Unifi (PU ou UP en anglais pour Unified Process) est une mthode de
dveloppement logiciel construite sur UML ; elle est itrative et incrmentale, centre sur
larchitecture, conduite par les cas dutilisation et pilote par les risques.
itrative et incrmentale : la mthode est itrative dans le sens o elle propose de faire des
itrations lors de ses diffrentes phases, ceci garantit que le modle construit chaque phase ou
tape soit affin et amlior. Chaque itration peut servir aussi ajouter de nouveaux incrments.
conduite par les cas dutilisation : elle est oriente utilisateur pour rpondre aux besoins de
celui-ci.
centre sur larchitecture : les modles dfinit tout au long du processus de dveloppement vont
contribuer tablir une architecture cohrente et solide.
pilote par les risques : en dfinissant des priorits pour chaque fonctionnalit, on peut
minimiser les risques dchec du projet.
La gestion dun tel processus est organise daprs les 4 phases suivantes :
Pr-tude (Inception) : cest ici quon value la valeur ajoute du dveloppement et la capacit
technique le raliser (tude de faisabilit).
Elaboration : sert confirmer ladquation du systme aux besoins des utilisateurs et livrer
larchitecture de base.

Construction : sert livrer progressivement toutes les fonctions du systme.
Transition : dployer le systme sur des sites oprationnels.
Chaque phase est elle-mme dcompose squentiellement en itrations limites dans le
temps (entre 2 et 4 semaines). Le rsultat de chacune delles est un systme test, intgr et
excutable. Lapproche itrative est fonde sur la croissance et l'affinement successifs dun
systme par le biais ditrations multiples. Le systme crot avec le temps de faon
incrmentale, itration par itration, et cest pourquoi cette mthode porte galement le nom
de dveloppement itratif et incrmental. Il sagit l du principe le plus important du
Processus Unifi.
Ces activits de dveloppement sont dfinies par 6 disciplines fondamentales qui
dcrivent la capture des besoins, la modlisation mtier, lanalyse et la conception,
limplmentation, le test et le dploiement.
Notons que ces diffrentes tapes (ou disciplines) peuvent se drouler travers plusieurs
phases.
Le processus unifi doit donc tre compris comme une trame commune des meilleures
pratiques de dveloppement.
2.3 Le processus 2TUP

On dit de la mthode UP quelle est gnrique c..d. quelle dfinit un certain nombre de
critres de dveloppement, que chaque socit peut par la suite personnaliser afin de crer son
propre processus plus adapt ses besoins.
Cest dans ce cadre que la socit Valtech a cr la mthode 2TUP.
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 signifie littralement que le processus suit deux chemins. Il sagit des
chemins fonctionnels et darchitecture technique , qui correspondent aux deux axes de
changement imposs au systme dinformation.


Figure 1:Le systme dinformation soumis deux types de contraintes

La branche gauche (fonctionnelle) : capitalise la connaissance du mtier de lentreprise.
Elle constitue gnralement un investissement pour le moyen et le long terme.
Les fonctions du systme dinformation sont en effet indpendantes des technologies
utilises.
Cette branche comporte les tapes suivantes :
La capture des besoins fonctionnels, qui produit un modle des besoins focalis sur le
mtier des utilisateurs.
Lanalyse.
La branche droite (architecture technique) : capitalise un savoir-faire technique. Elle
constitue un investissement pour le court et moyen terme. Les techniques dveloppes pour le
systme peuvent ltre en effet indpendamment des fonctions raliser.
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
fusion conduit lobtention dun processus en forme de Y.
La conception prliminaire.
La conception dtaille.
Le codage.
Lintgration.


Figure 2:Le processus de dveloppement en Y

2.4 Un processus de modlisation avec UML
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.
Unified Modeling Language : UML se dfinit comme un langage de modlisation
graphique et textuel destin comprendre et dcrire des besoins, spcifier, concevoir des
solutions et communiquer des points de vue. (Pitman, 2006)
UML unifie la fois les notations et les concepts orients objet.il ne sagit pas dune
simple notation, mais les concepts transmis par un diagramme ont une smantique prcise et
sont porteurs de sens au mme titre que les mots dun langage, cest pour a quUML est
prsent parfois comme une mthode alors quil ne lest absolument pas.
UML unifie galement les notations ncessaires aux diffrentes activits dun processus
de dveloppement et offre, par ce biais, le moyen dtablir le suivi des dcisions prises, depuis
la dfinition des besoins jusquau codage. (Roques, 2006)

Voici une prsentation rapide des diffrents diagrammes UML qui vont tre utiliss tout
au long du projet :
Le diagramme des cas dutilisation : reprsente la structure des fonctionnalits
ncessaires aux utilisateurs du systme. Il est normalement utilis lors des tapes de capture
des besoins fonctionnels et techniques.
Le diagramme dactivits : reprsente les rgles denchanement des activits et actions
dans le systme. Il peut tre assimil comme un algorithme mais schmatis.
Le diagramme de packages : prsent depuis UML 2.0, ce diagramme modlise des
catgories cohrentes entre elles, pour un souci de partage des rles. Correspond ltape de
modlisation des diffrents scnarios dun cas dutilisation.
Le diagramme de classes : srement lun des diagrammes les plus importants dans un
dveloppement orient objet. Sur la branche fonctionnelle, ce diagramme est prvu pour
dvelopper la structure des entits manipules par les utilisateurs.
En conception, le diagramme de classes reprsente la structure dun code orient objet.
Le diagramme de squence : reprsente les changes de messages entre objets, dans le
cadre dun fonctionnement particulier du systme.
Le diagramme dtats : reprsente le cycle de vie dun objet. Il spcifie les tats
possibles dune classe et leur enchainement.
Ce diagramme est utilis lors des tapes danalyse et de conception.


Chapitre 1
Analyse et Conception

I-Etude prliminaire

Ltude prliminaire (ou Pretude) est la toute premire tape du processus 2TUP. Elle
consiste effectuer un premier reprage des besoins fonctionnels et oprationnels, en utilisant
principalement le texte, ou diagrammes trs simples. Elle prpare les activits plus formelles
de capture des besoins fonctionnels et de capture techniques.
1-Prsentation du projet raliser
Cest un logiciel qui doit grer les activits de la socit AGRI, et ceci concernant la
ventes de ses produits ces clients, ainsi que la gestion de son catalogue et du stock de
chacune de ces agences.
2-Recueil des besoins fonctionnels
Pour pouvoir tablir lensemble des besoins fonctionnels de notre logiciel, nous nous
sommes bass sur le texte figurant sur le polycopier de llment de module Mthodologie de
dveloppement des systmes dinformation quon a tudi lors du premier semestre de cette
2me anne dtude lENSIAS, et a nous a permis dtablir le cahier des charges
prliminaire suivant :

Gestion du catalogue :
Ce catalogue est mis jour tous les 6 mois par la direction de la
socit AGRI (Modification des prix unitaires des produits
existants ou Ajout/Suppression de produits).

Le catalogue mis jour est envoy par la suite aux agences de
ventes, ainsi quau service de facturation.

Gestion du stock :
Chaque agence de la socit AGRI gre son propre stock.

Gestion des informations des clients :
Un client peut modifier ses informations qui sont rpertories
dans sa fiche client en le demandant lune des agences.
Lagence renvoie cette demande auprs du service de facturation
qui va soccuper de mettre jour la fiche du client concern.

Gestion des commandes des clients :
Le client passe sa commande lune des agences de la socit
AGRI.
Lagence fait appel au service de facturation pour vrifier les
informations relatif au client en les comparants sa fiche client.
Etablissement du bon de commande, ainsi que le bon de livraison
qui seront remis au service de facturation par la suite.

Gestion de la livraison :
Un produit nest livr que si la quantit commande est disponible
dans le stock de lagence.
Un contrle est effectu sur les informations du client et qui sont
portes sur le bon de livraison pour vrifier ltat de la remise.
Seul les clients de types dtaillants ont droit une remise.

Gestion de la facturation :
Le service de facturation tablie une facture par bon de livraison
reu.
La comptabilit reoit la facture et met jour le journal de ventes
de la socit AGRI le lendemain de la transaction de vente.
3-Choix techniques
Voici les choix techniques qui ont t adopts pour le projet :
o La modlisation avec UML.

o Adoption dune architecture 3 couches.
o Utilisation du langage Java.
o Omission dune base de donnes au profit de la srialisation (Java).
o Utilisation de lEDI NetBeans et de son plugin UML.
4-Identification des acteurs
Nous allons maintenant numrer les acteurs susceptibles dinteragir avec le systme,
mais dabord nous donnons une dfinition de ce que cest un acteur.
Dfinition : 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.
Les acteurs du systme identifis dans un premier temps sont :
Client : Un client peut passer une commande, renseigner sa fiche client
avec ses informations personnelles sil est nouveau ou la modifier en cas de
besoin, et enfin il peut consulter le catalogue de la socit AGRI.
Fournisseur : Le fournisseur peut consulter le catalogue, Proposer de
nouveaux produits la socit laide de son propre catalogue.
Direction : La direction peut consulter la fiche client (des clients de type
particuliers) pour prvoir des actions publicitaires par la suite, et mettre
jour le catalogue de la Socit en modifiant le prix unitaire de certains
produits, ou en ajoutant/supprimant des produits existants.
Agence : Chaque agence de la socit AGRI soccupe de traiter les
commandes de ces clients en tablissant le bon de commande ainsi que le
bon de livraison des produits commands, sans oublier la gestion du stock
ainsi que le traitement de la demande de modifications des informations de
ces clients suite leurs demandes et la consultation du catalogue.
Service de facturation : Le service de facturation Peut Crer/modifier la
fiche client, dtablir la facture pour les produits livrs ainsi que la
consultation du catalogue et du bon de livraison pour contrler les
informations sur les clients.
Comptabilit : La comptabilit soccupe de mettre jour le journal de
ventes de la socit AGRI.
Administrateur : Cre les profils utilisateurs et attribue les droits daccs.


5-Identification des messages

On va dtailler les diffrents messages changs entre le systme et lextrieur.
Dfinition: un message reprsente la spcification dune communication
unidirectionnelle entre les objets qui transporte de linformation avec lintention de
dclencher une activit chez le rcepteur.
Le systme met les messages suivants :
Le catalogue de la socit AGRI.
La fiche client de chaque client enregistr dans la socit.
Le bon de commande et le bon de livraison des commandes des
clients de la socit AGRI.
Le journal de vente de la socit.
Le stock de chacune des agences de la socit.
La facture des produits livrs aux clients.
Le systme reoit les messages suivants :
La cration, modification ou suppression de la fiche client.
La modification du catalogue (Ajout de nouveaux produits ou
modification des prix unitaires de ceux existants dj).
La cration du bon de commande, du bon de livraison et de la
facture.
La modification du journal de ventes de la socit AGRI.
Modification du stock dune agence de la socit.
6-Modlisation du contexte
A partir des informations obtenues lors des deux prcdentes tapes, nous allons
modliser le contexte de notre application. Ceci va nous permettre dans un premier temps, de
dfinir le rle de chaque acteur dans le systme
Utilisateurs finaux Description des besoins fonctionnels
Client Lapplication doit permettre au client de :
Sauthentifier

Passer une commande
Crer/Modifier sa fiche client
De consulter la facture des produits qui lui sont
livrs.
Fournisseur Lapplication doit permettre au fournisseur de :
Sauthentifier
Proposer de nouveaux produits.
Consulter le catalogue
Vendeur dune agence Lapplication doit permettre au vendeur dune agence de :
Sauthentifier
Etablir le bon de commande, ainsi que le bon de
livraison des produits commands par un client de
lagence.
Modifier le stock de lagence concern.
Consulter le catalogue

Responsable du Service
de facturation
Lapplication doit permettre au responsable du service de
facturation de :
Sauthentifier.
Crer/Modifier la fiche client dun client dune
agence de la socit.
Etablir la facture pour les produits livrs.
Consulter le catalogue.
Comptable Lapplication doit permettre un comptable du service de
comptabilit de :
Sauthentifier.
Mettre jour le journal de ventes de la socit
AGRI.
Membre de la direction Lapplication doit permettre un membre de la direction
de :
Sauthentifier.

Consulter la fiche client
Mettre jour le catalogue.

Administrateur Lapplication doit permettre ladministrateur de
lapplication de :
Sauthentifier.
Crer des profils dutilisateurs de lapplication.
Attribuer des droits et des privilges selon les
utilisateurs du systme.
Tableau 1:description des besoins fonctionnels
II-Capture des besoins fonctionnels
Cette phase reprsente un point de vue fonctionnel de larchitecture systme. Par le
biais des cas dutilisation, nous serons en contact permanent avec les acteurs du systme en
vue de dfinir les limites de celui-ci, et ainsi viter de trop sloigner des besoins rels de
lutilisateur final.
1-Dterminer les cas dutilisations
Dfinition: un cas dutilisation reprsente un ensemble de squences dactions ralises
par le systme et produisant un rsultat observable intressant pour un acteur particulier. Un
cas dutilisation modlise un service rendu par le systme. Il exprime les interactions
acteurs/systme et apporte une valeur ajoute notable lacteur concern.
1-1Utilisation doutils de gnration de diagrammes UML :
Tout au long du projet, nous sommes passs par plusieurs outils qui gnrent les
diagrammes UML. Nous allons faire une prsentation rapide de ceux l.
STAR UML : cest un outil gratuit crit avec Java, nous lavons utilis au dbut puis
nous lavons dlaiss pour sa lourdeur et son interface peu intuitive.
Bouml : srement loutil le plus lger sur le march, il est trs puissant et agrable
utiliser, et en plus il est gratuit.

1-2Identification des cas dutilisations
Lidentification des cas dutilisation une premire fois, nous donne un aperu des
fonctionnalits futures que doit implmenter le systme. Cependant, il nous faut plusieurs
itrations pour ainsi arriver constituer des cas dutilisation complets. Dautres cas
dutilisation vont apparatre au fur mesure de la description de ceux-l, et lavancement dans
le recueil des besoins fonctionnels . Pour constituer les cas dutilisation, il faut considrer
l'intention fonctionnelle de l'acteur par rapport au systme dans le cadre de l'mission ou de la
rception de chaque message. En regroupant les intentions fonctionnelles en units
cohrentes, on obtient les cas d'utilisations.

Cas dutilisation Acteur principal, Acteurs
secondaires
Messages mis/Reus
par les acteurs
Consulter le catalogue Client, fournisseur, agence,
service de facturation,
direction

Modifier le catalogue La direction de la socit
AGRI
Emet : La direction
met jour le catalogue
(Ajout de nouveaux
produits et/ou
modification des prix
unitaires des produits
existants)
Reoit : Les
propositions de
nouveaux produits en
provenance du
fournisseur
Grer le stock Agence Emet : Le responsable
du stock met jour
ce dernier suite une
vente dun produit ou

la suppression dun
autre du catalogue

Grer les informations des clients Service de facturation Emet :
Cration/Modification
de La fiche client
Reoit : La demande
de Cration/
modification des
informations des
clients de la part dune
des agences de la
socit.

Grer les commandes du client Agence, Service de facturation Emet : le bon de
commande
Reoit : La commande
du client de la part du
client ainsi que
lapprouvation des
informations du client
de la part du service
de facturation.
Grer la livraison des produits Agence, Service de facturation Emet : Le bon de
livraison
Reoit : Etat du stock
de lagence, Etat de la
remise

Tableau 2:identification des cas d'utilisation
Remarque : Ce premier tableau n'est pas dfinitif, un processus de dveloppement avec
UML est itratif, il se peut qu'il change au fur et mesure de l'avancement du projet.

Figure 3:Diagramme des cas dutilisations
2-Description dtaille des cas dutilisations
Nous allons maintenant dtailler chaque cas dutilisation qui doit faire lobjet dune
dfinition a priori qui dcrit lintention de lacteur lorsquil utilise le systme et les squences
Grer la facturation Service de facturation Emet : tablir la
facture des produits
livrs
Reoit : Bon de
livraison
Mettre jour le journal de ventes Comptabilit Emet : crire la
facture dans le
journal de ventes
Reoit : facture

dactions principales quil est susceptible deffectuer. Ces dfinitions servent fixer les ides
et nont pas pour but de spcifier un fonctionnement complet et irrversible.
Remarque : les descriptions vont tre organises de la faon suivante :
Un sommaire didentification : va rsumer les proprits du cas dutilisation.
Une description dtaille : des Prconditions au dclenchement du cas dutilisation
doivent tre spcifies, un scnario nominal dcrivant celui-ci additionn des
scnarios alternatifs et dexceptions.
Les diagrammes (optionnelle): plusieurs diagrammes vont apparaitre (mais pas
ncessairement) pour apporter une comprhension additive au cas dutilisation.
Cas d'utilisation " Authentification (identification utilisateurs) "
Titre : Authentification (identification utilisateurs)
Acteurs : Utilisateur.
Pr conditions : Introduire login et mot de passe
Scnario nominal : Ce cas dutilisation commence lorsque lutilisateur saisi son login
et son mot de passe.
Enchanement (a) : Lutilisateur valide les donnes saisies.
Enchanements alternatifs :
Enchanement (b) : Vrifications de lexistence de lutilisateur par le systme.
Enchanement (c) : Message de confirmation dentrer la session ou chec dentrer.
Post conditions : Ouverture de lespace personnel.


Figure 4: diagramme dactivit du cas sauthentifier

Cas d'utilisation " Grer les profils: "
Titre : Grer les profils:
Acteurs : Administrateurs
Pr conditions : Aucunes
Scnario nominal : Ce cas dutilisation commence lorsque ladministrateur lance le
logiciel.
Enchanement (a) : Crer un profil en construction
Ladministrateur choisit un nom / mot de passe pour le compte.
Il choisit le type de ce compte.
Post conditions : Validation du profil
Cas d'utilisation " Grer les infos clients "
Titre : Grer les infos clients
Rsum : le client effectue la demande auprs dune des agences, lagence transmet la
demande au service de facturation pour traitement
Acteurs : Agence, Service de facturation
Pr conditions : les responsables dagence et service de facturation doivent
sauthentifier

Scnario nominal : Ce cas dutilisation commence lorsque la demande est tablie
auprs du service de facturation.
Enchanement (a) : crer la fiche client
Si le client existe : [Exception1 : ClientExistant]
Enchanement (b) : valider la fiche client
Si le client de type particulier et sans date de naissance : [Exception2 : Incomplet]
Enchanement (c) : Modifier la fiche client
Exceptions :
[Exception1 : ClientExistant] : un message derreur saffiche lcran avisant
lutilisateur que la fiche existe dj pour ce client.
[Exception2 : Incomplet] : un message derreur saffiche lcran avisant lutilisateur
que les infos du client sont incomplets et quil reste la date de naissance
Post conditions : Validation de la fiche client.

Figure 5:Diagramme dactivit du cas grer des infos client

Cas d'utilisation " Grer la commande "
Titre : Grer la commande
Rsum : le client effectue la commande auprs dune des agences, aprs avoir vrifi
les informations du client auprs du service de facturation, le client rempli le bon de
commande
sauthentifier
Scnario nominal : Ce cas dutilisation commence lorsque le client vient passer une
commande auprs dune agence.
Enchanement (a) : passer la commande
Enchanement (b) : tablir le bon de commande
Enchanement (c) : Vrifier les informations du client
Si les informations du client sont fausses : [Exception1 : ErreurInfos]
Exceptions :
[Exception1 : ErreurInfos] : un message derreur saffiche lcran avisant
lutilisateur que les informations sont incorrectes.
Post conditions : Etablissement du bon de commande.


Figure 6:diagrame d'activit du cas grer la commande

Cas d'utilisation " Grer la livraison "
Titre : Grer la livraison
Rsum : lagence vrifie ltat du stock et vrifie les infos client auprs du service de
facturation pour savoir ltat de la remise et aprs elle tablit le bon de livraison
sauthentifier
Scnario nominal : Ce cas dutilisation commence lorsque le bon de commande est
tabli.
Enchanement (a) : vrifier le stock
Si la quantit du produit est indisponible : [Exception1 : QtIndispo]
Enchanement (b) : Vrifier ltat de la remise
Enchanement (c) : tablie le bon de livraison
Exceptions :

[Exception1 : ErreurInfos] : un message derreur saffiche lcran avisant
lutilisateur que la quantit demande est indisponible actuellement.
Post conditions : Etablissement du bon de livraison.

Figure 7:Diagramme dactivit du cas grer la livraison

Cas d'utilisation " Grer la facturation "
Titre : Grer la facturation
Rsum : le service de facturation tablit une facture chaque bon de livraison reu
ensuite lenvoi au comptable pour lcrire au journal de ventes
Acteurs : Comptabilit, Service de facturation
Pr conditions : les responsables de la comptabilit et le service de facturation doivent
sauthentifier

Scnario nominal : Ce cas dutilisation commence lorsque le bon de livraison est
arriv au service de facturation.
Enchanement (a) : tablir la facture
Enchanement (b) : criture dans le journal de ventes
Post conditions : Mettre jour le journal de ventes.

Figure 8:Diagramme dactivit du cas grer la facturation

Cas d'utilisation " Mettre jour le catalogue "
Titre : Mettre jour le catalogue
Rsum : La direction met jour le catalogue (Ajout de nouveaux produits et/ou
modification des prix unitaires des produits existants) aprs avoir reu les propositions
de nouveaux produits en provenance du fournisseur
Acteurs : direction, fournisseur
Pr conditions : le responsable de la direction doit sauthentifier
Scnario nominal : Ce cas dutilisation commence lorsque les propositions du
fournisseur sont arrives la direction.
Enchanement (a) : Mettre jour le catalogue

Enchanement (b) : Ajouter des nouveaux produits
Si le produit existe : [Exception1 : ProduitExistant]
Enchanement (c) : Modifier les prix unitaires
Si le produit nexiste pas : [Exception2 : ProduitInexistant]
Exceptions :
[Exception1 : ProduitExistant]: un message derreur saffiche lcran avisant
lutilisateur que le produit existe dj.
[Exception2 : ProduitInexistant]: un message derreur saffiche lcran avisant
lutilisateur que le produit nexiste pas
Post conditions : la mise jour du catalogue valide

Figure 9:Diagramme dactivit du cas mettre jour le catalogue

3-Structuration des cas dutilisations dans des packages
Cette phase va permettre de structurer les cas dutilisations en groupes fortement
cohrents, ceci afin de prparer le terrain pour la prochaine phase qui est le dcoupage en
catgories .
Dfinition : un package reprsente un espace de nommage qui peut contenir :
Des lments dun modle.

Des diagrammes qui reprsentent les lments du modle.
Dautres packages.
La structuration des cas dutilisations se fait par domaine dexpertise mtier c..d. les
lments contenus dans un package doivent reprsenter un ensemble fortement cohrent et
sont gnralement de mme nature et de mme niveau smantique.

Cas dutilisation Acteurs Packages
Consulter le catalogue Client, fournisseur, agence,
service de facturation, direction

Gestion du catalogue
Modifier le catalogue La direction de la socit
AGRI
Grer le stock Agence Gestion du stock
Grer les informations des clients Service de facturation

Gestion client
Grer les commandes du client Agence, Service de facturation
Grer la livraison des produits Agence, Service de facturation

Gestion de la livraison
Grer la facturation Service de facturation
Mettre jour le journal de ventes Comptabilit

III-Capture des besoins techniques
La capture des besoins techniques couvre avec celle des besoins fonctionnels, toutes les
contraintes qui ne traitent ni de la description du mtier des utilisateurs, ni de la description
applicative. Cette tape ncessite une connaissance des prrequis techniques. Le modle s'y
exprime suivant les deux points de vue qui sont la spcification logicielle et la structure du
matriel exploiter.
1-Spcification technique du point de vue matriel
Les choix techniques sont de nature gographique, organisationnelle, et technique. Elles
concernent les performances d'accs aux donnes, la scurit du systme, l'interoprabilit, la
volumtrie et le mode d'utilisation du systme. Ils impliquent des contraintes relatives la
configuration du rseau matriel
2-Configuration matriel du systme
Dans cette partie on va prsenter l'utilisation de l'infrastructure physique par le systme et
la manire dont les composants du systme sont rpartis ainsi que leurs relations entre
eux. Pour cela on va utiliser un diagramme de dploiement :

LAN
Internet
LAN
LAN
Agences
Appl i cati on
Comptabi l i t
Appl i cati on
di recti on
Appl i cati on
servi ce de facturati on
Appl i cati on
Serveur
Appl i cati on
Base de donnes

Figure 10:diagramme de dploiement

Nous avons un serveur principal qui se trouve dans le sige o est installe la base de
donnes. Les trois agences ont besoin de linternet pour pouvoir accder au serveur
contrairement la direction, le service de facturation et la comptabilit qui sont centraliss au
sige
IV-Analyse
1-Dveloppement du modle statique
Le dveloppement du modle statique constitue une tape importante de la phase de
conception. Ce modle rassemble les diffrentes classes et associations du systme. Cette
partie va nous permettre dillustrer les principales constructions du diagramme de classes
UML durant ltape danalyse. Le diagramme de classes a toujours t le diagramme le plus
important dans toutes les mthodes orientes objet. Cest galement celui qui contient la plus
grande gamme de notation et de variantes. Les diagrammes de classes expriment de manire
gnrale la structure statique dun systme, en terme de classes et de relations entre ces
classes. De mme quune classe dcrit un ensemble dobjets, une association dcrit un
ensemble de liens ; les objets sont instances de classes et les liens sont instances des relations.

Figure 11:Diagramme de classes participantes au processus de ventes de la socit AGRI


2-Dveloppement du modle dynamique

Cette partie va nous permettre dillustrer lutilisation des concepts dynamiques dUML et
des diagrammes associs en phase danalyse en dcrivant des scnarios mettant en jeu un
ensemble dobjets changeant des messages. Ces interactions seront dcrites au moyen de
diagrammes de squence qui met laccent sur la chronologie des messages.
Il faut signaler que tous les scnarios possibles ne peuvent tre numrs et dcrits du fait
quils en existent beaucoup. Cest pour cette raison que nous allons faire une description des
scnarios les plus pertinents.

a) Scnario dauthentification :

Figure 12:Diagramme de squence du scnario Authentification

b) Scnario dajout/Modification dun profil dutilisateur :

Figure 13:Diagramme de squence du scnario Ajout/Modification dun profil

c) Scnario dalimentation du stock :

Figure 14:Diagramme de squence du scnario Alimentation du stock


d) Scnario de passer une commande :

Figure 15:Diagramme de squence du scnario passer une commande

e) Scnario de ltablissement de la facture:

Figure 16:Diagramme de squence du scnario Etablir la facture


f) Scnario de cration du bon de livraison:

Figure 17:Diagramme de squence du scnario cration du bon de livraison

g) Scnario dajout dune fiche client:

Figure 18:Diagramme de squence du scnario Cration dune fiche client

h) Scnario de modification des informations sur le client:

Figure 19:Diagramme de squence du scnario Modification de la fiche client

i) Scnario de modification du catalogue:

Figure 20:Diagramme de squence du scnario Modifier catalogue

Construction des diagrammes dtats :

On recourt au concept de machine tats finis, qui consiste sintresser au cycle de vie
dun objet gnrique dune classe particulire au fil de ses interactions avec les autres classes,
dans tous les cas possibles. 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.

Dfinition : 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.
a) Diagramme dtats de la classe Personne :

Figure 21:Diagramme dtats-transitions de la classe Personne

b) Diagramme dtats de la classe Catalogue :

Figure 22:Diagramme dtats-transitions de la classe Catalogue


c) Diagramme dtats de la classe Commande :

Figure 23:Diagramme dtats-transitions de la classe Commande
d) Diagramme dtats de la classe Facture :

Figure 24:Diagramme dtats transitions de la classe Facture
e) Diagramme dtats de la classe Client :

Figure 25:Diagramme dtats-transitions de la classe Client

Chapitre 2
Ralisation

Le choix du langage sest port vers Java, qui tant Orient Objet la base, nous
facilitera la transformation de notre modle objet vers le code. La programmation peut se faire
pour des exemples simples avec le compilateur javac, mais pour avoir plus de confort il est
prfrable d'utiliser un environnement de dveloppement intgr ou IDE. Notre choix sest
port vers lEDI NetBeans, qui nous fournit le confort et la simplicit ncessaires un
dveloppement propre et rapide.
1-Outils de dveloppement :
1-1 NetBeans
NetBeans est un environnement de dveloppement intgr (EDI), plac en Open
Source par Sun. En plus de Java, NetBeans permet galement de supporter diffrents autres
langages, comme C, C++, JavaScript, PHP, HTML Il comprend toutes les
caractristiques d'un IDE moderne (diteur en couleur, projets multi-langage, refactoring,
diteur graphique d'interfaces et de pages Web).
Conu en Java, NetBeans est disponible sous Windows, Linux, Solaris, Mac OS X ou
sous une version indpendante des systmes d'exploitation (requrant une machine virtuelle
Java). Un environnement Java Development Kit (JDK) est requis pour les dveloppements en
Java.
L'IDE Netbeans s'enrichit l'aide de plugins.


Figure 26:IDE Netbeans 6.9.1
1-2PowerAMC

PowerAMC est un logiciel de conception cr par la socit SDP, qui permet de
modliser les traitements informatiques et leurs bases de donnes associes.
PowerAMC permet de raliser tous les types de modles informatiques. Il reste un des
seuls qui permet de travailler avec la mthode Merise. Selon Riff News, cela permet
d'amliorer la modlisation, les processus, le cot et la production d'applications.

Figure 27:PowerAMC


1-3Langage de programmation : JAVA
C'est un langage de programmation orient objet, dvelopp par Sun Microsystems. Il
permet de crer des logiciels compatibles avec de nombreux systmes dexploitation
(Windows, Linux, Macintosh, Solaris). Java donne aussi la possibilit de dvelopper des
programmes pour tlphones portables et assistants personnels. Enfin, ce langage peut tre
utilis sur internet pour des petites applications intgres la page web (applet) ou encore
comme langage serveur (jsp).
2-Prsentation de lapplication ralise :
Structure gnrale de lapplication :
Lapplication est dcoupe 2 en couches distinctes, Prsentation et Mtier.
La couche Prsentation est charge de tout ce qui est affichage.
La couche Mtier est la logique mtier de lapplication, elle est le coeur et cest elle
qui dfinit toutes les rgles rgissantes au fonctionnement de lapplication.
a) Le stockage de donnes : La technique choisie pour persister les donnes est : la
srialisation. Une technique plus aboutie aurait t un meilleur choix comme : le
mapping Objet/Relationnel avec un outil comme Hibernate. Cependant,
lapprentissage de cet outil demande un temps supplmentaire. Mais la solution de la
srialisation rponds largement nos besoins pour ce projet, cest pour a que nous
avons jug pertinent de la garder.

b) La couche Mtier :
Voici quelques figures reprsentants un chantillon du code source de cette couche :


Figure 28:Classe Log qui permet de coder lauthentification de lutilisateur

Figure 29:Classe Saisie produit qui permet linsertion dun nouveau produit dans le catalogue


Figure 30: Classe LireEtEcrire qui permet la Srialisation (La sauvegarde et le chargement) des
donnes

c) La couche Prsentation :

Voici quelques figures reprsentants linterface du logiciel :

Figure 31:Fentre daccueil


Figure 32:Fentre didentification

Figure 33: Menu administrateur


Figure 34:Fentre de saisie de nouveaux produits

Figure 35: Fentre dajout de nouveau client


Figure 36: Fentre de saison de la commande

Figure 37:Fentre des Listes des clients


Figure 38: Fentre du catalogue

3-Conclusion :
Nous pouvons constater que lajout de nouvelles fonctionnalits peut tre simplifi, pour
peu quon respecte bien les tapes dfinies par 2TUP. a demande de faire une itration
complte ou partielle selon le besoin, du cycle Y, et ne pas succomber la tentation de
toucher rapidement au code.

Conclusion gnrale

Nous avons tent travers ce projet de dmontrer limportance de lapplication dune
mthode de dveloppement. Nous pensons aussi que 2TUP pourra tre utilise dans des
projets de moyenne grande envergure. A titre personnel, le bnfice quon en a tir est
lapprentissage de concepts la pointe de la technologie et des tendances actuelles dans le
monde professionnel. Une recherche profonde a t indispensable pour essayer de
comprendre ces concepts-l. Ce projet nous a permis denrichir nos connaissances dans des
domaines trs varis comme : LOrient Objet, UML, 2TUP, le langage JAVA, Swing En
termes dvolution, lapplication pourra par la suite tre adapte une utilisation Plus vaste
par intgration dune base de donnes qui pourra tre utilise soit par le biais dun pont JDBC,
ou par le biais dune solution de Mapping Objet/ Relationnel comme Hibernate. Aussi, un
dploiement sur un rseau pourra tre fait grce au framework J2EE. Nous esprons que la
lecture de ce rapport a t agrable et claire.

Bibliographie
Cours de UML vue cette anne en deuxime anne lENSIAS
Cours sur le processus 2tup fait cette anne par Mr Kriouille
Meyer, B. (2000). Conception et Programmation orientes objet. Eyrolles.
Pitman, N. (2006). UML 2 en concentr. O'Reilly.

Webographie
http://laurent-audibert.developpez.com/Cours-UML/html/Cours-UML.html
http://uml.free.fr/index-cours.html
http://java.developpez.com/cours/

Rapport - PFA Processus 2tup PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport - PFA Processus 2tup PDF

Transféré par

Droits d'auteur :

Formats disponibles

Ecole Nationale Suprieure dInformatique

et dAnalyse des Systmes

Vous aimerez peut-être aussi