VI.1.2. Conception du
système de vente de crédit
1. Présentation de la méthode de
développement
La méthode RAD
RAD est une méthode de développement rapide
d'applications basée sur le prototypage et le développement
incrémental sans planification spécifique impliquée. Elle
repose sur un certain nombre de principes tels que:
· le développement doit s'effectuer en faisant
appel à une méthodologie formalisée ;
· l'équipe de développement RAD doit
disposer d'outils puissants qui automatisent le développement dans sa
globalité ;
· l'équipe de développement doit être
correctement gérée, par un encadrement encourageant la
réutilisation des composants ;
· les utilisateurs finaux doivent s'impliquer dans le
processus de développement.
La méthode RAD structure le cycle de vie du projet en
cinq (5) phases:
Ø Initialisation : l'objectif est
d'informer les intervenants des contraintes du projet RAD. En effet, dans cette
phase, on détermine le périmètre général et
le plan de communication du projet. De même, le travail est
structuré par thèmes et les acteurs pertinents du projet sont
identifiés ;
Ø Cadrage : qui couvre l'analyse des
besoins, la définition du périmètre et la planification de
l'itération ;
Ø Design : encore appelée la
phase de conception et de modélisation. Lors de cette phase, une
modélisation de la solution est faite et un premier niveau de
prototypage présentant l'ergonomie et la cinématique
générale de l'application est validé ;
Ø Construction : dans cette
étape, l'équipe doit construire l'application module par module
dans un délai limité avec la participation
régulière des utilisateurs. Elle fusionne les étapes de
codage, de tests unitaires et de tests d'intégration ;
Ø Finalisation: il s'agit, dans cette
phase, d'officialiser une livraison globale et de transférer le
système en exploitation et maintenance après avoir
réalisé toutes les recettes et élaboré la
documentation ;
2. Présentation des outils
Les outils utilisés pour le développement du
produit sont classés suivant leur utilité au niveau du projet.
Ainsi on distingue:
· Le langage de modélisation
v Présentation d'UML
UML, c'est l'acronyme anglais pour « Unified Modeling
Language » traduit par « langage de modélisation unifié
».
C'est un langage visuel constitué d'un ensemble de
schémas, appelés des diagrammes, qui donnent chacun une vision
différente du projet à traiter.
UML est né de la fusion des trois méthodes qui
ont influencé la modélisation objet au milieu des années
90: OMT, Booch et OOSE. Il s'agit d'un compromis qui a été
trouvé par une équipe d'experts: Grady Booch, James Rumbaugh et
Ivar Jacobson. UML est à présent un standard défini par
l'OMG.
v Les diagrammes UML
Depuis sa normalisation en 1997 par l'OMG, UML en est
aujourd'hui à sa version 2.5.
Cette version comporte quatorze (14) diagrammes classés
en trois (3) grandes catégories : les diagrammes structurels (diagramme
de classes, diagramme d'objets, diagramme de packages, diagramme de composants,
diagramme de structure composite, diagramme de déploiement et diagramme
de profils), les diagrammes d'interaction (diagramme de séquence,
diagramme de collaboration, diagramme d'interaction et diagramme de temps) et
les diagrammes comportementaux (diagramme de cas d'utilisation, diagramme
d'activités et diagramme d'état-transition).
v Le diagramme de cas d'utilisation
Il permet de représenter les fonctionnalités
d'un système ou sous-système. Il se compose d'acteurs, de cas
d'utilisation et de relations qui les associent.
Un acteur est celui qui bénéficie de
l'utilisation du système. C'est une entité qui joue un rôle
dans le système. Dans le formalisme UML, un acteur est
représenté symboliquement par un « bonhomme » («
stick man » en anglais) et est identifié par son nom ou est
formalisé par une classe stéréotypée «
actor »
Un cas d'utilisation est une manière spécifique
d'utiliser un système. Il réalise un service de bout en bout,
avec un déclenchement, un déroulement et une fin pour l'acteur
qui l'initie. Il est représenté dans UML par une ellipse.
Plusieurs types de relation peuvent exister entre les cas
d'utilisation :
· Une relation d'inclusion matérialisée par
le stéréotype « include » (« inclure »)
permet d'indiquer qu'un cas d'utilisation fait appel à un autre cas
d'utilisation ;
· Une relation d'extension matérialisée par
le stéréotype « extends » (« étendre
») permet d'indiquer qu'un cas d'utilisation étend le comportement
d'un autre cas d'utilisation.
v Le diagramme de classes
Ce diagramme permet de donner la représentation
statique du système à développer. Cette
représentation est centrée sur les concepts de classe et
d'association. Une classe est une abstraction des entités du monde
réel possédant une structure commune, un comportement commun, des
relations identiques et une sémantique identique. Les liens entre les
entités du monde réel se traduisent par des associations entre
classes. Dans UML, une classe
est représentée par un rectangle découpé en trois
(3) parties contenant respectivement le nom de la classe, la liste des
attributs, et la liste des opérations (comportement).
v Le diagramme de séquence
Le diagramme de séquence permet de décrire
l'ordre des interactions entre les objets qui composent le système : il
représente la dynamique du système. Les objets sont des
entités appartenant au système, des instances de classe. Dans
UML, à chaque objet est associée une ligne de vie qui montre ses
actions et réactions, ainsi que les périodes pendant lesquelles
il est actif.
v Les outils de modélisation : Visual Paradigme
C'est un logiciel de modélisation qui permet la
création des diagrammes UML et des modèles qui en sont à
l'origine. Ceux-ci peuvent alors générer du code dans un langage
de programmation déterminé. Il propose également la
création d'autres types de diagrammes, comme celui qui permet la
modélisation des bases de données pouvant, lui aussi,
générer des canevas d'applications basé sur des Framework
et Pattern mais en plus, générer du code SQL qu'il peut ensuite
déployer automatiquement dans différents environnements.
3. Analyse des besoins
· Les paquets du système
Pour permettre un couplage faible entre les composants de
notre système, on a commencé par découper le
système en packages. Chaque package contiendra une partie des
fonctionnalités du système. Nous aurons le package appel, le
package message et le package demande de crédit:
1. Diagramme de package du système
Nous aurons ainsi quatre sous-systèmes: la gestion des
revendeurs, la gestion des appels, la gestion des messages et la gestion des
demandes de crédit.
o Sous-système « gestion des revendeurs »
Nous allons dans cette section illustrer, à l'aide de
diagramme de cas d'utilisation UML, les fonctionnalités du sous module
« gestion des revendeurs ». Le diagramme ci-dessous montre ses
différentes fonctionnalités:
2. Diagramme des fonctionnalités dans « gestion
des revendeurs »
Pour une bonne compréhension, nous allons illustrer le
diagramme à l'aide de diagramme de séquence d'UML pour la
réalisation du cas d'utilisation « supprimer revendeur ».
o Sous-système « gestion des appels »
Nous allons dans cette section illustrer, à l'aide de
diagramme de cas d'utilisation UML, les fonctionnalités du sous module
« gestion des appels ». Le diagramme ci-dessous montre ses
différentes fonctionnalités :
3. Diagramme des fonctionnalités dans «
gestion des appels »
Pour une bonne compréhension, nous allons illustrer le
diagramme à l'aide de diagramme de séquence d'UML pour la
réalisation des cas d'utilisation « supprimer appel » et
« lister appel ».
4. Diagramme de séquence du cas d'utilisation «
supprimer appel »
o Sous-système « gestion des messages »
Nous présentons ici à l'aide de diagramme de cas
d'utilisation, les fonctionnalités du sous-module « gestion des
messages » et ensuite détailler un cas pour expliquer les
échanges entre les objets du système pour réaliser une
fonctionnalité. Le diagramme ci-dessous montre le diagramme de cas
d'utilisation dans ce module.
5. Diagramme gestion des demandes de credit
o Sous-système « gestion des demandes de
crédit »
Nous présentons dans cette section le diagramme de cas
d'utilisation, les fonctionnalités du sous-module « gestion des
demandes de crédit » et ensuite détailler un cas pour
expliquer les échanges entre les objets du système pour
réaliser une fonctionnalité. Le diagramme ci-dessous
montre le diagramme de cas d'utilisation dans ce module.
7. Diagramme de cas d'utilisation « gestion des
demandes de crédit »
8. Diagramme de séquence du cas d'utilisation
«solder »
4. Présentation du diagramme de classe du
système de vente de crédit
Nous présenterons ici le de classe du système.
Dans ce diagramme, les fonctionnalités sont représentées
dans chaque classe. Le diagramme ci-dessous décrit les
fonctionnalités du système et les différentes interactions
du système.
9. Diagramme: Diagramme de classe du système
| 
