Rapport Pfa Processus 2tuppdf

Ecole Nationale Supérieure d’Informatique
et d’Analyse 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 : Encadré par :

Othmane MAHBOUB M. Abdelaziz KRIOUILE
Amine MAJDOUL
Année Universitaire : 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 à 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 oublier dans nos remerciements tout le cadre professoral de l’ENSIAS,
pour la formation consistante qu’il nous a prodiguée.
Que tous ceux qui nous ont 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 à 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.
Le mémoire sera découpé en 5 grands chapitres :
1. Introduction : nous parlerons dans ce chapitre des objectifs que nous

voudrions atteindre, ainsi qu’un aperçu des différentes méthodes
existantes.
2. La méthode 2TUP : ce chapitre contient les définitions des différents

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,

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

Liste des figures
Figure 1:Le système d’information soumis à deux types de contraintes..................................15
Figure 2:Le processus de développement en Y........................................................................16
Figure 3:Diagramme des cas d’utilisations...............................................................................26
Figure 4: diagramme d’activité du cas « s’authentifier ».........................................................28
Figure 5:Diagramme d’activité du cas « gérer des infos client »............................................29
Figure 6:diagrame 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é du cas « gérer la facturation».................................................33
Figure 9:Diagramme d’activité du cas «mettre à jour le 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 « 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 ».............................39
Figure 15:Diagramme de séquence du scénario passer une commande...................................40
Figure 16:Diagramme de séquence du scé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............................41
Figure 19:Diagramme de séquence du scénario Modification de la fiche client......................42
Figure 20:Diagramme de séquence du scénario Modifier catalogue........................................42
Figure 21:Diagramme d’états-transitions de la classe Personne...............................................43
Figure 22:Diagramme d’états-transitions de la classe Catalogue.............................................43
Figure 23:Diagramme d’états-transitions de la classe Commande...........................................44
Figure 24:Diagramme d’états transitions de la classe Facture..................................................44
Figure 25:Diagramme d’états-transitions de la classe Client....................................................44
Figure 26:IDE Netbeans 6.9.1...................................................................................................46
Figure 27:PowerAMC...............................................................................................................46
Figure 28:Classe Log qui permet de coder 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

Figure 32:Fenêtre d’identification.............................................................................................50
Figure 33: Menu administrateur................................................................................................50
Figure 34:Fenêtre de saisie 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

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
Chapitre 1.................................................................................................................................18
Analyse et Conception.............................................................................................................18
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 les cas d’utilisations........................................................................................23
1-1 Utilisation d’outils de génération de diagrammes UML..............................................23
1-2 Identification des cas d’utilisations..............................................................................24

2- Description détaillée des cas d’utilisations........................................................................26
Cas d'utilisation " Authentification (identification utilisateurs) ".....................................27
Cas d'utilisation " Gérer les profils: "................................................................................28
Cas d'utilisation " Gérer les infos clients "........................................................................28
Cas d'utilisation " Gérer la commande "...........................................................................30
Cas d'utilisation " Gérer la livraison "...............................................................................31
Cas d'utilisation " Gérer la facturation "...........................................................................32
Cas d'utilisation " Mettre à jour le catalogue "..................................................................33
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
Réalisation................................................................................................................................45
1- Outils de développement....................................................................................................45
1-1 NetBeans.....................................................................................................................45
1-2PowerAMC..................................................................................................................46
1-3Langage de programmation : JAVA............................................................................47
2- Présentation de l’application réalisée.................................................................................47
3- Conclusion.........................................................................................................................53
Conclusion générale...................................................................................................................54

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 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 aujourd’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 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 celui-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.
Projet de Fin 2012- Page

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

La société AGRI possède quelques milliers de clients qu’il est difficile de gérer en continu.
Alors la tâche de 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 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 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éveloppement 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 méthode 2TUP, du fait de son approche nouvelle, originale.
Notre projet est basé sur un processus de développement bien 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 dans ce document.

2.1 Définition d’un processus de 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 pré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 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 peut 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
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 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.

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

Figure 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 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.
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.
La conception préliminaire.
La conception détaillée.
Le codage.
L’intégration.

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 le suivi des décisions prises, depuis
la définition des besoins jusqu’au codage. (Roques, 2006)

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

dans le système. Il peut être assimilé comme un algorithme mais schématisé.
Le diagramme de 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 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 : 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.

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
de capture des besoins fonctionnels et de capture techniques.
1- Présentation du projet à réaliser

C’est un logiciel qui doit gérer les activités de la société AGRI, et ceci concernant la
ventes de ses produits à ces clients, ainsi que la gestion de son catalogue et du stock de
chacune de ces agences.
2- Recueil des besoins fonctionnels

Pour pouvoir établir l’ensemble des besoins fonctionnels de notre logiciel, nous nous
sommes basés sur le texte figurant sur le polycopier 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).

 Le catalogue mis à jour est envoyé par la suite aux agences de
ventes, 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 des agences.
 L’agence renvoie cette demande auprès du service de facturation
qui va s’occuper de mettre à jour la fiche 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 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.

o Adoption d’une architecture à 3 couches.
o Utilisation du langage Java.
o Omission d’une base de données au profit de la sérialisation (Java).
o Utilisation de l’EDI NetBeans et de son plugin 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 :

 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
nouveaux produits à la société à l’aide de son propre catalogue.
 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 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 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 : Crée les profils utilisateurs et attribue les droits d’accès.

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.
Le système émet les messages suivants :
 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é.
 La facture des produits livrés aux clients.
Le système reçoit les messages suivants :

 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 permettre au client de :
 S’authentifier

 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 :
 Proposer de nouveaux produits.
 Consulter le catalogue
Vendeur d’une agence L’application doit permettre au vendeur d’une agence de :
 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é.
 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 :
 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 :

 Consulter la fiche client
 Mettre à jour le catalogue.
Administrateur L’application doit permettre à l’administrateur de

l’application de :
 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, et ainsi éviter de trop s’éloigner des besoins réels de
l’utilisateur final.
1- Déterminer les cas 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 exprime les interactions
acteurs/système et apporte une valeur ajoutée « notable » à l’acteur concerné.
1-1 Utilisation 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.
Bouml : sûrement l’outil le plus léger sur le marché, il est très puissant et agréable à
utiliser, et en plus il est gratuit.

1-2 Identification 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 ceux-là, et l’avancement dans
le « recueil des besoins fonctionnels ». 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 Messages émis/Reçus

secondaires par les acteurs
Consulter le catalogue Client, fournisseur, agence,

service de facturation,
direction
Modifier le catalogue La direction de la société Emet : La direction

AGRI met à jour le catalogue
(Ajout de nouveaux
produits et/ou
modification des prix
unitaires des produits
existants)
Reçoit : Les
propositions
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

la suppression d’un
autre du catalogue
Gérer les informations des clients Service de facturation Emet :

Création/Modification
de La fiche client
Reçoit : 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

Gérer la facturation Service de facturation Emet : établir la
facture des produits
livrés
Reçoit : Bon de
livraison
Mettre à jour le journal de ventes Comptabilité Emet : écrire la

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 des cas d’utilisations
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

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éversible.
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): plusieurs diagrammes vont apparaitre (mais pas

nécessairement) pour apporter une compréhension additive au cas d’utilisation.
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.
 Enchaînement (a) : L’utilisateur valide les données saisies.
Enchaînements alternatifs :
 Enchaînement (b) : Vérifications de l’existence de l’utilisateur par le système.
 Enchaînement (c) : Message de confirmation d’entrer à la session ou échec d’entrer.
 Post conditions : Ouverture de l’espace personnel.

Figure 4: diagramme d’activité du cas « s’authentifier »
Cas d'utilisation " Gérer les profils: "

 Titre : Gérer les profils:
 Acteurs : Administrateurs
 Pré conditions : Aucunes
 Scénario nominal : Ce cas d’utilisation commence lorsque l’administrateur lance le

logiciel.
 Enchaî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 : Validation du profil
Cas d'utilisation " Gérer les infos clients "

 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

 Scénario nominal : Ce cas d’utilisation commence lorsque la demande est établie
auprès du service de facturation.
 Enchaînement (a) : créer la fiche client
Si le client existe : [Exception1 : ClientExistant]
 Enchaînement (b) : valider la fiche client
Si le client de type « particulier » et sans date de naissance : [Exception2 : Incomplet]
 Enchaînement (c) : Modifier la fiche client
Exceptions :
 [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 : Validation de la fiche client.
Figure 5:Diagramme d’activité du cas « gérer des infos client »

Cas d'utilisation " Gérer la commande "
 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

s’authentifier
 Scénario nominal : Ce cas d’utilisation commence lorsque le client vient passer une
commande auprès d’une agence.
 Enchaînement (a) : passer la commande
 Enchaînement (b) : établir le bon de commande
 Enchaînement (c) : Vérifier les informations du client
Si les informations du client sont fausses : [Exception1 : ErreurInfos]
Exceptions :
 [Exception1 : ErreurInfos] : un message d’erreur s’affiche à l’écran avisant

l’utilisateur que les informations sont incorrectes.
 Post conditions : Etablissement du bon de commande.

Figure 6:diagrame d'activité du cas « gérer la commande »
Cas d'utilisation " Gérer la livraison "

 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

s’authentifier
 Scénario nominal : Ce cas d’utilisation commence lorsque le bon de commande est

établi.
 Enchaînement (a) : vérifier le stock
Si la quantité du produit est indisponible : [Exception1 : QtéIndispo]
 Enchaînement (b) : Vérifier l’état de la remise
 Enchaînement (c) : établie le bon de livraison
Exceptions :

 [Exception1 : ErreurInfos] : un message d’erreur s’affiche à l’écran avisant
l’utilisateur que la quantité demandée est indisponible actuellement.
 Post conditions : Etablissement du bon de livraison.
Figure 7:Diagramme d’activité du cas « gérer la livraison»
Cas d'utilisation " Gérer la facturation "

 Titre : Gérer la facturation
 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

 Scénario nominal : Ce cas d’utilisation commence lorsque le bon de livraison est
arrivé au service de facturation.
 Enchaînement (a) : établir la facture
 Enchaînement (b) : écriture dans le journal de ventes
 Post conditions : Mettre à jour le journal de ventes.
Figure 8:Diagramme d’activité du cas « gérer la facturation»
Cas d'utilisation " Mettre à jour le catalogue "

 Titre : Mettre à jour le catalogue
 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.
 Enchaînement (a) : Mettre à jour le catalogue

 Enchaînement (b) : Ajouter des nouveaux produits
Si le produit existe : [Exception1 : ProduitExistant]
 Enchaînement (c) : Modifier les prix unitaires
Si le produit n’existe pas : [Exception2 : ProduitInexistant]
Exceptions :
 [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 : la mise à jour du catalogue validée
Figure 9:Diagramme d’activité du cas «mettre à jour le catalogue»
3- Structuration des cas d’utilisations dans des packages

Cette phase va permettre de structurer les cas 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 :

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

 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 Acteurs Packages
Consulter le catalogue Client, fournisseur, agence,

service de facturation, direction
Gestion du catalogue
Modifier le catalogue La direction de la société
AGRI
Gérer le stock Agence Gestion du stock
Gérer les informations des clients Service de facturation
Gestion client
Gérer les commandes du client Agence, Service de facturation
Gérer la livraison des produits Agence, Service de facturation
Gestion de la livraison
Gérer la facturation Service de facturation
Mettre à jour le journal de ventes Comptabilité

III- Capture des besoins techniques
La capture des besoins techniques couvre avec celle des besoins fonctionnels, toutes les
contraintes qui ne traitent ni de la description du 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 entre
eux. Pour cela on va utiliser un diagramme de déploiement :
Agences
Application
Comptabilité
Internet
Application
LAN
Serveur
LAN service de facturation

Application
direction
Application Application
Base de données
LAN
Figure 10:diagramme de déploiement

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

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 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 :
Figure 12:Diagramme de séquence du scénario « Authentification »

b) Scénario d’ajout/Modification d’un profil d’utilisateur :
Figure 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 »

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

f) Scénario de création du bon de livraison:
Figure 17:Diagramme de séquence du scénario création du bon de livraison
g) Scénario d’ajout d’une fiche client:
Figure 18:Diagramme de séquence du scénario Création d’une fiche client

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.

Définition : un é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 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 qui
lui arrivent.
a) Diagramme d’états de la classe Personne :
Figure 21:Diagramme d’états-transitions de la classe Personne
b) Diagramme d’états de la classe Catalogue :
Figure 22:Diagramme d’états-transitions de la classe Catalogue

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

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

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

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
caractéristiques d'un IDE moderne (éditeur en couleur, 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.

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

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 compatibles avec de nombreux systèmes d’exploitation
(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 des petites applications intégrées à la page web (applet) ou encore
comme langage serveur (jsp).
2- Présentation de l’application 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 est 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.
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 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 :

Figure 28:Classe Log qui permet de coder l’authentification de l’utilisateur
Figure 29:Classe Saisie produit qui permet l’insertion d’un nouveau produit dans le catalogue

Figure 30: Classe LireEtEcrire qui permet la Sérialisation (La sauvegarde et le chargement) des
données
c) La couche Présentation :
Voici quelques figures représentants l’interface du logiciel :
Figure 31:Fenêtre d’accueil

Figure 32:Fenêtre d’identification
Figure 33: Menu administrateur

Figure 34:Fenêtre de saisie de nouveaux produits
Figure 35: Fenêtre d’ajout de nouveau client

Figure 36: Fenêtre de saison de la commande
Figure 37:Fenêtre des Listes des clients

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.

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à. 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 être utilisée soit par le biais d’un pont JDBC,
ou par le biais d’une solution de Mapping Objet/ Relationnel comme 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.

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/

Rapport Pfa Processus 2tuppdf

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport Pfa Processus 2tuppdf

Transféré par

Droits d'auteur :

Formats disponibles

Ecole Nationale Supérieure d’Informatique

et d’Analyse des Systèmes

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

Conception Orienté Objet et Réalisation du cas Agri

Réalisé par : Encadré par :

Année Universitaire : 2012-2013

Projet de Fin d’Année 2012-2013 Page 3

La gestion d’un cycle de vie de logiciel requit un grand sens de la rigueur et de

Le mémoire sera découpé en 5 grands chapitres :

1. Introduction : nous parlerons dans ce chapitre des objectifs que nous

2. La méthode 2TUP : ce chapitre contient les définitions des différents

3. Conception du logiciel : c’est ici que nous allons appliquer la

Projet de Fin d’Année 2012-2013 Page 4

Liste des abréviations

2TUP 2 Tracks Unified Process

Projet de Fin d’Année 2012-2013 Page 5

Projet de Fin d’Année 2012-2013 Page 6

Liste des tableaux

Projet de Fin d’Année 2012-2013 Page 7

Projet de Fin d’Année 2012-2013 Page 8

Projet de Fin d’Année 2012-2013 Page 9

Avec l’avènement de la pensée objet, de nouvelles méthodes sont apparues et différentes

Projet de Fin 2012- Page

Actuellement, les nouvelles technologies s’appuient sur le modèle objet.

En termes d’analyse et de modélisation objet, UML est devenu un standard incontournable,

1.3.2 Conduite de projet

1.4 Présentation de l’application à réaliser

Depuis l’apparition de l’informatique et son introduction dans le monde économique, les

Projet de Fin 2012- Page

Description de la méthode 2TUP

Comment vais-je organiser les équipes de développement ;

Quelles tâches attribuer à qui ;

Quel temps faudrait-il pour livrer le produit ;

Projet de Fin 2012- Page

2.2 Le processus unifié

Projet de Fin 2012- Page

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

Ces activités de développement sont définies par 6 disciplines fondamentales qui

2.3 Le processus 2TUP

C’est dans ce cadre que la société Valtech a créé la méthode 2TUP.

Projet de Fin 2012- Page

La branche gauche (fonctionnelle) : capitalise la connaissance du métier de l’entreprise.

Les fonctions du système d’information sont en effet indépendantes des technologies

Cette branche comporte les étapes suivantes :

La branche droite (architecture technique) : capitalise un savoir-faire technique. Elle

Cette branche comporte les étapes suivantes :

La capture des besoins techniques.

La branche du milieu : à l’issue des évolutions du modèle fonctionnel et de l’architecture

Cette branche comporte les étapes suivantes :

Projet de Fin 2012- Page

2.4 Un processus de modélisation avec UML

« Unified Modeling Language » : UML se définit comme un langage de modélisation

Projet de Fin 2012- Page

Le diagramme des cas d’utilisation : représente la structure des fonctionnalités

Le diagramme d’activités : représente les règles d’enchaînement des activités et actions

Le diagramme de packages : présent depuis UML 2.0, ce diagramme modélise des

En conception, le diagramme de classes représente la structure d’un code orienté objet.

Le diagramme de séquence : représente les échanges de messages entre objets, dans le

Ce diagramme est utilisé lors des étapes d’analyse et de conception.

Projet de Fin 2012- Page

1- Présentation du projet à réaliser

2- Recueil des besoins fonctionnels