Crédit Club Auto

Abbas Ahmad
Matin Bayramov
Année 2010/2011
Analyse et Modélisation des Systèmes Informatique (AMSI)
Projet de Modélisation UML
<< Crédit Club Auto >>
Professeur encadrant :
M. GUILLAUME PAQUETTE
Université de Franche-Comté (UFC)
Projet de modélisation UML << Crédit Club Auto >>
Page 2
Sommaire
Introduction
I.
Diagramme de cas d’utilisation du système
<< Crédit Club Auto >>.
II.
Diagramme de séquences spécifiant le scénario nominal
de création d’un crédit automobile pour client existant.
III.
Diagramme de classes de l’application << Crédit Club Auto >>.
Conclusion
Université de Franche-Comté (UFC)
Projet de modélisation UML << Crédit Club Auto >>
Page 3
Introduction
Le projet sur lequel nous avons travaillé ce premier semestre, est un projet de modélisation
UML.
UML (en anglais Unified Modeling Language ou « langage de modélisation unifié ») est
un langage de modélisation graphique à base de pictogrammes.
On trouve dans le langage UML plusieurs diagrammes, en ce qui nous concerne nous allons
voir uniquement 3 diagrammes :
1. Diagramme de cas d’utilisation
2. Diagramme de séquences
3. Diagramme de classes
Les diagrammes de cas d'utilisation sont des diagrammes UML utilisés pour donner une
vision globale du comportement fonctionnel d'un système logiciel. Un cas d'utilisation
représente une unité discrète d'interaction entre un utilisateur (humain ou machine) et un
système. Il est une unité significative de travail. Dans un diagramme de cas d'utilisation, les
utilisateurs sont appelés acteurs (actors), ils interagissent avec les cas d'utilisation (use
cases).
Les diagrammes de séquences sont la représentation graphique des interactions entre les
acteurs et le système selon un ordre chronologique.
Le diagramme de classes est un schéma utilisé en génie logiciel pour présenter les classes et
les interfaces des systèmes ainsi que les différentes relations entre celles-ci. Ce
diagramme fait partie de la partie statique d'UML car il fait abstraction des aspects
temporels et dynamiques.
En utilisant ces différents diagrammes UML, nous allons modéliser un logiciel informatique
<< Crédit Club Auto >> qui a pour objectif d’enrichir une gamme de produits destiné à un
réseau de concessionnaires automobiles.
Afin d’améliorer la lisibilité de nos diagrammes, nous les avons structuré en plusieurs
planches.
Université de Franche-Comté (UFC)
Projet de modélisation UML << Crédit Club Auto >>
Page 4
I.
Diagramme de cas d’utilisation
Notre première planche dans le diagramme de cas d’utilisation représente les actions du responsable
de crédit uniquement.
On associe au responsable de crédit le cas d’utilisation : Gestion Crédit.
A partir de la gestion du crédit, le gestionnaire crédit peut soit :
- Editer un contrat crédit automobile
- Créer un contrat crédit automobile
- Editer les conditions de crédit
- Editer les conditions de locations
Il a le pouvoir de faire ces actions a tout moment et indépendamment.
Cependant lors de la création d’un contrat crédit automobile il y a automatiquement édition du
contrat crédit automobile, ce qui justifie une inclusion de l’édition du contrat crédit automobile lors
de la création de celui-ci *(1).
Il existe aussi d’autres actions possible après la réalisation d’un de ces 4 cas d’utilisation que l’on
représenté par une flèche << extension>>. C'est-à-dire que l’on a la possibilité comme dans
l’exemple * (2) après une édition des conditions de crédit automobile de créer un contrat crédit
automobile.
Diagramme cas d'utilisation partie 1
* Voir numéro sur diagramme correspondant.
Université de Franche-Comté (UFC)
Projet de modélisation UML << Crédit Club Auto >>
Page 5
La seconde planche nous représente les cas d’utilisations des deux autres acteurs, le responsable
crédit et l’administrateur système.
Le responsable crédit comme décrit dans le sujet, n’a qu’un cas d’utilisation : mettre le contrat en
suspens. Et c’est le seul à pouvoir effectuer cette action.
Cependant l’administrateur système lui a plusieurs taches possibles, soit :
- Modifier les conditions du crédit,
- Modifier les taux de calcul de prêt,
- Faire divers modification (Non spécifier lesquels dans le sujet).
Diagramme cas d'utilisation partie 2
Université de Franche-Comté (UFC)
Projet de modélisation UML << Crédit Club Auto >>
Page 6
II.
Diagramme de séquences
Le diagramme de séquences suivant a été divisé en 2 planche Partie 1 et Partie 2
uniquement pour raison de lisibilité. Il est à noter que le diagramme de séquence partie 2
est une continuation du diagramme de séquence partie 1.
Notre diagramme de séquence se porte sur un scénario nominal de création d’un crédit
automobile pour client existant.
Trois acteurs interagissent lors de la création d’un crédit automobile. Deux de ces acteurs sont
humain : le client et le gestionnaire crédit. Le troisième acteur et un acteur machine : system Crédit
Club Auto.
Nous avons décidé de représenter le fait que le gestionnaire crédit demande au client de lui fournir
les informations en premier temps. Ce qui sous-entend que le client connaît au préalable les
informations à fournir ce qui est possible puisque le client est un client existant.
La saisie des informations fournies par le client est séparée en plusieurs blocs parallèles. C'est-à-dire
que comme dans *(3), lorsque le client donne une information le gestionnaire la saisie en même
temps sur le system Crédit Club Auto.
Apres la saisie de toutes les informations nécessaires a la création du contrat, le système vérifie si les
informations saisie sont valable pour obtenir un crédit : OK, ou non valable : KO.
Les vérifications nécessitent l’application de plusieurs règles : RG-CTRL-Catégorie, RG-CTRL-MontantPlancher,….
Cependant, nous avons décidé de ne pas représenter ces détails *(4) qui ne sont pas importants
dans la mesure où l’on cherche à voir l’interaction des différents acteurs entre eux. La vérification
des informations n’est autre qu’une suite de message du system vers le system lui-même ou il
effectue des calculs et des vérifications booléennes à l’aide de méthodes.
Suite à la vérification des informations le système transmet les résultats au gestionnaire.
* Voir numéro sur diagramme correspondant.
Université de Franche-Comté (UFC)
Projet de modélisation UML << Crédit Club Auto >>
Page 7
Diagramme séquences Partie 1
Il y alors 2 possibilités que l’on regroupe dans un bloc « alt » selon si le résultat de la vérification est
KO ou OK *(5).
Si KO le gestionnaire crédit refuse le crédit au client et annule la procédure sur le system.
Si OK le system affiche le coût total du crédit et le gestionnaire demande l’échéancier du crédit que le
système calcule puis affiche.
Ensuite le client donne son identifiant qui lui est demandé par le gestionnaire. Le gestionnaire saisie
dans le système soit le numéro de compte du client soit son nom et optionnellement son prénom
*(6) (Bloc « opt » pour l’option).
Apres recherche du client et affichage de la demande de création de crédit automobile par le
système, le gestionnaire demande une impression du contrat.
L’impression du contrat est demander qu’une seule foi mais le contrat est imprimer en 2
exemplaires.
* Voir numéro sur diagramme correspondant.
Université de Franche-Comté (UFC)
Projet de modélisation UML << Crédit Club Auto >>
Page 8
On modélise ceci par un boucle que le system effectuera sur « Impression du contrat » deux fois *(7).
Finalement après demande du gestionnaire d’enregistrer le contrat, le system effectue à la fois
l’enregistrement du contrat et l’affichage de la prise en compte de l’enregistrement.
Diagramme séquences Partie 2
* Voir numéro sur diagramme correspondant.
Université de Franche-Comté (UFC)
Projet de modélisation UML << Crédit Club Auto >>
Page 9
III.
Diagramme de classes
Les classes Personne et Client
Comme il est bien marqué dans le sujet du projet, soit un particulier est déjà un client du réseau,
soit il ne l’en est pas. Dans ce deuxième cas le system doit être capable de créer un nouveau client.
Un client se définit par son nom, prénom, adresse et bien entendu par un numéro de compte.
Pour un particulier (un particulier qui n’est pas encore un client est en effet un futur client du réseau)
aussi le system doit posséder au moins son nom et son prénom. D’où l’intérêt d’avoir une classe
nommée « Personne » qui est outils dans les diagrammes de classe d’UML. Cette classe possèdera
deux attributs ; nom et prénom.
Différemment à un particulier qui n’est pas encore un client du réseau, pour un client donné le
système possède déjà un numéro de compte et une adresse. Alors nous avons fait une classe
« Client » qui a deux attributs ; numéro de compte et l’adresse, une méthode rechercher() qui
permet de rechercher un client en fonction de son nom, prénom ou son numéro de compte. Et bien
entendu cette classe possède aussi les attributs de la classe Personne dont elle hérite. Une
Le lien entre ces deux classes sera bien sur « est une sorte de ». C’est-à-dire un client est une
sorte de personne.
Personne
nom_personne
prénom_personne
Client
numéro_compte
adresse_client
rechercher()
Il nous reste de gérer le cas d’un particulier n’appartenant pas au réseau. Nous avons créé une
méthode « créerClient ()» qui permettra au système de créer un nouveau client. Comme un
particulier est une personne, alors on lui associe une généralisation à la classe « Personne ».
Personne
nom_personne
prénom_personne
Particulier
créerClient()
La classe Véhicule
Véhicule
Nous avons créé une classe qui s’appelle « Véhicule ». Cette classe
possède trois attributs qui sont la marque, le type (le modèle), et la catégorie. marque_véhicule
Pour le montant d’un véhicule nous avons décidé de le présenter comme une type_véhicule
catégorie_véhicule
méthode. Car le montant peut varier en fonction des critères du système.
calcul_montant()
Université de Franche-Comté (UFC)
Projet de modélisation UML << Crédit Club Auto >>
Page 10
La classe Crédit
La classe crédit comporte quatre attributs : montant, plancher, plafond et durée. Elle
possède aussi les méthodes suivantes :
-
calculTaux() :
Cette méthode calcul le taux du crédit en fonction de la catégorie du véhicule, le montant de
véhicule et la durée du prêt qui sont tous des attributs récupérables dans le diagramme de classe.
-
calculMtEch() :
Crédit
La méthode permet de calculer le montant d’une échéance à l’aide des
montant
attributs : le montant emprunté, le taux périodique et le nombre d’échéance.
plancher
- calculNbEch() :
plafond
Cette méthode calcul le nombre d’échéance du crédit en fonction de la durée durée
calculTaux()
du crédit.
calculNbEch()
- calculCout() :
calculCout()
Cette méthode permet au système de calculer le cout total du crédit en afficherEcheancier()
caclulMtEch()
fonction du nombre d’échéance et du montant d’une échéance.
calculTxPer()
- afficherEcheancier() :
Cette méthode permet d’afficher l’échéancier de crédit automobile par date, montant, et montant
cumulé.
-
calculTxPer() :
Cette méthode permet de calculer le taux périodique en fonction du taux.
Contrat
La classe Contrat
numéro
dateSouscription
Un contrat a un numéro et une date de souscription. Il peut être annuler,
imprimer()
enregistrer et imprimer.
enregistrer()
annuler()
La classe CréationCrédit
Cette classe contient les attributs : date1erEcheance et tauxAppliqué d’un
CréationCrédit
crédit. Pour un client la classe crée un contrat pouvant impliquer plusieurs véhicules Date1erEcheance
avec les options définit dans la classe Crédit.
TauxAppliqué
Université de Franche-Comté (UFC)
Projet de modélisation UML << Crédit Club Auto >>
Page 11
Cependant, cette solution est préférable à présenter avec un losange qui relie les classes Client,
Contrat, Crédit et Véhicule avec une classe d’association CréationCrédit.
Nous n’avons pas pu présenter cette solution car RSA (Rational Software Architecte de IMB) ne nous
le permet pas.
Finalement le diagramme de classe du système est celui-ci.
Diagramme de classe du système 1
Université de Franche-Comté (UFC)
Projet de modélisation UML << Crédit Club Auto >>
Page 12
Conclusion
Nous avons trouvé plusieurs difficultés à modéliser certaines parties du projet Crédit Club Auto.
Après avoir travaillé de nombreuses semaines sur ce projet nous avons réussi à modélisée les
attentes de manière plus au moins cohérente.
Ce n’est cependant pas sans l’aide des connaissances acquise en cours, TD et TP.
Nous remercions pour cette occasion notre professeur encadrant M. GUILLAUME PAQUETTE et M.
FABIEN PEUREUX pour le soutien à la réalisation de ce projet.
Université de Franche-Comté (UFC)
Projet de modélisation UML << Crédit Club Auto >>
Page 13