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
Projet de Fin dAnne 2012-2013 Page 4 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
Projet de Fin dAnne 2012-2013 Page 5 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
Projet de Fin dAnne 2012-2013 Page 6 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
Projet de Fin dAnne 2012-2013 Page 7 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
Projet de Fin dAnne 2012-2013 Page 8
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
Projet de Fin dAnne 2012-2013 Page 9 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
Projet de Fin dAnne 2012-2013 Page 10
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.
Projet de Fin dAnne 2012-2013 Page 11 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.
Projet de Fin dAnne 2012-2013 Page 12 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.
Projet de Fin dAnne 2012-2013 Page 13 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.
Projet de Fin dAnne 2012-2013 Page 14 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.
Projet de Fin dAnne 2012-2013 Page 15
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. 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 fusion conduit lobtention dun processus en forme de Y. Cette branche comporte les tapes suivantes : La conception prliminaire. La conception dtaille. Le codage. Lintgration.
Projet de Fin dAnne 2012-2013 Page 16
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)
Projet de Fin dAnne 2012-2013 Page 17 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.
Projet de Fin dAnne 2012-2013 Page 18
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).
Projet de Fin dAnne 2012-2013 Page 19 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.
Projet de Fin dAnne 2012-2013 Page 20 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.
Projet de Fin dAnne 2012-2013 Page 21
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
Projet de Fin dAnne 2012-2013 Page 22 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.
Projet de Fin dAnne 2012-2013 Page 23 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.
Projet de Fin dAnne 2012-2013 Page 24 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
Projet de Fin dAnne 2012-2013 Page 25 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
Projet de Fin dAnne 2012-2013 Page 26 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
Projet de Fin dAnne 2012-2013 Page 27 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.
Projet de Fin dAnne 2012-2013 Page 28
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
Projet de Fin dAnne 2012-2013 Page 29 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] Enchanements alternatifs : 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
Projet de Fin dAnne 2012-2013 Page 30 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 Acteurs : Agence, Service de facturation Pr conditions : les responsables dagence et service de facturation doivent 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 Enchanements alternatifs : 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.
Projet de Fin dAnne 2012-2013 Page 31
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 Acteurs : Agence, Service de facturation Pr conditions : les responsables dagence et service de facturation doivent 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 :
Projet de Fin dAnne 2012-2013 Page 32 [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
Projet de Fin dAnne 2012-2013 Page 33 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 Enchanements alternatifs :
Projet de Fin dAnne 2012-2013 Page 34 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.
Projet de Fin dAnne 2012-2013 Page 35 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
Projet de Fin dAnne 2012-2013 Page 36 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
Projet de Fin dAnne 2012-2013 Page 37 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
Projet de Fin dAnne 2012-2013 Page 38
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
Projet de Fin dAnne 2012-2013 Page 39 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
Projet de Fin dAnne 2012-2013 Page 40
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
Projet de Fin dAnne 2012-2013 Page 41
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
Projet de Fin dAnne 2012-2013 Page 42 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.
Projet de Fin dAnne 2012-2013 Page 43 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
Projet de Fin dAnne 2012-2013 Page 44
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
Projet de Fin dAnne 2012-2013 Page 45 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.
Projet de Fin dAnne 2012-2013 Page 46
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
Projet de Fin dAnne 2012-2013 Page 47
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 :
Projet de Fin dAnne 2012-2013 Page 48
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
Projet de Fin dAnne 2012-2013 Page 49
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
Projet de Fin dAnne 2012-2013 Page 50
Figure 32:Fentre didentification
Figure 33: Menu administrateur
Projet de Fin dAnne 2012-2013 Page 51
Figure 34:Fentre de saisie de nouveaux produits
Figure 35: Fentre dajout de nouveau client
Projet de Fin dAnne 2012-2013 Page 52
Figure 36: Fentre de saison de la commande
Figure 37:Fentre des Listes des clients
Projet de Fin dAnne 2012-2013 Page 53
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.
Projet de Fin dAnne 2012-2013 Page 54 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.
Projet de Fin dAnne 2012-2013 Page 55 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.