CHAPITRE I : METHODE UP7 ET LES APPLICATIONS WEB
Ce chapitre sera subdivisé en deux sections, nous
parlerons dans notre première section des
généralités sur la méthode UP7 (Unified Process ou
Processus Unifié) ainsi que son usage en mettant un accent particulier
sur le langage de modélisation UML (Unified Modeling Language ou Langage
de Modélisation Unifié) et dans la deuxième section
nous parlerons des généralités sur le web.
1.1.
Méthode UP7
1.1.1. Présentation de la
méthode UP7
La méthode UP7 (Unifie Process 7) est une
démarche d'application d'UML qui prend appui sur UP (Unified Process)
mais qui se veut avant tout être pragmatique. Cette démarche est
fondée d'une part sur notre vision du processus de développement
et d'autre part sur notre propre expérience tirée de la
réalisation en entreprise de projets avec UML.
Cette démarche s'articule suivant deux axes : les
quatre phases qui correspondent à celles d'UP (lancement,
élaboration, construction et transition) et sept activités ou
étapes ayant chacun un pourcentage de temps qu'elle occupe
(Modélisation métier, Exigence fonctionnelle, Analyse des cas
d'utilisation, Synthèse d'analyse, Conception, Implémentation et
Test). Ainsi, nous pouvons présenter dès ce stade un premier
schéma d'ensemble de la démarche suivant ces deux axes.
PHASES
Transition
Construction
Élaboration
Lancement
ACTIVITÉS
3
Analyse
-
des cas d'utilisation
2
Exigences
-
fonctionnelles
Modélisation métier
1-
Test
7-
6
-
Implémentation
5
Conception
-
4
Synthèse
-
de l'analyse
Figure 1. 1 Schéma d'ensemble de la
démarche UP7 (source Gabay-Uml_2_Analyse_Et_Conception)
Les zones grises dans les différentes phases sur le
schéma représentent les proportions de l'effort à
consentir pour chaque activité durant les phases d'un projet. Voici donc
les différentes phases et leurs proportions évaluées en
pourcentage.
a) Modélisation métier : elle consiste
à mieux connaître et comprendre les processus dans lesquels va
s'intégrer le futur système informatique. Cette activité
aboutit à trois résultats :
· Au positionnement du système à
étudier au sein de l'ensemble des processus de l'entreprise et à
la définition du périmètre fonctionnel global du
système (diagramme de contexte du domaine d'étude).
· À la définition des processus
métiers concernés par le système à
développer et à l'identification des acteurs (diagramme
d'activité).
· À la définition des concepts
métiers du domaine sous forme de classe (diagramme de classe
métier). Les concepts métiers correspondent aux informations
créées, transformées ou manipulées par les experts
du domaine. L'expert du domaine y retrouve le vocabulaire de son
métier.
À l'issue de cette activité, le
périmètre du système à étudier est
défini. Cette étape ne correspond qu'à 5% de
proportion.
b) Les exigences fonctionnelles : elle consiste à
définir ce que doit faire le système d'un point de vue
métier. Cette activité permet d'obtenir trois résultats
:
· La définition des cas d'utilisation
métier et leur description générale (diagramme de cas
d'utilisation système).
· Les scénarios des cas d'utilisation
métier (diagramme de séquence système).
· La navigation générale du système
à étudier, c'est-à-dire l'interface homme-machine
(schéma de navigation générale).
Au terme de ces deux premières activités,
l'expression des besoins (au sens UP) est couverte. Cette étape ne
correspond qu'à 5% de proportion.
c) Analyse des cas d'utilisation : elle consiste à
fournir une vue informatique du système. Cette activité permet
d'obtenir cinq résultats :
· La définition de tous les cas d'utilisation
(métiers + informatiques) et leur description détaillée
(diagramme des cas d'utilisation).
· L'identification des scénarios pour chaque cas
d'utilisation (diagramme de séquence).
· Les différents états des objets
étudiés (diagramme d'état-transition). Cette partie de
l'activité est optionnelle et s'applique selon les systèmes
étudiés.
· Les interfaces utilisateur pour chaque cas
d'utilisation.
· Les classes pour chaque cas d'utilisation (diagramme de
classe).
À l'issue de cette activité, l'analyse des cas
d'utilisation est produite mais non encore consolidée ni validée
définitivement. Cette activité ne représente que 20% de
proportion.
d) La synthèse d'analyse : elle consiste à
consolider et valider toute l'analyse des cas d'utilisation. Cette
activité permet d'obtenir deux résultats :
· Le regroupement de l'ensemble des classes en un seul
diagramme (diagramme de classe récapitulatif).
· La validation de l'analyse de chaque cas par le biais
d'une matrice de validation. Celle-ci permet de vérifier que l'analyse
des cas est complète, c'est-à-dire que tous les cas d'utilisation
métier ont été repris dans l'analyse.
Au terme des activités 3 et 4, l'analyse (au sens
activité UP) est couverte. Elle ne couvre que 5% de la proportion.
e) La conception : elle se concentre sur le «
comment faire ». Elle a pour but de définir et de mettre en place
les choix d'architecture technique, et de compléter la description du
système sous l'angle technique. Cette activité permet d'obtenir
quatre résultats :
· Les choix techniques retenus.
· Les scénarios techniques par cas d'utilisation
(diagrammes de séquence technique).
· Les classes techniques par cas d'utilisation
(diagrammes de classe technique).
· Le regroupement sous forme de paquetage de l'ensemble
des classes techniques en un seul diagramme (diagramme de paquetage).
Cette activité couvre la conception (au sens UP) et
représente 10%.
f) L'implémentation : elle se concentre sur
l'utilisation des technologies de programmation. Quand on parle de
l'implémentation il s'agit donc de mettre en oeuvre les modèles
issus de l'analyse et de la conception. Cette activité nous permet donc
d'obtenir un produit logiciel sous forme des composants de bibliothèque
ou des fichiers(DJUNGU S.-J. , Genie logiciel, 2017). Cette étape comme
dans toutes les autres méthodes reste la plus lourde par rapport
à toutes les autres et représente 40% de proportion.
g) Les tests : ne représente quant à elle
que 15%. Elle consiste à vérifier la bonne implémentation
de toutes les exigences, le fonctionnement correct des interactions entre les
objets.
Le schéma ci-dessous nous présente les
différentes étapes qui caractérisent le cycle de
développement logiciel qu'exige la démarche UP7 d'une
manière simplifiée.
| 
