rapport_PFA Processus 2tup.pdf

Ecole Nationale Supérieure d’Informatique

et d’ A   A nalyse nalyse des Systèmes

Mémoire de Projet de Fin de 2ème année

Sujet :

Conception Orienté Objet et Réalisation du cas Agri selon le processus 2tup

Réalisé par : Othmane MAHBOUB

Encadré par : M. Abdelaziz KRIOUILE

Amine MAJDOUL

 Année Universitai Universitaire re : 2012-2013 : 2012-2013

Remerciements

Remerciements

Il nous est agréable de nous acquitter d’une dette de reconnaissance auprès de toutes les  personnes dont l’intervention au cours de ce projet a favorisé son aboutissement. Tout d’abord nous adressons nos vifs remerciements re merciements à notre encadrant Monsieur KRIOUILE  pour ses directives précieuses et ses conseils pertinents qui nous ont été d’un appui considérable dans la réalisation de notre projet.  Nous ne saurions saur ions oublier dans nos remerciements r emerciements tout t out le cadre professoral professora l de l’ENSIAS,  pour la formation consistante qu’il nous a prodiguée. Que tous ceux qui nous ont aidés, aidés , de prés ou de loin, trouvent ici l’expression de nos sentiments les meilleurs. Enfin, nous présentons notre profond respect aux membres du jury notamment Monsieur ELKETTANI pour leur bienveillance bienveillance à vouloir évaluer notre travail

Projet de Fin d’Année

2012-2013

Page 3

Résumé

Résumé :  Nous proposons dans le cadre de ce projet de fin d’études, d’appliquer la méthode 2TUP au problème de la gestion des ventes de la société AGRI. La gestion d’un cycle de vie de logiciel requit un grand sens de la rigueur et de l’adaptation aux changements continuels imposés au monde de l’entreprise. C’est pour ça que nous avons choisi d’axer notre travail sur une méthode de développement qui est née de travaux poussés vers la standardisation et la flexibilité, et ce  pour répondre aux contraintes actuelles de gestion des développements. développements. Le mémoire sera découpé en 5 grands chapitres :

1. Introduction : Introduction : nous parlerons dans ce chapitre des objectifs que nous voudrions atteindre, atteindre, ainsi qu’un aperçu des différentes méthodes existantes. 2TUP : ce chapitre contient les définitions des différents 2. La méthode 2TUP : concepts utilisés dans ce document.

3. Conception du logiciel : c’est ici que nous allons appliquer la méthode 2TUP au problème de la gestion des enseignements en suivant les phases suivantes : l’étude préliminaire,

Projet de Fin d’Année

2012-2013

Page 4

Liste des abréviations abréviations

Liste des abréviations

Abréviation

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 d’Année

2012-2013

Page 5

Liste des figures Figure 1:Le système d’information soumis à deux types de contraintes ................................. ................................. 15 Figure 2:Le 2: Le processus pr ocessus de développement en Y ............................................ ................................................................... ............................ ..... 16 Figure 3:Diagramme des cas d’utilisations .......................................... ................................................................. .................................... ............. 26 Figure 4: diagramme d’activité d’activité du cas « s’authentifier » s’authentifier » ................................ ...................................................... ......................... ... 28 Figure 5:Diagramme d’activité du cas « gérer des infos client »  » ............................................ ........................................... 29 Figure 6:diagrame d'activité d'activit é du cas « gérer la commande » .................................... .................................................... ................ 31 Figure 7:Diagramme d’activité du cas « gérer la livraison» .......................................... ................................................... ......... 32 Figure 8:Diagramme d’activité d’activité du cas « gérer la facturation» facturation » ........................................... ................................................ ..... 33 Figure 9:Diagramme d’activité du cas «mettre à jour le catalogue»  catalogue» ....................................... ...................................... 34 Figure 10:diagramme de déploiement ........................ ............................................... .............................................. ....................................... ................ 36 Figure 11:Diagramme de classes participantes au processus de ventes de la société AGRI ... 37 Figure 12:Diagramme de séquence du scénario scénari o « Authentification »...................................... »...................................... 38 Figure 13:Diagramme de séquence du scénario « Ajout/Modification d’un profil »  .............. 39 Figure 14:Diagramme de séquence du scénario « Alimentation du stock s tock » ............................ ............................ 39 Figure 15:Diagramme de séquence du scénario passer une commande .................................. .................................. 40 Figure 16:Diagramme de séquence du scénario s cénario Etablir la facture .......................... ........................................... ................. 40 Figure 17:Diagramme de séquence du scénario création du bon de livraison ........................ ........................ 41 Figure 18:Diagramme de séquence du scénario Création d’une fiche client  client  ........................... 41 Figure 19:Diagramme de séquence du scénario s cénario Modification de la fiche client ..................... 42 Figure 20:Diagramme de séquence du scénario s cénario Modifier catalogue .................................. ....................................... ..... 42 Figure 21:Diagramme d’états-transitions d’états-transitions de la classe Personne ............................................ .............................................. .. 43 Figure 22:Diagramme d’états-transitions d’états-transitions de la classe cla sse Catalogue .......................................... ............................................ .. 43 Figure 23:Diagramme d’états-transitions d’états-transitions de la classe Commande ............................ .......................................... .............. 44 Figure 24:Diagramme d’états transitions de la classe Facture  Facture ................................................. ................................................ 44 Figure 25:Diagramme d’états-transitions d’états-transitions de la classe Client .......................................... ................................................... ......... 44 Figure 26:IDE Netbeans 6.9.1 ............................................ .................................................................. ............................................ ................................ .......... 46 Figure 27:PowerAMC ............................................................... ..................................................................................... ............................................. ......................... .. 46 Figure 28:Classe 28:Classe Log qui permet de coder l’authentification de l’utilisateur  .......................... ......................... 48 Figure 29:Classe Saisie produit qui permet l’insertion d’un nouveau produit dans le catalogue ........................................... .................................................................. ............................................. ............................................ ............................................. .................................... ............. 48 Figure 30: Classe LireEtEcrire qui permet la Sérialisation (La sauvegarde et le chargement) des données .......................................... ................................................................. ............................................. ............................................ ....................................... ................. 49 Figure 31:Fenêtre d’accueil ........................................... ................................................................. ............................................ .................................... .............. 49

Projet de Fin d’Année

2012-2013

Page 6

Figure 32:Fenêtre d’identification .......................................... ................................................................ ............................................ ............................ ...... 50 Figure 33: Menu administrateur .................................. ........................................................ ............................................ ....................................... ................. 50 Figure 34:Fenêtre de saisie sais ie de nouveaux produits ....................................... ............................................................. ............................ ...... 51 Figure 35: Fenêtre d’ajout de nouveau client ........................................... .................................................................. ................................ ......... 51 Figure 36: Fenêtre de saison de la commande ........................................................... ......................................................................... .............. 52 Figure 37:Fenêtre des Listes des clients ............................................ ................................................................... ....................................... ................ 52 Figure 38: Fenêtre du catalogue ..................................... ........................................................... ............................................ .................................... .............. 53

Liste des tableaux Tableau 1:description des besoins fonctionnels ............................ .................................................. ........................................... ..................... 23 Tableau 2:identification des cas d'utilisation ............................................................. ........................................................................... .............. 26

Projet de Fin d’Année

2012-2013

Page 7

Tables des matières Remerciements ............................................ .................................................................. ............................................ ............................................. .................................. ........... 3 Résumé : ........................................... ................................................................. ............................................ ............................................ ............................................. ....................... 4 Liste des abréviations ..................................................... ........................................................................... ............................................. ...................................... ............... 5 Liste des figures ........................................... ................................................................. ............................................ ............................................. .................................. ........... 6 Liste des tableaux ....................................................... .............................................................................. .............................................. ......................................... .................. 7 Introduction générale ............................................. ................................................................... ............................................ ........................................... ..................... 10 1.1

Le contexte de travail .................................................... .......................................................................... ........................................... ..................... 10

1.2

Objectifs .......................................... ................................................................. ............................................. ............................................. ............................ ..... 10

1.3

Comparaison entre les différentes approches .......................................... ........................................................... ................. 11

1.3.1

Modélisation ........................................... ................................................................. ............................................ .................................... .............. 11

1.3.2

Conduite de projet ..................................................... ........................................................................... ....................................... ................. 11

1.4

Présentation de l’application à réaliser . ...................................................... .................................................................... .............. 11

Description de la méthode 2TUP ............................................ .................................................................. ............................................ ......................... ... 12 2.1

Définition d’un processus de developpement logiciel ........................................... ............................................. .. 13

2.2

Le processus unifié .................................. ........................................................ ............................................ ........................................... ..................... 13

2.3

Le processus 2TUP......................................... ............................................................... ............................................ .................................... .............. 14

2.4

Un processus de modélisation avec UML ........................................... ................................................................ ..................... 16

.................................................................... ............................................. ............................................ ....................................... ................. 18 Chapitre 1 ............................................. ................................................................. ............................................ ........................................... ..................... 18  Analyse et Conception ........................................... I-Etude préliminaire ............................................ .................................................................. ............................................ ............................................. ......................... .. 18 1-Présentation du projet à réaliser .................................. ........................................................ ............................................. ................................ ......... 18 2-Recueil des besoins fonctionnels ...................................................... ............................................................................. ................................ ......... 18 3-Choix techniques .......................................... ................................................................ ............................................ ............................................. ......................... .. 19 4-Identification des acteurs ............................................ .................................................................. ............................................ ................................ .......... 20 5-Identification des messages .......................... ................................................ ............................................ ............................................ ......................... ... 21 6-Modélisation du contexte ........................................ .............................................................. ............................................ .................................... .............. 21 II-Capture des besoins fonctionnels .............................................. .................................................................... ........................................... ..................... 23 1-Déterminer 1-Déterminer les cas d’utilisations...................... d’utilisations ............................................ ............................................. ........................................... .................... 23 1-1Utilisation 1-1Utilisation d’outils de génération de diagrammes UML : .......................................... .......................................... 23 1-2Identification 1-2Identification des cas d’utilisations................... d’utilisations ......................................... ............................................ .................................... .............. 24

Projet de Fin d’Année

2012-2013

Page 8

2-Description 2-Description détaillée des cas d’utilisations ........................................... .................................................................. ............................ ..... 26 Cas d'utilisation " Authentification (identification (identificat ion utilisateurs) " .............................. .................................... ...... 27 Cas d'utilisation " Gérer Gére r les profils: " ........................................... .................................................................. .................................... ............. 28 Cas d'utilisation d'utilisat ion " Gérer les infos i nfos clients " ........................................... .................................................................. ............................ ..... 28 Cas d'utilisation " Gérer la commande " ................................................. ........................................................................ ......................... .. 30 Cas d'utilisation " Gérer Gére r la livraison " ....................................... ............................................................. ....................................... ................. 31 Cas d'utilisation " Gérer Gére r la facturation " ........................................... .................................................................. ................................ ......... 32 Cas d'utilisation d'utilisat ion " Mettre à jour le catalogue cat alogue " .......................... ................................................ ....................................... ................. 33 3-Structuration 3-Structuration des cas d’utilisations dans des packages ............................................ ..................................................... ......... 34 III-Capture des besoins techniques ........................................... ................................................................. ............................................ ......................... ... 36 1-Spécification technique du point de vue matériel ................................. ....................................................... ............................ ...... 36 2-Configuration matériel du système ................................................... .......................................................................... ................................ ......... 36 IV-Analyse ........................................... .................................................................. ............................................. ............................................ ....................................... ................. 37 1-Développement du modèle statique ........................................... .................................................................. ....................................... ................ 37 2-Développement du modèle dynamique ......................................... ............................................................... .................................... .............. 38 Construction des diagrammes d’états :  :. ........................................................... ............................................................................ ................. 42 Chapitre 2 ............................................ ................................................................... ............................................. ............................................ ....................................... ................. 45

.................................................................. ............................................. ............................................ ....................................... ................. 45 Réalisation ........................................... 1-Outils de développement : .......................................... ................................................................ ............................................ ................................ .......... 45 1-1 NetBeans ........................................... .................................................................. ............................................. ............................................. ............................ ..... 45 1-2PowerAMC ............................................ .................................................................. ............................................ ............................................. ......................... .. 46 1-3Langage de programmation : JAVA ................................ ...................................................... ........................................... ..................... 47 2-Présentation 2-Présentation de l’application réalisée :.............................................. :..................................................................... ................................ ......... 47 3-Conclusion : ............................................. .................................................................... ............................................. ............................................. ............................ ..... 53 Conclusion générale ............................................ .................................................................. ............................................ ............................................. ......................... .. 54

Projet de Fin d’Année

2012-2013

Page 9

Introduction générale 1.1

Le contexte de travail La complexité croissante des systèmes informatiques a conduit les concepteurs à s’intéresser

aux aux méthodes de développement. Ces dernières ont toujours essayé d’apporter un contrôle continu sur un projet tout au long de son processus de vie. Bien que des méthodes de développement existent depuis 30 ans (Merise, SADT), nous ne  pouvons constater aujour d’hui d’hui l’existence d’une règle qui soit à la fois formelle et commune aux différentes cultures. Par ailleurs, des méthodes séquentielles comme celles se basant sur le cycle en V, ont montré leur limite dans un environnement régi par des changements réguliers, impliquant une impossibilité à revenir en arrière, et de ce fait, laissant une très petite marge à l’erreur. Avec l’avènement de la pensée objet, de nouvelles méthodes sont apparues et différentes notations ont été établies. UML a ouvert le terrain de l’unification l ’unification en fusionnant ces notations et en apportant précision et rigueur à la définition des concepts introduits. Sur cet élan, les spécialistes ont aussi pensé à unifier non pas les processus, mais plus exactement les meilleures pratiques de développement orienté objet.

1.2

Objectifs

 Notre but est d’appliquer une méthode rigoureuse de conduite d’un projet réel. Le projet en question concerne la gestion des ventes. Ce projet a pour objectif principal de proposer une solution à un problème concret, et ceci en  partant d’une définition des besoins. Nous espérons à travers celuicelui-ci, démontrer l’importance de l’application d’une méthodologie de développement, et aussi permettre par la suite que ce produit  puisse être évolutif et facilement maintenable par des intervenants tiers. tiers.

Projet de Fin d’Année

2012-2013

Page 10

1.3

Comparaison entre les différentes approches

1.3.1

Modélisation

Par le passé, le modèle Entité-Relation représentait une grande partie des approches les plus utilisées. Actuellement, les nouvelles technologies s’appuient sur le modèle o bjet. En termes d’analyse et de modélisation objet, UML est devenu un standard incontournable, stabilisé, industriel.

1.3.2

Conduite de projet

Au début, le cycle en cascade (ex : le cycle en V) était très utilisé. Mais on a vite constaté son incapacité à s’adapter aux différents changements. Une méthode semi-itérative est apparut (RAD) pour pallier aux carences d e ce dernier. L’itératif s’est ensuite imposé, parce qu’il réduit la complexité de réalisation des phases, en travaillant par approches successives et incrémentales. Une méthode fortement axée sur l’itératif et le modèle UML est alors apparut, il s’agit de UP (Unified Process). Cette méthode comme son nom l’indique, a été le fruit de travail de plusieurs  personnes voulants « unifier » les différentes méthodes objets existantes à ce moment comme Booch, OMT et OOSE. On constate aujourd’hui, l’émergence d’une nouvelle approche : les méthodes agiles (Agile Modeling). C’est des méthodes itératives à planification souple qui leur permettent de s’adapter à la à la fois aux changements du contexte et de spécifications du projet. (Chromatic, 2005)

1.4

Présentation de l’application à réaliser De nos jours, une des tendances les plus en vue et qui concerne tout les secteurs de

développement, est l’informatisation. Depuis Depuis l’apparition de l’informatique et son introduction dans le monde économique, les entreprises et entités publiques aspirent à optimiser et à rendre fiable la gestion de leur structure interne.

Projet de Fin d’Année

2012-2013

Page 11

La société AGRI possède quelques milliers de clients qu’il est est difficile de gérer en continu. Alors la tâche de gestion gestion est très complexe. Le projet que nous proposons nous permettra de faciliter la gestion de ventes de la société, à travers la conception d’un logiciel avec une un e méthode que nous allons présenter.

Description de la méthode 2TUP Devant le nombre de méthodes disponibles, le choix parmi elles devient difficile, beaucoup de questions peuvent se poser à un chef de projet lors d’un démarrage de d e projet : Comment vais-je organiser les équipes de développement ; Quelles tâches attribuer à qui ; Quel temps faudrait-il pour livrer le produit ; Comment faire participer le client au développemen t afin de capter les besoins de celui-ci Comment éviter des dérives et de mauvaises estimations qui vont allonger les coûts et le temps de développement. Comment vais-je procéder pour que le produit soit évolutif et facilement maintenable.  Nous pouvons citer à ce propos les méthodes de développement objet suivantes : 2TUP, RUP, XP, AUP et OpenUP.  Notre choix s’est porté vers la vers la méthode 2TUP, du fait de son approche nouvelle, originale.  Notre projet est basé sur un processus de développement bien b ien défini qui va de la détermination des besoins fonctionnels attendus du système jusqu’à la conception et le codage final. Ce processus se base lui-même sur le Processus Unifié (Unified Process) qui est devenu un standard général réunissant les meilleures pratiques de développement. Cette méthode ne se base aucunement sur un processus linéaire mais bien, sur un développement itératif et incrémental.  Nous allons d’abord définir les différents concepts qui vont être utilisés utilisés dans ce document.

Projet de Fin d’Année

2012-2013

Page 12

2.1

Définition d’un processus de developpement developpement logiciel Un processus définit une séquence d’étapes, en partie ordonnées, qui concourent à l’obtention

d’un système logiciel ou à l’évolution d’un système existant. L’objet d’un processus de développement est de produire des logiciels de qualité qui répondent aux besoins de leurs utilisateurs dans des temps et des coûts p révisibles. (Rocques & Vallée, 2004)

2.2

Le processus unifié Le Processus Unifié (PU ou UP en anglais pour Unified Process) est une méthode de

développement logiciel construite sur UML ; elle est itérative et incrémentale, centrée sur l’architecture, conduite par les cas d’utilisation et pilotée par pilotée par les risques. itérative et incrémentale : la méthode est itérative dans le sens où elle propose de faire des itérations lors de ses différentes phases, ceci garantit que le modèle construit à chaque phase ou étape soit affiné et amélioré. Chaque itération peu t servir aussi à ajouter de nouveaux incréments. conduite par les cas d’utilisation : elle est orientée utilisateur pour répondre aux besoins de celui-ci. centrée sur l’architecture : les modèles définit tout au long du processus de développement vont von t contribuer à établir une architecture cohérente et solide.  pilotée par les risques : en définissant des priorités pour chaque fonctionnalité, on peut minimiser les risques d’échec du projet. La gestion d’un tel processus est organisée d’après les 4 phases phases suivantes : Pré-étude (Inception) : c’est ici qu’on évalue la valeur ajoutée du développement et la capacité technique à le réaliser (étude de faisabilité). Elaboration : sert à confirmer l’adéquation du système aux besoins des utilisateurs et à livrer l’architecture de base.

Projet de Fin d’Année

2012-2013

Page 13

Construction : sert à livrer progressivement toutes les fonctions du système. Transition : déployer le système sur des sites opérationnels. Chaque phase est elle-même décomposée séquentiellement en itérations limitées dans le temps (entre 2 et 4 semaines). Le résultat de chacune d’elles est un système testé, intégré et exécutable. L’approche itérative est fondée sur la croissance et l'affinement successifs d’un système par le biais d’itérations multiples. Le système croît avec le tem ps de façon incrémentale, itération par itération, et c’est pourquoi cette méthode porte également le nom de développement itératif et incrémental. Il s’agit là du principe le plus important du Processus Unifié. Ces activités de développement sont définies par 6 disciplines fondamentales qui décrivent la capture des besoins, la modélisation métier, l’analyse et la conception, l’implémentation, le test et le déploiement.  Notons que ces différentes différ entes étapes (ou disciplines) peuvent se dérouler à travers plusieurs  phases. Le processus unifié doit donc être compris comme une trame commune des meilleures  pratiques de développement.

2.3

Le processus 2TUP On dit de la méthode UP qu’elle est générique c.à.d. qu’elle définit un certain nombre de

critères de développement, que chaque société peut par la suite personnaliser afin de créer son  propre processus plus adapté à ses besoins. C’est dans ce cadre que la société Valtech a créé la méthode 2TUP. 2TUP signifie « 2 Track Unified Process» .C’est un processus qui répond aux caractéristiques du Processus Unifié. Le processus 2TUP apporte une réponse aux contraintes de changement continuel imposées aux systèmes d’information de l’entreprise. En ce sens, il renforce le contrôle sur les capacités d’évolution et de correction de tels systèmes. « 2 Track» signifie littéralement que le processus suit deux chemins. Il s’agit des « chemins fonctionnels » et « d’architecture technique », qui correspondent aux deux axes de changement imposés au système d’information.

Projet de Fin d’Année

2012-2013

Page 14

Figure 1:Le 1:Le système d’information soumis à deux types de contraintes

La branche gauche (fonctionnelle) : capitalise la connaissance du métier de l’entreprise. Elle constitue généralement un investissement pour le moyen et le long terme. Les fonctions fonctions du système d’information sont en effet indépendantes des technologies utilisées. Cette branche comporte les étapes suivantes : La capture des besoins fonctionnels, qui produit un modèle des besoins focalisé sur le métier des utilisateurs. L’analyse. La branche droite (architecture technique) : capitalise un savoir-faire technique. Elle constitue un investissement pour le court et moyen terme. Les techniques développées pour le système peuvent l’être en effet indépendamment des fonctions à réaliser. Cette branche comporte les étapes suivantes : La capture des besoins techniques. La conception générique. La branche du milieu : à l’issue des évolutions du modèle fonctionnel et de l’architecture technique, la réalisation du système consiste à fusionner les résultats des 2 branches. Cette fusion conduit à l’obtention d’un processus en forme de Y. Cette branche comporte les étapes suivantes : La conception préliminaire. La conception détaillée. Le codage. L’intégration.

Projet de Fin d’Année

2012-2013

Page 15

Figure 2:Le processus de développement en Y

2.4

Un processus de modélisation avec UML Le processus 2TUP s’appuie sur UML tout au long du cycle de développement, car les

différents diagrammes de ce dernier permettent de part leur facilité et clarté, de bien modéliser le système à chaque étape. « Unified Modeling Language » : UML se définit comme un langage de modélisation graphique et textuel destiné à comprendre et décrire des besoins, spécifier, concevoir des solutions et communiquer des points de vue. (Pitman, 2006) UML unifie à la fois les notations et les concepts orientés objet.il ne s’agit pas d’une simple notation, mais les concepts transmis par un diagramme ont une sémantique précise et sont porteurs de sens au même titre que les mots d’un langage, c’est pour ça qu’UML est  présenté parfois comme une méthode alors qu’il ne l’est absolument pas. UML unifie également les notations nécessaires aux différentes activités d’un processus de développement et offre, par ce biais, le moyen d’établir d’établir le suivi des décisions prises, depuis la définition des besoins jusqu’au codage. (Roques, 2006)

Projet de Fin d’Année

2012-2013

Page 16

Voici une présentation rapide des différents diagrammes UML qui vont être utilisés tout au long du projet : Le diagramme des cas d’utilisation d’utilisation   : représente la structure des fonctionnalités nécessaires aux utilisateurs du système. Il est normalement utilisé lors des étapes de capture des besoins fonctionnels et techniques. Le diagramme d’activités : représente les règles d’enchaînement des activités et actions actions dans le système. Il peut être assimilé comme un algorithme mais schématisé. Le diagramme de packages  packages   : présent depuis UML 2.0, ce diagramme modélise des catégories cohérentes entre elles, pour un souci de partage des rôles. Correspond à l’étape de modélisation modélisation des différents scénarios d’un cas d’utilisation. Le diagramme de classes : sûrement l’un des diagrammes les plus importants dans un développement orienté objet. Sur la branche fonctionnelle, ce diagramme est prévu pour développer la structure des entités manipulées par les utilisateurs. En conception, le diagramme de classes représente la structure d’un code orienté objet. Le diagramme de séquence : séquence : représente les échanges de messages entre objets, dans le cadre d’un fonctionnement particulier du système. Le diagramme d’états : représente le cycle de vie d’un objet. Il spécifie les états  possibles d’une classe et leur enchainement. Ce diagramme est utilisé lors des étapes d’analyse et de conception.

Projet de Fin d’Année

2012-2013

Page 17

Chapitre 1  Analyse et Conception I-Etude préliminaire L’étude préliminaire (ou Préetude) est la toute première étape du processus 2TUP. Elle consiste à effectuer un premier repérage des besoins fonctionnels et opérationnels, en utilisant  principalement le texte, ou diagrammes très simples. Elle prépare les activités plus formelles formelle s de capture des besoins fonctionnels et de capture techniques.

1-Présentation du projet à réaliser C’est un un logiciel qui qui doit gérer gérer les activités de la société AGRI, et ceci

concernant la

ventes de ses produits produits à ces clients, ainsi ainsi que la gestion gestion de son catalogue et du stock de chacune de ces agences.

2-Recueil des besoins fonctionnels Pour pouvoir établir l’ensemble des besoins fonctionnels de notre logiciel, nous nous sommes basés sur le texte figurant sur le polycopier po lycopier de l’élément de module Méthodologie de développement des systèmes d’information qu’on a étudié lors du premier semestre de cette 2ème année d’étude à l’ENSIAS, et ça nous a permis d’établir le cahier des charges  préliminaire suivant :  Gestion du catalogue : 

Ce catalogue est mis à jour tous les 6 mois par la direction de la société AGRI (Modification des prix unitaires des produits existants ou Ajout/Suppression de produits).

Projet de Fin d’Année

2012-2013

Page 18



Le catalogue mis à jour est envoyé par la suite aux agences de ventes, ainsi ainsi qu’au service de facturation.

 Gestion du stock : 

Chaque agence de la société AGRI gère son propre stock.

 Gestion des informations des clients : 

Un client peut modifier ses informations qui sont répertoriées dans sa fiche client en le demandant à l’une l’une des agences.



L’agence renvoie cette demande auprès du service de facturation qui va s’occuper de mettre à jour la fiche fi che du client concerné.

 Gestion des commandes des clients : 

Le client passe sa commande à l’une des agences de la société AGRI.



L’agence fait appel au service de facturation pour vérifier 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 de facturation par la suite.

 Gestion de la livraison : 

Un produit n’est livré que si la quantité commandée est disponible dans le stock de l’agence.



Un contrôle est effectué sur les informations du client et qui sont  portées sur le bon de livraison pour vérifier l’état de la remise.



Seul les clients de types détaillants ont droit à une remise.

 Gestion de la facturation : 

Le service de facturation établie une facture par bon de livraison reçu.



La comptabilité reçoit la facture et met à jour le journal de ventes de la société AGRI le lendemain de la transaction de vente.

3-Choix techniques Voici les choix techniques qui ont été adoptés pour le projet : o La modélisation avec UML.

Projet de Fin d’Année

2012-2013

Page 19

o

Adoption d’une architecture à 3 couches.

o

Utilisation du langage Java.

o

Omission d’une base de données au profit de d e la sérialisation (Java).

o

Utilisation de l’EDI NetBeans et de son plugin UML. UML.

4-Identification des acteurs  Nous allons maintenant énumérer les acteurs susceptibles d’interagir avec le système, mais d’abord nous donnons une définition de ce que c’est un acteur.

Définition :  un acteur représente l'abstraction d'un rôle joué par des entités externes (utilisateur, dispositif matériel ou autre système) qui interagissent directement avec le système étudié. Les acteurs du système identifiés dans un premier temps sont : clie nt  Client : Un client peut passer une commande, renseigner sa fiche client avec ses informations personnelles s’il est nouveau ou la modifier en cas de  besoin, et enfin il peut consulter le catalogue de la société AGRI. Fournisseur :: Le fournisseur peut consulter le catalogue, Proposer de  Fournisseur  nouveaux produits à la société à l’aide de son propre catalogue.  Direction Direction   : La direction peut consulter la fiche client (des clients de type

 particuliers) pour prévoir des actions publicitaires par la suite, et mettre à  jour le catalogue de la Société en modifiant le prix unitaire de certains  produits, ou en ajoutant/supprimant des des produits existants.  Agence : Chaque agence de la société AGRI s’occupe de traiter les

commandes de ces clients en établissant le bon de commande ainsi que le  bon de livraison des produits commandés, 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 Le service de facturation Peut Créer/modifier

la

fiche client, d’établir la facture pour les produits livrés ainsi que la consultation du catalogue et du bon de livraison pour contrôler les informations sur les clients.  Comptabilité : La comptabilité s’occupe de mettre à  jour le journal de

ventes de la société AGRI.  Administrateur  Administrateur :: Crée les profils utilisateurs et attribue les droits d’accès.

Projet de Fin d’Année

2012-2013

Page 20

5-Identification des messages On va détailler les différents messages échangés entre le système et l’extérieur.

Définition:

un

message

représente

la

spécification

d’une

communication

unidirectionnelle entre les objets qui transporte de l’information avec l’intention de déclencher une activité chez le récepteur.

L e systè systè me é m et l es messages messag es sui van va n t s : 

Le catalogue de la société AGRI.



La fiche client de chaque client enregistré dans la société.



Le bon de commande et le bon de livraison des commandes des clients de la société AGRI.



Le journal de vente de la société.



Le stock de chacune des agences de la société. s ociété.



La facture des produits livrés aux clients.

L e systè systèm e reç r eçoi t l es messages messages sui vant van t s :  La création, modification ou suppression de la fiche client.  La modification du catalogue (Ajout de nouveaux produits ou

modification des prix unitaires de ceux existants déjà).  La création du bon de commande, du bon de livraison et de la

facture.  La modification du journal de ventes de la société AGRI.  Modification du stock d’une agence de la société.

6-Modélisation du contexte A partir des informations obtenues lors des deux précédentes étapes, nous allons modéliser le contexte de notre application. Ceci va nous permettre dans un premier temps, de définir le rôle de chaque acteur dans le système Utilisateurs finaux

Description des besoins fonctionnels

Client

L’application doit permettr e au client de :  S’authentifier 

Projet de Fin d’Année

2012-2013

Page 21

 Passer une commande  Créer/Modifier sa fiche client  De consulter la facture des produits qui lui sont

livrés. Fournisseur

L’application doit permettre au fournisseur de : de  :  S’authentifier   Proposer de nouveaux produits.  Consulter le catalogue

Vendeur d’une agence

L’application doit permettre au vendeur d’une agence de : de  :  S’authentifier   Etablir le bon de commande, ainsi que le bon de

livraison des produits commandés par un client de l’agence.  Modifier le stock de l’agence concerné. concern é.  Consulter le catalogue

Responsable du Service

L’application doit permettre au responsable du service de

de facturation

facturation de :  S’authentifier.  Créer/Modifier la fiche client d’un client d’une

agence de la société.  Etablir la facture pour les produits livrés.  Consulter le catalogue.

Comptable

L’application doit permettre à un comptable du service de comptabilité de :  S’authentifier.  Mettre à jour le journal de ventes de la société

AGRI. Membre de la direction

L’application doit permettre à un membre de la direction de :  S’authentifier.

Projet de Fin d’Année

2012-2013

Page 22

 Consulter la fiche client  Mettre à jour le catalogue.

Administrateur

L’application

doit

permettre

à

l’administrateur

de

l’application de : de :  S’authentifier.  Créer des profils d’utilisateurs de l’application.  Attribuer des droits et des privilèges selon les

utilisateurs du système. Tableau 1:description des besoins fonctionnels

II-Capture des besoins fonctionnels Cette phase représente un point de vue « fonctionnel » de l’architecture  système. Par le  biais des cas d’utilisation, nous serons en contact permanent avec les acteurs du système en vue de définir les limites de celui-ci, celui-ci, et ainsi éviter de trop s’éloigner des besoins réels de l’utilisateur final.

1-Déterminer 1-Déterminer les cas d’utilisations d’utilisations Définition: un cas d’utilisation représente un ensemble de séquences d’actions réalisées  par le système et produisant un résultat observable intéressant pour un acteur particulier. Un cas d’utilisation modélise un service rendu par le système. Il ex prime les interactions acteurs/système et apporte une valeur ajoutée « notable » à l’acteur concerné.

1-1Utilisation 1-1Utilisation d’outils de génération de diagrammes UML : Tout au long du projet, nous sommes passés par plusieurs outils qui génèrent les diagrammes UML. Nous allons faire une présentation rapide de ceux là.

STAR UML : c’est un outil gratuit écrit avec Java, nous l’avons utilisé au début puis nous l’avons délaissé pour sa lourdeur et son interface peu intuitive. su r le marché, il est très puissant et agréable à Bouml : sûrement l’outil le plus léger sur utiliser, et en plus il est gratuit.

Projet de Fin d’Année

2012-2013

Page 23

1-2Identification 1-2Identification des cas d’utilisations L’identification des cas d’utilisation une première fois, nous donne un aperçu des fonctionnalités futures que doit implémenter le système. Cependant, il nous faut plusieurs itérations pour ainsi arriver à constituer des cas d’utilisation complets. D’autres cas d’utilisation vont apparaître au fur à mesure de la description de ceuxceux -là, et l’avancement dans le « recueil des besoins fonctionnels fo nctionnels ». Pour constituer les cas d’utilisation, il faut considérer l'intention fonctionnelle de l'acteur par rapport au système dans le cadre de l'émission ou de la réception de chaque message. En regroupant les intentions fonctionnelles en unités cohérentes, on obtient les cas d'utilisations.

Cas d’utilisation

Acteur

principal,

Acteurs

secondaires  Consulter le catalogue

M essa essag ges é m i s/ s/R Reçu s par l es acte acteur ur s 

Client, fournisseur, agence, service

de

facturation,

direction Modifier le catalogue

La direction de la AGRI

société Emet :

La

direction

met à jour le catalogue (Ajout de nouveaux  produits

et/ou

modification des prix unitaires des produits existants) Reçoit :  :   propositions

Les de

nouveaux produits en  provenance

du

fournisseur Gérer le stock 

Agence

Emet :  Le responsable du stock met à jour ce dernier suite à une vente d’un produit ou

Projet de Fin d’Année

2012-2013

Page 24

la suppression d’un autre du catalogue

Gérer les informations informations des clients

Service de facturation

Emet : Création/Modification de La fiche client Reçoit : La : La demande de Création/ modification des informations des clients de la part d’une des agences de la société.

Gérer les commandes du client

Agence, Service de facturation

Emet :

le

bon

de

commande Reçoit : La commande du client de la part du client

ainsi

que

l’approuvation

des

informations du client de la part du service de facturation. Gérer la livraison des produits

Agence, Service de facturation

Emet :

Le

bon

de

livraison Reçoit : Etat du stock de l’agence, Etat de la remise

Projet de Fin d’Année

2012-2013

Page 25

Gérer la facturation

Service de facturation

Emet :

établir 

la

facture des produits livrés Reçoit :

Bon

de

écrire

la

livraison Mettre à jour le journal de ventes

Comptabilité

Emet : facture

dans

le

 journal de ventes Reçoit : facture Tableau 2:identification des cas d'utilisation

Remarque : Ce premier tableau n'est pas définitif, un processus de développement avec UML est itératif, il se peut qu'il change au fur et à mesure de l 'avancement du projet.

Figure 3:Diagramme 3:Diagramme des cas d’utilisations

2-Description 2-Description détaillée des cas d’utilisations  Nous allons maintenant détailler chaque cas d’utilisation qui doit faire l’objet d’une définition a priori qui décrit l’intention de l’acteur lorsqu’il utilise le système et les séquences

Projet de Fin d’Année

2012-2013

Page 26

d’actions principales qu’il est susceptible d’effectuer. Ces définitions servent à fixer les idées et n’ont pas pour but de spécifier un fonctionnement complet et irréver sible.

Remarque : les descriptions vont être organisées de la façon suivante : 

Un sommaire d’identification : va résumer les propriétés du cas d’utilisation.



Une description détaillée : des Préconditions au déclenchement du cas d’utilisation doivent être spécifiées, un scénario nominal décrivant celui-ci additionné à des scénarios alternatifs et d’exceptions.



Les diagrammes (optionnelle (optionnelle): ): plusieurs diagrammes vont apparaitre (mais pas nécessairement) pour apporter une compréhension additive au cas d’utilisat ion.

Cas d'utilisation " Authentification (identification utilisateurs) " 

Titre : Authentification (identification utilisateurs)



Acteurs : Utilisateur.



Pré conditions : Introduire login et mot de passe



Scénario nominal : Ce cas d’utilisation commence lorsque l’utilisateur saisi son login et son mot de passe.



E nch aînement (a) : L’utilisateur valide les données saisies. Enchaînements alternatifs :



E nch aînement (b) : Vérifications de l’existence de l’utilisateur par le système.



E nch aînement (c) : Message de confirmation d’entrer à la session ou échec d’entrer.



Post conditions : Ouverture de l’espace personnel.

Projet de Fin d’Année

2012-2013

Page 27

Figure 4: diagramme d’activité du cas « cas « s’authentifier » s’authentifier »

Cas d'utilisation " Gérer les profils: " 

Titre : Titre : Gérer les profils:



Acteurs : Acteurs : Administrateurs



Pré conditions : Aucunes



Scénario nominal : Ce cas d’utilisation commence lorsque l’administrateur lance le logiciel.



E nch aînement (a) : Créer un profil en construction L’administrateur choisit un nom / mot de passe pour le compte. Il choisit le type de ce compte.



Post conditions : conditions : Validation du profil

Cas d'utilisation " Gérer les infos clients " 

Titre : Titre : Gérer les infos clients



Résumé : le client effectue la demande auprès d’une des agences, l’agence transmet la demande au service de facturation pour traitement





Acteurs : Agence, Service de facturation Pré conditions : les responsables d’agence et service de facturation doivent s’authentifier 

Projet de Fin d’Année

2012-2013

Page 28



Scénario nominal : Ce cas d’utilisation commence lorsque la demande est établie auprès du service de facturation.



E nch aînement (a) : créer la fiche client Si le client existe : [Exception1 : [Exception1 : ClientExistant]



E nch aînement (b) : valider la fiche client Si le client de type « particulier » et sans date de naissance : [Exception2 : Incomplet] Enchaînements alternatifs :



E nch aînement (c) : Modifier la fiche client Ex ceptions ceptions :



[Exception1 : ClientExistant] : un message d’erreur s’affiche à l’écran avisant l’utilisateur que la fiche existe déjà pour ce client.



[Exception2 : Incomplet] : un message d’erreur s’affiche à l’écran avisant l’utilisateur que les infos du client sont incomplets et qu’il reste la date de naissance



Post conditions : conditions : Validation de la fiche client.

Figure 5:Diagramme 5:Diagramme d’activité d’activité du cas « gérer des infos client »

Projet de Fin d’Année

2012-2013

Page 29

Cas d'utilisation " Gérer la commande " 

Titre : Titre : Gérer la commande



Résumé : le client effectue la commande auprès d’une des agences, après avoir vérifié les informations du client auprès du service de facturation, le client rempli le bon de commande





Acteurs : Agence, Service de facturation Pré conditions : les responsables d’agence et service de facturation doivent s’authentifier 



Scénario nominal : Ce cas d’utilisation commence lorsque le client vient passer une commande auprès d’une agence.



E nch aînement (a) : passer la commande



E nch aînement (b) : établir le bon de commande Enchaînements alternatifs :



E nch aînement (c) : Vérifier les informations du client Si les informations informations du client sont fausses : [Exception1 : ErreurInfos]

Ex ceptions ceptions : 

[Exception1 : ErreurInfos] : un message d’erreur s’affiche à l’écran avisant l’utilisateur que les informations sont incorrectes.



Post conditions : conditions : Etablissement du bon de commande.

Projet de Fin d’Année

2012-2013

Page 30

Figure 6:diagrame d'activité du cas « gérer la commande »

Cas d'utilisation " Gérer la livraison " 

Titre : Titre : Gérer la livraison



Résumé : l’agence vérifie l’état du stock et vérifie les infos client auprès du service de facturation pour savoir l’état de la remise et après elle établit le bon de livraison





Acteurs : Agence, Service de facturation Pré conditions : les responsables d’agence et service de facturation doivent s’authentifier 



Scénario nominal : Ce cas d’utilisation commence lorsque le bon de commande est établi.



E nch aînement (a) : vérifier le stock Si la quantité du produit est indisponible : [Exception1 :  [Exception1 : QtéIndispo]



E nch aînement (b) : Vérifier l’état de la remise



E nch aînement (c) : établie le bon de livraison Ex ceptions ceptions :

Projet de Fin d’Année

2012-2013

Page 31



[Exception1 : ErreurInfos] : un message d’erreur s’affiche à l’écran avisant l’utilisateur que la quantité demandée est indisponible actuellement.



Post conditions : conditions : Etablissement du bon de livraison.

Figure 7:Diagramme 7:Diagramme d’activité du du cas « gérer la livraison»

Cas d'utilisation " Gérer la facturation " 

Titre : Titre : Gérer la facturation



Résumé  Résumé  : le service de facturation établit une facture à chaque bon de livraison reçu ensuite l’envoi au comptable pour l’écrire au journal de ventes





Acteurs : Comptabilité, Service de facturation Pré conditions : les responsables de la comptabilité et le service de facturation doivent s’authentifier 

Projet de Fin d’Année

2012-2013

Page 32



Scénario nominal : Ce cas d’utilisation commence lorsque le bon de livraison est arrivé au service de facturation.



E nch aînement (a) : établir la facture



E nch aînement (b) : écriture dans le journal de ventes



Post conditions : conditions : Mettre à jour le journal de ventes.

Figure 8:Diagramme 8:Diagramme d’activité du du cas « gérer la facturation»

Cas d'utilisation " Mettre à jour le catalogue " 

Titre : Titre : Mettre  Mettre à jour le catalogue



Résumé  Résumé  : La direction met à jour le catalogue (Ajout de nouveaux produits et/ou modification des prix unitaires des produits existants) après avoir reçu les propositions de nouveaux produits en provenance du fournisseur



Acteurs : direction, fournisseur



Pré conditions : le responsable de la direction doit s’authentifier 



Scénario nominal : Ce cas d’utilisation commence lorsque les propositions du fournisseur sont arrivées à la direction.



E nch aînement (a) : Mettre à jour le catalogue Enchaînements alternatifs :

Projet de Fin d’Année

2012-2013

Page 33



E nch aînement (b) : Ajouter des nouveaux produits Si le produit existe : [Exception1 : [Exception1 : ProduitExistant]



E nch aînement (c) : Modifier les prix unitaires Si le produit n’existe pas : pas  : [Exception2  [Exception2 : ProduitInexistant]

Ex ceptions ceptions : 

[Exception1 : ProduitExistant]: un message d’erreur s’affiche à l’écran avisant l’utilisateur que le produit existe déjà.



[Exception2 : ProduitInexistant]: un message d’erreur s’affiche à l’écran avisant l’utilisateur que le produit n’existe pas



Post conditions : conditions : la mise à jour du catalogue validée

Figure 9:Diagramme 9:Diagramme d’activité du du cas «mettre à jour le catalogue» catalogue»

3-Structuration des cas d’utilisations dans des packages Cette phase va permettre de structurer les cas d’utilisations d’utilisations en groupes fortement cohérents, ceci afin de préparer le terrain pour la prochaine phase qui est le « découpage en catégories ».

Définition : un package représente un espace de nommage qui peut contenir : 

Projet de Fin d’Année

Des éléments d’un modèle.

2012-2013

Page 34



Des diagrammes qui représentent les éléments du modèle.



D’autres packages.

La structuration des cas d’utilisations se fait par domaine d’expertise métier c.à.d. les éléments contenus dans un package doivent représenter un ensemble fortement cohérent et sont généralement de même nature et de même niveau sémantique.

Cas d’utilisation

Consulter le catalogue

Acteurs Client,

fournisseur,

Packages  agence,

service de facturation, direction Modifier le catalogue

La direction de la

Gestion du catalogue

société

AGRI Gérer le stock 

Agence

Gérer les informations informations des clients

Service de facturation

Gérer les commandes du client

Agence, Service de facturation

Gérer la livraison des produits

Agence, Service de facturation

Gérer la facturation

Service de facturation

Mettre à jour le journal de ventes

Comptabilité

Projet de Fin d’Année

2012-2013

Gestion du stock

Gestion client

Gestion de la livraison

Page 35

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 métier des utilisateurs, ni de la description applicative. Cette étape nécessite une connaissance des prérequis techniques. Le modèle s'y exprime suivant les deux points de vue qui sont la spécification logicielle et la structure du matériel à exploiter.

1-Spécification technique du point de vue matériel Les choix techniques sont de nature géographique, organisationnelle, et technique. Elles concernent les performances d'accès aux données, la sécurité du système, l'interopérabilité, la volumétrie et le mode d'utilisation du système. Ils impliquent des contraintes relatives à la configuration du réseau matériel

2-Configuration matériel du système Dans cette partie on va présenter l'utilisation de l'infrastructure physique par le système et la manière dont les composants du système sont répartis ainsi que leurs relations r elations entre eux. Pour cela on va utiliser un diagramme de déploiement :

 Agen ces

 Appl icati on

Comptabilité

Internet  Appl icati on

LAN

Serveur 

LAN direction

service de facturation

 Appl icati on

 Appl icati on  Appl icati on

Base de données

LAN

Figure 10:diagramme de déploiement

Projet de Fin d’Année

2012-2013

Page 36

 Nous avons un serveur principal qui se trouve dans le siège où est installée la base de données. Les trois agences ont besoin de l’internet pour pouvoir accéder au serveur contrairement à la direction, le service de facturation et la comptabilité qui sont centralisés au siège

IV-Analyse 1-Développement du modèle statique Le développement du modèle statique constitue une étape importante de la phase de conception. Ce modèle rassemble les différentes classes et associations du système. Cette  partie va nous permettre d’illustrer d’illustrer les principales constructions du diagramme de classes UML durant l’étape d’analyse. Le diagramme de classes a toujours été le diagramme le plus important dans toutes les méthodes orientées objet. C’est également celui qui contient la plus grande gamme de notation et de variantes. Les diagrammes de classes expriment de manière générale la structure statique d’un système, en terme de classes et de relations entre ces classes. De même qu’une classe décrit un ensemble d’objets, une association décrit 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 société AGRI

Projet de Fin d’Année

2012-2013

Page 37

2-Développement du modèle dynamique Cette partie va nous permettre d’illustrer l’utilisation des concepts dynamiques d’UML et des diagrammes associés en phase d’analyse en décrivant des scénarios mettant en jeu un ensemble d’objets échangeant des messages. Ces interactions seront seront décrites au moyen de diagrammes de séquence qui met l’accent sur la chronologie des messages. Il faut signaler que tous les scénarios possibles ne peuvent être énumérés et décrits du fait qu’ils en existent beaucoup. C’est pour cette raison que nous allons faire une description des scénarios les plus pertinents.

a) Scénario d’authentification : d’authentification :

Figure 12:Diagramme de séquence du scénario « Authentification »

Projet de Fin d’Année

2012-2013

Page 38

 b) Scénario d’ajout/Modification d’un profil d’utilisateur  :  :

Figure 13:Diagramme 13:Diagramme de séquence du scénario « Ajout/Modification d’un profil »

c) Scénario d’alimentation du stock  :  :

Figure 14:Diagramme de séquence du scénario « Alimentation du stock »

Projet de Fin d’Année

2012-2013

Page 39

d) Scénario de passer une commande :

Figure 15:Diagramme de séquence du scénario passer une commande

e) Scénario de l‘établissement de la facture:

Figure 16:Diagramme de séquence du scénario Etablir la facture

Projet de Fin d’Année

2012-2013

Page 40

f) Scénario de création du bon de livraison:

Figure 17:Diagramme de de séquence du scénario scénario création du bon de livraison

g) Scénario d’ajout d’ajout d’une fiche client:

Figure 18:Diagramme 18:Diagramme de séquence du scénario Création d’une fiche client

Projet de Fin d’Année

2012-2013

Page 41

h) Scénario de modification des informations sur le client:

Figure 19:Diagramme de séquence du scénario Modification de la fiche client

i) Scénario de modification du catalogue:

Figure 20:Diagramme de séquence du scénario Modifier catalogue

Construction des diagrammes d’états : On recourt au concept de machine à états finis, qui consiste à s’intéresser au cycle de vie d’un objet générique d’une classe particulière au fil de ses interactions avec les autres classes, dans tous les cas possibles. Cette vue locale d’un objet, décrivant comment il réagit à des événements en fonction de son état courant et passe dans un nouvel état, est représentée graphiquement sous forme d’un diagramme d’états.

Projet de Fin d’Année

2012-2013

Page 42

Définition : un : un état état représente une situation durant la vie d’un objet pendant laquelle : Il satisfait une certaine condition, il exécute une certaine activité, Ou bien il attend un certain évènement. Un objet passe par une succession successio n d’états durant son existence. Un état a une durée finie, variable selon la vie de l’objet, en particulier en fonction des événements événeme nts qui lui arrivent.

a) Diagramme d’états d’états de la classe Personne :

Figure 21:Diagramme 21:Diagramme d’états-transitions d’états-transitions de la classe Personne

 b) Diagramme d’états d’états de la classe Catalogue :

Figure 22:Diagramme 22:Diagramme d’états-transitions d’états-transitions de la classe Catalogue

Projet de Fin d’Année

2012-2013

Page 43

c) Diagramme d’états de la classe Commande : Commande :

Figure 23:Diagramme 23:Diagramme d’états-transitions d’états-transitions de la classe Commande

d) Diagramme d’états de la classe Facture : Facture :

Figure 24:Diagramme 24:Diagramme d’états transitions de la classe Facture

e) Diagramme d’états de la classe Client : Client :

Figure 25:Diagramme 25:Diagramme d’états-transitions d’états-transitions de la classe Client

Projet de Fin d’Année

2012-2013

Page 44

Chapitre 2 Réalisation Le choix du langage s’est porté vers Java, qui étant Orienté Objet à la base, nous facilitera la transformation de notre modèle 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  préférable d'utiliser un environnement de développement intégré ou IDE. Notre choix s’est  porté vers l’EDI NetBeans, qui nous fournit le confort et la simplicité nécessaires à un développement propre et rapide.

1-Outils de développement : 1-1 NetBeans  NetBeans est un environnement de développement intégré (EDI), placé en Open Source par Sun. En plus de Java, NetBeans permet également de supporter différents autres langages, comme C, C++,

JavaScript, PHP,

HTML … Il comprend toutes les le s

caractéristiques d'un IDE moderne moderne (éditeur en couleur, projets projets multi-langage, refactoring, éditeur graphique d'interfaces et de pages Web). Conçu en Java, NetBeans est disponible sous Windows, Linux, Solaris, Mac OS X ou sous une version indépendante des systèmes d'exploitation (requérant une machine virtuelle Java). Un environnement Java Development Kit (JDK) est requis pour les développements en Java. L'IDE Netbeans s'enrichit à l'aide de plugins.

Projet de Fin d’Année

2012-2013

Page 45

Figure 26:IDE Netbeans 6.9.1

1-2PowerAMC PowerAMC est un logiciel de conception créé par la société SDP, qui permet de modéliser les traitements informatiques et leurs bases de données associées. PowerAMC permet de réaliser tous les types de modèles informatiques. Il reste un des seuls qui permet de travailler avec la méthode Merise. Selon Riff News, cela permet d'améliorer la modélisation, les processus, le coût et la production d'applications.

Figure 27:PowerAMC

Projet de Fin d’Année

2012-2013

Page 46

1-3Langage de programmation : JAVA C'est un langage de programmation orienté objet, développé par Sun Microsystems. Il  permet de créer des logiciels des logiciels compatibles avec de nombreux systèmes d’exploitation (Windows, Linux, (Windows, Linux,   Macintosh, Solaris). Java donne aussi la possibilité de développer des  programmes pour téléphones portables et assistants personnels. Enfin, ce langage peut être utilisé sur internet pour internet pour des petites applications petites applications intégrées à la page web (applet) ou encore comme langage serveur langage serveur (jsp).

2-Présentation 2-Présentation de l’application réalisée : réalisée  : Structure générale de l’application : L’application est découpée 2 en couches distinctes, Présentation et Métier. La couche « Présentation » est chargée de tout ce qui e st affichage. La couche « Métier » est la logique métier de l’application, elle est le coeur et c’est elle qui définit toutes les règles régissantes au fonctionnement de l’application. l’ application. a) Le stockage de données : La technique choisie pour persister les données est : la sérialisation. Une technique plus aboutie aurait été un meilleur choix comme : le mapping Objet/Relationnel avec un outil comme Hibernate. Cependant, l’apprentissage l’apprentissage de cet outil demande un temps supplémentaire. Mais la solution de la sérialisation réponds largement à nos besoins pour ce projet, c’est pour ça que nous avons jugé pertinent de la garder.  b) La couche Métier  : Voici quelques figures représentants un échantillon du code source de cette couche :

Projet de Fin d’Année

2012-2013

Page 47

Figure 28:Classe 28:Classe Log qui permet de coder l’authentification de l’utilisateur

Figure 29:Classe 29:Classe Saisie produit qui permet l’insertion d’un d’un nouveau produit dans le catalogue

Projet de Fin d’Année

2012-2013

Page 48

Figure 30: Classe LireEtEcrire qui permet la Sérialisation (La sauvegarde et le chargement) des données

c) La couche Présentation : Présentation :

Voici quelques figures représentants l’interface du logiciel :

Figure 31:Fenêtre 31:Fenêtre d’accueil

Projet de Fin d’Année

2012-2013

Page 49

Figure 32:Fenêtre 32:Fenêtre d’identification

Figure 33: Menu administrateur

Projet de Fin d’Année

2012-2013

Page 50

Figure 34:Fenêtre de saisie de nouveaux produits

Figure 35: Fenêtre d’ajout de nouveau client

Projet de Fin d’Année

2012-2013

Page 51

Figure 36: Fenêtre de saison de la commande

Figure 37:Fenêtre des Listes des clients

Projet de Fin d’Année

2012-2013

Page 52

Figure 38: Fenêtre du catalogue

3-Conclusion :  Nous pouvons constater que l’ajout de nouvelles fonctionnalités peut être simplifié, pour  peu qu’on respecte bien les étapes définies par 2TUP. Ça demande de faire une itération complète ou partielle selon le besoin, du cycle Y, et ne pas succomber à la tentation de toucher rapidement au code.

Projet de Fin d’Année

2012-2013

Page 53

Conclusion générale

 Nous avons tenté à travers ce projet de démontrer l’importance de l’application d’une méthode de développement. Nous pensons aussi que 2TUP pourra être utilisée dans des  projets de moyenne à grande envergure. A titre personnel, le bénéfice qu’on en a tiré est l’apprentissage 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à. concepts-là. Ce projet nous a permis d’enrichir nos connaissances dans des domaines très variés comme : L’Orienté Objet, UML, 2TUP, le langage JAVA, Swing… En termes d’évolution, l’application pourra par la suite être adaptée à une utilisation Plus vaste  par intégration d’une base de données qui pourra pourra être utilisée soit par le biais d’un pont JDBC, ou par le biais d’une solution de Mapping Objet/ Relationnel comme c omme Hibernate. Aussi, un déploiement sur un réseau pourra être fait grâce au framework J2EE. Nous espérons que la lecture de ce rapport a été agréable et claire.

Projet de Fin d’Année

2012-2013

Page 54

Bibliographie Cours de UML vue cette année en deuxième année à l’ENSIAS Cours sur le processus 2tup fait cette année par Mr Kriouille Meyer, B. (2000). Conception et Programmation orientées objet. Eyrolles. Pitman, N. (2006). UML 2 en concentré. O'Reilly.

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

Projet de Fin d’Année

2012-2013

Page 55