Table des matires Introduction 1 Chapitre I Analyse et spcification des besoins 3 1 Analyse et spcification des besoins 4 1.

1 Introduction : 4 1.2 Prsentation de l'environnement du stage : 4 1.2.1 Prsentation de SOTOTEL Info : 4 1.3 Contexte et motivation du projet 5 1.3.1 Contexte 5 1.3.2 Critique de l'existant 5 1.3.3 Travail demand 5 1.3.4 Approche de solution 5 1.4 Conclusion 6 Chapitre II Mthodes et outils 7 2 Mthodes et outils 8 2.1 Introduction : 8 2.2 Avantages de l'approche oriente objet : 8 2.3 Les architectures n-tiers : 8 2.3.1 Architecture utilisant un serveur centr : 8 2.3.2 Architectures n-tiers : 9 2.4 Model View Control (MVC) : 9 2.5 Nuance entre MVC et 3-Tiers : 9 2.6 Mthodes et outils pour l'application : 10 2.6.1 Choix des outils de conception : 10 2.6.1.1 Choix du principe et du logiciel de modlisation : 10
1

2.6.2 Choix des outils de dveloppement : 11 2.6.2.1 Choix du langage de programmation : 12 2.6.2.2 Choix de l'outil de dveloppement : 13 2.6.2.3 Choix du SGBD : 14 2.6.2.3.1 Oracle Database 15 2.6.2.3.2 Access 17 Chapitre III La conception 18 3 La conception 19 3.1 Introduction : 19 3.2 La modlisation dynamique : 19 3.2.1 Diagramme des cas d'utilisation : 19 3.2.2 Diagramme de squence : 24 3.3 Modlisation Statique : 27 3.3.1 Diagramme de classes : 27 3.3.2 Modle conceptuel des donnes (modle physique) : 30 Chapitre IV La ralisation 32 4 La ralisation : 33 4.1 Introduction : 33 4.2 Modles de cycles de vie d'un logiciel : 33 4.2.1 Modle de cycle de vie en cascade 33 4.2.2 Modle de cycle de vie en V 33 4.2.3 Modle de cycle de vie en spirale 35 4.2.4 Modle par incrment : 36 4.2.5 Modle de prototypage : 36 4.3 Prsentation de l'application dveloppe : 37
2

4.3.1 Fentre d'accueil : 38 4.3.2 Itinraire suivi pour l'dition d'une commande : 38 4.3.3 Quelques interfaces. 43 4.4 Droulement du projet : 49 4.5 Conclusion : 49 Conclusion et perspectives 50 Bibliographie 52 Annexes 54

Introduction De l'ge de la pierre nos jours, l'esprit perfectionniste de l'homme n'a cess de lui permettre d'amliorer sa vie quotidienne. Le passage de la mcanique aux domaines d'informatique, d'lectronique, d'automatique et de domotique a rvolutionn la vie journalire de l'tre humain. Les nouvelles technologies de l'information et de communication illustrent ce phnomne. Aujourd'hui, vu l'intrt croissant de vouloir gagner en temps, de conserver les donnes, de limiter le nombre d'employs et pas mal d'autres raisons, ont pouss petites, moyennes et grandes entreprises chercher des solutions informatiques capables de rpondre leurs besoins. Dans ce cadre s'inscrit notre projet de fin d'tudes qui consiste raliser une application sur mesure de gestion commerciale pour une socit de ventes des matriels informatiques. Ce travail est ralis en vue d'obtention du diplme de matrise en informatique l'Institut Suprieur d'Informatique de Charguia (ISET). Pour atteindre notre objectif on a partag le travail comme suit :Le premier chapitre s'agit d'une prise de connaissance de l'existant pour savoir de ce que doit tre capable de faire et de quoi va servir notre futur application en d'autres termes il s'agit d'une analyse et spcification des besoins. Dans le second chapitre on va faire notre choix sur les mthodes et outils utiliser pour raliser l'application. Le troisime chapitre sera consacr la conception de l'application il s'agit d'une phase de modlisation thorique de l'application. Avant de clore on va essayer de prsenter les rsultats obtenus dans le quatrime chapitre.

1 Chapitre I Analyse et spcification des besoins 2 Analyse et spcification des besoins

2.1 Introduction :
Il s'agit d'une tape cruciale dans la ralisation d'une application donne. Le futur d'un logiciel dpend beaucoup de cette phase, elle nous permet d'viter le dveloppement d'une application non satisfaisante. Pour cela le client et le dveloppeur doivent tre en troites relations, voire avoir un intermdiaire entre eux s'il le faut. Pour arriver nos fins il nous faut prendre connaissance de : L'analyse et la dfinition des besoins : permet de trouver un commun accord entre les spcialistes et les utilisateurs. L'tude de la faisabilit : Le domaine d'application, l'tat actuel de l'environnement du futur systme, les ressources disponibles, les performances attendues, etc. Etablissement du cahier des charges. Le prsent chapitre va nous donner un aperu global de l'application.

1.2 Prsentation de l'environnement du stage :

1.2.1 Prsentation de SOTOTEL Info : CRISTAL Info est une socit informatique base Monastir plus prcisment dans les locaux de CYBERPARC, elle fournit plusieurs services informatiques. 1.2.2 Activits de SOTOTEL Info : Les activits de SOTOTEL Info sont trs varies, on peut mentionner quelques unes : Conception et dveloppement des sites web Conception, scurisation et audit de rseaux.
5

 Conception et mise en place des bases de donnes. Dveloppement d'applications. Rdaction des cahiers de charges.

2.3 Contexte et motivation du projet

2.3.1 Contexte Comme on l'a cit prcdemment, SOTOTEL Info n'est pas une socit consommatrice, elle est plutt productrice. Toutes les applications dveloppes sont destines alors la vente. L'application en question s'agit d'une commande d'une boutique de vente des matriels informatiques. Il s'agit donc d'une application de gestion commerciale spcialise dans le domaine de vente informatique cette solution doit tre capable d'automatiser les taches qui sont faites l'heure actuelle manuellement. 2.3.2 Critique de l'existant La solution actuelle est manuelle : L'abondance des documents dans l'entreprise peut ralentir les services. On peut en avoir besoin de plus d'employs pour se partager les taches. Risque de mlanger les documents : ce qui peut tre fatal. La suivie des clients et des fournisseurs peut rencontrer beaucoup de problmes. La perte de la clientle est possible au cas o le traitement de leurs demandes traine. 2.3.3 Travail demand Notre travail consiste concevoir et dvelopper une application informatique qui permettra la gestion automatique des clients, des fournisseurs, du stock, etc. Autrement dit notre but est de concevoir et dvelopper un logiciel de gestion commercial adaptable aux conditions cites prcdemment (gestion des clients, des fournisseurs, du stock,...). 2.3.4 Approche de solution En tenant compte des critiques et des besoins d'informatiser les services cits ci-dessus la solution est de concevoir et dvelopper une application permettant de satisfaire au maximum
6

possible le client. Pour cela l'application doit rpondre aux besoins suivants : Avoir un logiciel performant Avoir un logiciel qui respecte les principes des Interfaces Homme/Machine (IHM) tels que l'ergonomie et la fiabilit. Rduire les taches manuelles qui nous permettraient de gagner en spatio-temporel Archiver les informations Avoir un logiciel volutif et paramtrable

2.4 Conclusion
L'tude pralable appele techniquement ingnierie des exigences ou analyse et spcification des besoins, constitue une phase capitale dans le cas o toute la suite du projet dpend d'elle, elle doit tre faite avec beaucoup de rigueur et plus d'attention pour que le projet russisse avec un grand succs. Dans ce chapitre, on a expos les problmes de la socit et de l'existant, puis nous avons fait les critiques du travail manuel et enfin on a fait une approche de solution qui consiste concevoir et dvelopper une application qui facilitera les services numrs prcdemment. Aprs avoir fix nos objectifs, pour atteindre notre but on doit suivre plusieurs tapes ces dernires constituent une partie du cycle de vie de tout projet informatique. Ainsi dans l'tape suivante on va se consacrer sur le choix des mthodes et outils de la ralisation.

Chapitre II La conception
7

4 La conception
4.1 Introduction :
La plupart des nouveaux langages sont orients objet. Le passage de la programmation fonctionnelle l'orient objet n'tait pas facile. L'un des soucis tait d'avoir une ide globale en avance de ce qu'on doit programmer. L'algorithmique qui tait utilis dans la programmation fonctionnelle ne pourrait pas suffire lui seul. Le besoin d'avoir des mthodes ou langages pour la modlisation des langages orients objet se faisait sentir. Ainsi plusieurs mthodes ou langages on vu le jour. En occurrence UML qui nous a permis de faire la conception de notre application. De nos jours UML2 possde treize diagrammes qui sont classs en deux catgories (dynamique et statique). Pour ce faire on a commenc par les diagrammes de cas d'utilisation (Use Case) qui permettent de donner une vue globale de l'application. Pas seulement pour un client non avis qui aura l'ide de sa future application mais aussi le dveloppeur s'en sert pour le dveloppement des interfaces. En deuxime lieu on va prsenter la chronologie des oprations par les diagrammes de squences. Et finir par les diagrammes statiques qui sont celles des classes et le modle physique.

4.2 La modlisation dynamique :

Comme on l'a dit UML2 possde treize diagrammes. Quant la catgorie dynamique elle seule est associe huit diagrammes. Dans notre application on va s'en servir des deux seulement noncs ci-dessus. On ne peut pas aller directement la conception sans faire une petite description du fonctionnement de l'application. 4.2.1 Diagramme des cas d'utilisation : Le but de ces diagrammes et d'avoir une vision globale sur les interfaces du futur logiciel. Ces diagrammes sont constitus d'un ensemble d'acteurs qui agit sur des cas d'utilisation. Les acteurs :

UML n'emploi pas le terme d'Utilisateur mais d'acteur. Les acteurs d'un systme sont les entits externes ce systme qui interagissent avec lui. Suivant les besoins de notre systme on peut prsenter deux acteurs. Il s'agit d'un administrateur et un agent travaillant pour la socit. La manire d'accder aux services de l'application pour l'un et pour l'autre est la mme. La diffrence rside sur les droits d'accs et les limites de chacun. L'agent : Celui-ci s'agit d'un simple employeur mais pour restreindre l'accs notre application personne ne peut y accder sans s'authentifier. L'agent a comme rle de : Grer les ventes. Grer les achats. Grer les fournisseurs. Grer les clients. Grer le stock. L'administrateur : Qui paye le plus paye le moins , comme l'administrateur se place en dessus de l'agent celui-ci peut faire part les taches de l'agent mais aussi grer ces derniers. Ceci est intressant car UML prsente le critre d'hritage entre les acteurs. Donc on pourra faire l'administrateur un hritier de l'agent et on va lui ajouter la particularit de pouvoir gestion des agents.

Prsentation globale des cas d'utilisation :

Figure 2. Diagramme global des cas d'utilisation En observant la figure ci-dessus on a presque l'ide complte de l'application (interface). Dans les parties qui suivent on va essayer de dtailler le diagramme de chaque acteur agissant sur le systme Diagramme des cas d'utilisation de l'agent : Dans les paragraphes prcdents on a dcrit ce que peut de chaque acteur ici on ne va pas rcrire la mme chose. Juste on va donner un schma qui montre l'interaction de l'agent aux interfaces de l'application.

10

Figure 3. Diagramme des cas d'utilisation d'un agent Diagramme des cas d'utilisation de l'administrateur : L'administrateur est un hritier de l'agent (Figure 2). Il peut grer les agents comme il peut faire les autres gestions.

11

Figure 4. Diagramme des cas d'utilisation pour administrateur Les cas d'utilisations. Avec ses multiples relations (extend, include, etc.), nous donne une vue presque relle de l'application. (Pour des informations complmentaires voir Annexe 1). Cette richesse nous montre une vue globale de l'application mais pour voir rellement la succession des actions des acteurs il nous faut un autre modle (diagramme) qui nous dtaille le squencement des oprations ce diagramme s'agit du diagramme des squences. Ce dernier comme son nom l'indique il dveloppe un cas d'utilisation en montrant les diffrentes oprations permettant de raliser l'action du cas en question. Vu le grand nombre de cas de notre application, en tenant compte du nombre limite de pages imposes pour la rdaction de ce prsent mmoire, on a choisi quatre qu'on donnera leurs diagrammes de squences. Ce choix n'est pas un fruit du hasard mais on a essay de regrouper les cas en diffrentes catgories qu'on a classes selon l'importance et les ressemblances des cas et enfin prendre dans chacune un pour illustrer.

12

Ces quatre catgories sont : Catgorie Authentification Gestion des ventes/achats Grer les agents Cas choisi agent diter une facture ajouter un agent

Grer les fournisseurs/clients/produits ajouter un produit

Tableau 1. Partage des cas d'utilisation en catgories

4.3 Modlisation Statique :

Prcdemment on a parl des deux grandes catgories de diagrammes UML (statique et dynamique) l'un des diagrammes statiques nous intresse beaucoup pour pouvoir implmenter le code, il s'agit du diagramme de classes 4.3.1 Diagramme de classes : Ce modle nous permet d'avoir une vue statique de l'application. Il nous montre les relations entre les diffrentes entits (classes) composant notre application. Il nous mne vers la solution finale. partir de ce diagramme on retrouve les corps des diffrentes classes de notre application. Mieux encore en utilisant la technique de l'ingnierie (voir Annexe 3) on obtient une grande partie du code finale.

13

Figure 9. Diagramme de classes Le schma ci-dessus nous donne une vue globale de notre application. On a les classes principales qui vont nous servir raliser l'application. Pour avoir de plus amples informations sur l'autre partie de notre application on peut penser reprsenter le modle conceptuel de donnes (modle physique) il s'agit de reprsenter les donnes et les diffrentes relations entre elles. Ce modle nous a permis de construire notre base de donne, car chaque entit est associe une table dans la base de donne. Faisons un feed-back sur le diagramme des classes et faisons quelques dtails : Client : Un client peut avoir plusieurs factures comme il peut avoir plusieurs commandes et plusieurs devis, et quand il reoit un produit il doit avoir un bon de livraison. Fournisseur :

14

Il reoit un ou plusieurs commandes de la socit, donc il va donner une facture et un bon de livraison au moment de la livraison Facture, bon de commande, Devis, bon de livraison: Ici il s'agit du cot vente, donc ils doivent possder chacun une rfrence, un code client, une date et un ou plusieurs produits. On peut avoir des transformations comme l'indique la table suivante : Peut tre transform(e) Facture Facture BL BC Devis ******* Non Oui Oui BL Oui ******* Oui Oui BC Non Non ******* Oui Devis Non Non Non *******

Tableau 2. Tableau des transformations. Peut tre transform(e) AB Facture, bon de commande, bon de livraison: Ici il s'agit du cot achat, donc ils doivent possder chacun une rfrence, un code fournisseur, une date et un ou plusieurs produits. Ici on n'a pas besoin des transformations. Produit : Un produit est caractris par sa rfrence, sa dsignation, sa catgorie, son type, la quantit, sa marque, tva et son prix d'achat. Administrateur/agent : C'est seulement les deux personnes qui ont accs physiquement l'application. Ils grent les clients, les fournisseurs, les factures, les commandes et les bons. Il est vident que l'administrateur hrite de l'agent, car c'est lui seul qui peut grer les agents. 4.3.2 Modle conceptuel des donnes (modle physique) : On a utilis MERISE pour pouvoir implmenter notre base de donnes, ce modle nous permet d'avoir une ide sur les tableaux qui composent notre base. Evidemment il y'a des rgles qui permettent de passer d'un modle un autre. (Pour plus d'informations voir Annexe 3).

15

Figure 10. Modle physique des donnes Chapitre III La ralisation

5 La ralisation :
5.1 Introduction :
Arriv ce stade nous pouvons nous estimer heureux, il ne reste qu' commencer crire notre code en se basant sur les rsultats obtenus des chapitres prcdents. Mais cela se fait en suivant des critres. On doit passer par plusieurs jalons pour avoir un produit de bonne qualit. Ces techniques qu'on les appelle modles de cycles de vie d'un logiciel sont bien expliques par le gnie logiciel. Ces modles nous ont accompagns du dbut du projet jusqu' l'implmentation de celui-ci. Ainsi dans ce chapitre on va essayer de donner un bref aperu sur quelques modles et choisir le modle adopter, prsenter les rsultats de notre travail et finir par une petite conclusion.

5.2 Modles de cycles de vie d'un logiciel :

16

5.2.1 Modle de cycle de vie en cascade Le modle de cycle de vie en cascade a t mis au point ds 1966, puis formalis aux alentours de 1970. Dans ce modle le principe est trs simple : chaque phase se termine une date prcise par la production de certains documents ou logiciels. Les rsultats sont dfinis sur la base des interactions entre tapes, ils sont soumis une revue approfondie et on ne passe la phase suivante que s'ils sont jugs satisfaisants. Le modle original ne comportait pas de possibilit de retour en arrire. Celle-ci a t rajoute ultrieurement sur la base qu'une tape ne remet en cause que l'tape prcdente, ce qui est dans la pratique s'avre insuffisant. (Voir Figure 11) 5.2.2 Modle de cycle de vie en V Le modle en V demeure actuellement le cycle de vie le plus connu et certainement le plus utilis. Le principe de ce modle est qu'avec toute dcomposition doit tre dcrite la recomposition, et que toute description d'un composant doit tre accompagne de tests qui permettront de s'assurer qu'il correspond sa description. Ceci rend explicite la prparation des dernires phases (validation-vrification) par les premires (construction du logiciel), et permet ainsi d'viter un cueil bien connu de la spcification du logiciel : noncer une proprit qu'il est impossible de vrifier objectivement aprs la ralisation. (Voir Figure 12).

Figure 11. Modle du cycle de vie en cascade

17

Figure 11. Modle du cycle de vie en V Figure 12. Modle du cycle de vie en V 5.2.3 Modle de cycle de vie en spirale Propos par B. Boehm en 1988, ce modle est beaucoup plus gnral que le prcdent. Il met l'accent sur l'activit d'analyse des risques : chaque cycle de la spirale se droule en quatre phases : dtermination, partir des rsultats des cycles prcdents, ou de l'analyse prliminaire des besoins, des objectifs du cycle, des alternatives pour les atteindre et des contraintes. Analyse des risques, valuation des alternatives et, ventuellement maquettage. Dveloppement et vrification de la solution retenue, un modle classique (Cascade ou en V) peut tre utilis ici ; Revue des rsultats et vrification du cycle suivant. L'analyse prliminaire est affine au cours des premiers cycles. Le modle utilise des maquettes exploratoires pour guider la phase de conception du cycle suivant. Le dernier cycle se termine par un processus de dveloppement classique.

18

Figure 13. Modle de cycle de vie en spirale 5.2.4 Modle par incrment : Dans les modles prcdents un logiciel est dcompos en composants dvelopps sparment et intgrs la fin du processus. Dans les modles par incrment, un seul ensemble de composants est dvelopp la fois : des incrments viennent s'intgrer un noyau de logiciel dvelopp au pralable. Chaque incrment est dvelopp selon l'un des modles prcdents. Les avantages de ce type de modle sont les suivants : chaque dveloppement est moins complexe. les intgrations sont progressives. il est ainsi possible de livrer et de mettre en service chaque incrment. il permet un meilleur lissage du temps et de l'effort de dveloppement grce la possibilit de recouvrement (paralllisation) des diffrentes phases. Les risques de ce type de modle sont les suivants :

19

 Remettre en cause les incrments prcdents ou pire le noyau. Ne pas pouvoir intgrer de nouveaux incrments. Les noyaux, les incrments ainsi que leurs interactions doivent donc tre spcifis globalement, au dbut du projet. Les incrments doivent tre aussi indpendants que possibles, fonctionnellement mais aussi sur le plan du calendrier du dveloppement. 5.2.5 Modle de prototypage : Un prototype : Un modle excutable d'un systme logiciel, qui souligne des aspects spcifiques Caractristiques : Un degr lev de participation du client Une reprsentation tangible des exigences du client Trs utile quand les exigences sont instables ou incertaines Avantages: participation du client : Le client participe activement dans le dveloppement du produit Le client reoit des rsultats tangibles rapidement Le produit rsultant est plus facile utiliser et apprendre Applicabilit : Pour des systmes interactifs de petite et moyenne taille Pour des parties de grands systmes (par exemple l'interface utilisateur) Pour des systmes avec une vie courte

Figure 14. Modle de prototypage Il existe pas mal de modles, mais ici on a essay d'expliquer les plus connus et les plus utiliss actuellement. Le choix du modle est prendre au srieux puisque il n'y a pas un modle parfait et c'est difficile de se baser sur un seul modle, n'empche d'avoir un modle
20

de rfrence. Cependant, un ou plusieurs modles peuvent bien s'adapter un cas donn par rapport d'autres. En ce qui concerne notre application, il s'agit d'un logiciel destin la vente donc on doit tre en relations troites avec le client. Il lui faut temps en temps des maquettes d'essai. Raison pour laquelle on a choisi le modle de prototypage qui nous permet de prsenter au client un prototype et l'amliorer jusqu' avoir un produit fini satisfaisant. On peut faire ici des feed-back.

5.3 Prsentation de l'application dveloppe :

Notre application s'agit d'un logiciel commercial sur mesure permettant de grer les achats, les ventes, le stock et d'offrir l'utilisateur quelques accessoires savoir un calendrier et une aide sous fourme FAQ (Foire Aux Questions). La multitude des taches que notre application est capable de faire engendre un grand nombre de fentres. Pour des effets esthtiques on a essay d'utiliser deux types de container (JFrame et JDialog) selon les informations afficher. On va essayer de slectionner quelques unes qui nous paraissent important pour les intgrer dans ce prsent mmoire. 5.3.1 Fentre d'accueil :

C'est la premire fentre qui s'affiche si on excute l'application toute personne qui veut bnficier des services du logiciel doit s'authentifier (on rappelle que l'application est livr avec un pseudo Administrateur et un mot de passe). Aprs authentification une fentre principale s'affiche et les boutons sont activs selon les droits d'accs de la personne authentifie. On a le choix entre Admin et agent Figure 15. Fentre d'accueil (authentification) 5.3.2 Itinraire suivi pour l'dition d'une commande : Cette fentre (Figure 16) gre presque toute l'application la plupart des fentres qui vont
21

s'ouvrir y prennent source. La fentre est divise en quatre grandes parties : La partie inferieure qui est compos par les taches de gestion des ventes, des achats, du stock, et des utilitaires. En cliquant sur une parmi ces taches, son icne est activ et un panel contenant les boutons reprsentant les diffrentes sous taches s'ouvre droite. Au milieu on a deux boutons qui grent respectivement les fournisseurs et les clients. Quant gauche, on a la gestion du personnel (ajout agent) et ce bouton n'est activ que si l'administrateur s'est authentifi. Pour tre objectif, traitons le cas d'enregistrement d'une commande d'un client : Aprs authentification de l'administrateur on a l'interface suivante :

Figure 16. Fentre de Mensualit pour un capitale

5.4 Droulement du projet :

Tache Etude pralable Conception Dveloppement Dure Pourcentage 5 jours 5 jours 10 jours 10% 10% 20% 20%

Rdaction du rapport 10 jours

Tableau 3. Tableau du droulement

22

5.5 Conclusion :
Dans ce chapitre on a prsent en premier lieu quelques modles du cycle de vie d'un logiciel. On a justifi notre choix sur le modle de rfrence qu'on a choisi (prototypage). Vu le grand nombre des interfaces composant notre application, en second lieu on s'est content de donner quelques unes qui nous paraissent plus importantes. On a essay au maximum possible prsenter une seule interface s'il y' a plusieurs ayant des similarits. Et la fin, on a donn un tableau rsumant le droulement du projet. Conclusion et perspectives Ce projet tait bnfique pour nous dans plusieurs sens. Il nous a permis : o de nous perfectionner en amliorant nos connaissances en programmation et en conception. o De bien comprendre et mettre en oeuvre le droulement d'un cycle de vie d'un logiciel. o De dcouvrir le monde de l'entreprise (fonctionnement). Nous avons essay de raliser ce projet pour le but de faciliter l'entreprise en question, d'amliorer la gestion et le suivi de ses clients, de ses fournisseurs et de son stock. On a appliqu au maximum possible les rgles de bases permettant d'avoir une application performante. Nous avons appliqu UML pour concevoir une grande partie de notre travail. Nous avons utilis aussi Java et Access pour implmenter notre application. Grce aux architectures que nous avons utilis (MVC et client/serveur) et du fait que Java est un langage adaptable dans plusieurs domaines, notre application peut avoir des extensions ou des modifications dans le futur. Citons quelques unes : o On peut lier cette application un site web dynamique qui nous permettra le suivi des clients et des fournisseurs en ligne. o On peut changer le SGBD au cas o l'entreprise aura des donnes volumineuses stocker. o Dans l'avenir quand l'entreprise aura besoin de plusieurs agents travaillant en mme temps en rseau, on peut utiliser le concept Remote Method Invocation (RMI) : appels des mthodes distant

23

Bibliographie Ouvrages lectronique KELLER, Nicolas ROUQUET, Maxime. - KellerRouquet [ FORMTEXT en ligne ], 03/03/2006. AUDIBERT, Laurent - Cours-UML.[en ligne] GOLLOT, Eric - les cas utilisation. DI SCALA, Robert - Initiation la programmation. http://www.developpez.com Wikipdia : http://fr.wikipedia.org LATIRI Chiraz.-Cours Gnie logiciel. M.DIMASSI Jamil.- Mthodologie de conception UML. Travaux universitaires GHARSALLI Alia et BEN AMMAR Amel. - Conception et dveloppement d'une application de gestion de socit de services. - Projet de fin d'tudes, ISIMM.

24

Annexes Annexe 1 cas d'utilisation Le diagramme des cas d'utilisation qui fait partie des modles dynamique d'UML2 sert entreautre un moyen de communication entre les spcialistes et le client, et d'un outil nous permettant d'avoir une ide sur les principales interfaces de l'application. Utilisateurs - Acteurs UML n'emploi pas le terme d'Utilisateur mais d'acteur. Les acteurs d'un systme sont les entits externes ce systme qui interagissent avec lui. Quand on dit qui interagissent , on veut dire qui envoient des vnements comme, cliquer sur un bouton OK ou encore envoyer un fichier de donnes ou une trame XML. On veut aussi dire qui reoivent des informations de la part du systme comme, recevoir une facture, mettre jour un rfrentiel de donnes ou encore mettre jour une application back-office. Les acteurs sont donc l'extrieur du systme et dialoguent avec lui. Ces acteurs permettent de cerner l'interface que le systme va devoir offrir son environnement. Oublier des acteurs ou en identifier de faux conduit donc ncessairement se tromper sur l'interface et donc la dfinition du systme produire. On fera attention ne pas confondre acteurs et utilisateurs d'un systme. Non pas que cela soit faux car tout dpend du sens donn au mot utilisateur mais trop souvent, le mot utilisateur est vu comme un raccourci pour dsigner ceux qui vont cliquer dans les fentres de l'application. Les acteurs sont plus que les simples utilisateurs humains d'un systme. D'une part parce que les acteurs inclus les utilisateurs humains mais aussi les autres systmes informatiques ou hardware qui vont communiquer avec le systme. Pour trouver les acteurs d'un systme, on va identifier quels sont les diffrents rles que vont devoir jouer ses utilisateurs. Car les acteurs sont en fait les rles jous par ces diffrents Utilisateurs (ex : Responsable clientle, Responsable d'agence, Administrateur, Approbateur,...). On regardera ensuite quels sont les autres systmes avec lesquels le systme va devoir communiquer soit en mode rception soit en mode mission d'vnements (ex : Hardware d'un distributeur de billet, Systme d'information partenaire, ERP,...). Un biais classique dans l'identification des acteurs est d au fait que les acteurs peuvent aussi tre d'autres systmes. Aussi, il est frquent de vouloir identifier comme acteur les rfrentiels de donnes existant dans le systme d'information. Effectivement, le Systme produire aura srement rcuprer ou mettre jour des donnes issues de ces rfrentiels, mais le risque d'identifier ces systmes comme acteur est qu'ensuite, lors de la rdaction des cas d'utilisation, on risque de rentrer trop tt dans la solution et oublier l'expression premire du besoin. Je ne dis pas qu'identifier ce type d'acteur est une erreur fondamentale mais l'exprience montre que l'intrt est minime et que les biais induits sont

25

nfastes : une description des cas d'utilisation plus proche de la solution que du besoin. Les cas d'utilisation Les cas d'utilisation vont ici nous aider dcrire ces attendus. On entend souvent que les cas d'utilisation permettent de dcrire les fonctionnalits attendues du systme de point de vue des acteurs. Ce n'est pas faux mais attention car fonctionnalits se transforme souvent en fonctions . On en arrive donc utiliser les cas d'utilisation pour faire un dcoupage fonctionnel au sens procdures des langages procduraux. Et l, on se trompe compltement d'objectif. Ces fonctionnalits que l'on documente avec les cas d'utilisation doivent avoir un sens pour le mtier des acteurs. Pour identifier les cas d'utilisation, il faut donc se poser les questions : ?? Mais que va faire cet acteur avec le systme en arrivant le matin au boulot ? ?? Pourquoi dmarre t-il le systme, avec quel objectif mtier ? En se posant ce type de question, on verra que gnralement des cas d'utilisation comme Rechercher client ou Imprimer facture ne sont pas des cas d'utilisation mais plutt des fonctions du systme. L'important avec les cas d'utilisation est de bien dcrire ce que l'on pourrait dsigner savamment par unit d'intention complte . C'est--dire une srie d'envois d'vnements de la part de l'acteur au systme et de rponses du systme pour atteindre un objectif mtier prcis. Et non les diffrentes fonctions du systme qui seront en fait dduites des diffrents cas d'utilisation. Un cas d'utilisation est donc compos des lments suivants : Un nom : Utiliser un verbe l'infinitif (Ex : Rceptionner un colis) Une description rsume permettant de comprendre l'intention principale du cas d'utilisation. Cette partie est souvent renseigne au dbut du projet dans la phase de dcouverte des cas d'utilisation. Des acteurs dclencheurs : ceux qui vont raliser le cas d'utilisation (la relation avec le cas d'utilisation est illustre par le trait liant le cas d'utilisation et l'acteur dans un diagramme de cas d'utilisation) Des acteurs secondaires : ceux qui ne font que recevoir des informations l'issue de la ralisation du cas d'utilisation (Ex : client ou autre systme informatique. La relation avec le cas d'utilisation est illustre par le trait liant le cas d'utilisation et l'acteur dans un diagramme de cas d'utilisation) Des pr-conditions qui dcrivent dans quel tat doit tre le systme (l'application) avant que ce cas d'utilisation puisse tre dclench (Ex : un contrat existe avec le client). Des scnarii. Ces scnarii sont dcrits sous la forme d'changes d'vnements entre l'acteur et le systme. On classe les scnarii en : Un scnario nominal (celui qui est droul quand il n'y a pas d'erreur, celui qui est principalement ralis dans 90% des cas), des scnarii alternatifs qui sont les variantes du scnario nominal et enfin les scnarii d'exception qui
26

dcrivent les cas d'erreurs. Des post-conditions qui dcrivent l'tat du systme l'issue des diffrents scnarii (Ex : un contrat est cr et le systme back-office est mis jour avec le nouveau contrat cr) Des informations sur l'utilisation du cas d'utilisation comme : le nombre de personnes excutant ce cas d'utilisation dans une journe type, le nombre d'objets (mtiers !) traits par le cas d'utilisation dans une journe type (Ex : 120 contrats crs entre septembre et novembre, 2000 consultations des contrats par jour). Eventuellement une description des besoins en termes d'interface graphique. Ce chapitre tant rserv des cas simples car gnralement trait en dehors de la description mme du cas d'utilisation. Dans ce cas une cohrence doit d'ailleurs tre assure entre l'IHM et la description du cas d'utilisation. Les relations entre cas d'utilisation UML dfinit 3 grands types de relations entre cas d'utilisation : gnralisation/spcialisation, include, extends. Il est important de noter que l'utilisation de ces relations n'est pas primordiale dans la rdaction des cas d'utilisation et donc dans l'expression du besoin. Ces relations peuvent tre utiles dans certains cas mais une trop forte focalisation sur leur usage conduit souvent une perte de temps ou un usage fauss, pour une valeur ajoute, au final, relativement faible. Extends : La relation d'extend est probablement la plus utile car elle a une smantique qui a un sens du point de vue mtier au contraire des 2 autres qui sont plus des artifices d'informaticiens. On dit qu'un cas d'utilisation X tend un cas d'utilisation Y lorsque le cas d'utilisation X peut tre appel au cours de l'excution du cas d'utilisation Y comme :

27

Figure 28. Relation extend Ce type de relation est primordial pour l'criture de l'application. Imaginer dans le cas prcdent que l'on n'ait pas mis la relation extends . Cela signifierait que lors de la prise de commande pour un nouveau client, le processus de prise de commande devrait tre annul au moment de la saisie des informations client, pour d'abord excuter Enregistrer client afin que le client soit connu puis ensuite, reprendre le processus de prise de commande depuis le dbut ; pas cool pour notre responsable clientle et bonjour l'image commerciale donne au client ! Include : La relation d'include n'a pour seul objectif que de factoriser une partie de la description d'un cas d'utilisation qui serait commune d'autres cas d'utilisation. Le cas d'utilisation inclus dans les autres cas d'utilisation n'est pas proprement parl un vrai cas d'utilisation car il n'a pas d'acteur dclencheur ou receveur d'vnement2. Il est juste un artifice pour faire de la rutilisation d'une portion de texte. Une erreur classique est d'utiliser la relation d'include pour faire du dcoupage fonctionnel d'un cas d'utilisation en plusieurs sous cas d'utilisation qui s'enchanent en fonction de certains critres. On en arrive alors se demander : Comment documenter l'enchanement des sous cas d'utilisation avec UML ? Mais cette question n'a en fait pas lieu d'tre, tout simplement.

Figure 29. Relation include Gnralisation / spcialisation Cette relation est de mon point de vue la relation la plus discutable du point de vue de son utilit pratique. Elle consiste dire que l'on a un cas d'utilisation dit de base , gnrique, qui dcrit des squences d'vnements et d'autres cas d'utilisation qui hritent de ce comportement de base et le spcialise suivant diffrents critres (le comment de la chose reste nbuleux). On pourra par exemple avoir une situation comme

28

Figure 30. Relation gnralisation/spcification Conclusion On espre vous avoir un peu clair sur cette espce que sont les cas d'utilisation et surtout sur leur bon usage. On espre aussi que vous aurez compris qu'il est inutile de compliquer leur utilisation en introduisant la notion de relation et que les cas d'utilisation deviennent simples si on s'en tient rpondre la question : Mais est ce que ce cas d'utilisation un sens du point de vue mtier pour l'acteur, n'est ce pas une vision informaticienne de son besoin ? Les dtails d'informaticiens seront abords lors des activits d'analyse et de conception. Ne soyons pas press et exprimons d'abord le besoin et ensuite la solution. Annexe 2 Rgles de passage du modle conceptuel au modle physique (MCD MLD) Table et cl primaire : Toute classe ou entit (=objet de gestion) est transforme en table. Les attributs de l'entit deviennent les attributs de la table. L'identifiant de la classe/entit devient la cl primaire de la table.

Figure 31. Table et cl primaire. Relation binaire (...,*) - (...,1) : La cl primaire de l'entit relie par (..., 1) devient cl trangre de l'entit relie par (...,*).

Figure 32. Relation binaire (...,*) - (...,1).

29

Relation binaire (0.1) - (1.1) : La cl primaire de l'entit relie par (0, 1) devient cl trangre de l'entit relie par (1, 1).

Figure 33. Relation binaire (0.1) - (1.1). Relation binaire et ternaire (...,*) - (...,*) : On cre une table supplmentaire ayant comme cl primaire une cl compose des cls primaires des deux entits. Lorsque la relation contient elle-mme des proprits, celles-ci deviennent attributs de

30