Mise en place d'une application mobile web et de drivers à Goma au sein d'un établissement commercial. Cas de l'établissement YETU.

III.2. Généralités sur la Méthode UP

UML n'est qu'un langage de modélisation. Nous n'avons pas aujourd'hui dans la norme, de démarche unifiée pour construire les modèles et conduire un projet mettant en oeuvre UML. Cependant les auteurs d'UML, ont décrit, dans un ouvrage [Jacobson2000a] le processus unifié

(UP, Unified Process) qui doit être associé à UML. Nous n'allons pas, dans le cadre de cet ouvrage, donner une présentation détaillée d'UP. Cependant il nous a paru intéressant de dégager les idées fondatrices d'UP dans le cadre d'une présentation générale. Nous allons tout d'abord expliciter les principes de la méthode UP.

Nous compléterons ensuite cette présentation générale en décrivant l'architecture à deux dimensions d'UP et ses principaux concepts, nous passerons aussi en revue les différentes phases d'UP, et pour finir nous détaillerons les activités d'UP³⁸.

Les principes d'UP

35 Cadet BUCE NTANYANYA, Opcit.

36 Ibidem

37 Arsène BUINGO, Question Spéciale de la Programmation Avancée(QSPA), Cours Inédit, L1 CSI, ISC/Goma, 2016-2017

³⁸ Cadet NTANYANYA, Opcit

35

Le processus de développement UP, associé à UML, met en oeuvre les principes suivants :

- Processus guidé par les cas d'utilisation,

- Processus itératif et incrémental,

- Processus centré sur l'architecture,

- Processus orienté par la réduction des risques.

Ces principes sont à la base du processus unifié décrit par les auteurs d'UML.

III.3. Modélisation Proprement dite

En mettant en application les principes du langage UML en utilisant la méthode UP, nous allons subdiviser notre modélisation en trois parties dont l'analyse, la conception et l'implémentation.

III.3.1. Analyse

L'analyse permet une formalisation du système à développer en réponse à l'expression des besoins formulée par les utilisateurs. L'analyse se concrétise par l'élaboration de cinq diagrammes suivants : le diagramme de cas d'utilisation, le diagramme de séquence et le diagramme d'activités.

III.3.1.1. Elaboration du Diagramme de Cas d'Utilisation

Le diagramme de cas d'utilisation décrit les fonctions du système selon le point de vue de l'utilisateur futur.

Le diagramme de cas d'utilisation il permet de recueillir, d'analyser et d'organiser les besoins³⁹.

Un cas d'utilisation correspond à une manière spécifique d'utiliser le système. C'est la représentation d'une fonctionnalité, déclenchée en réponse à une stimulation du système.⁴⁰

Acteur : est une entité externe qui agit sur le système. Un acteur possède un rôle par rapport au système. Ne pas confondre acteur et un utilisateur du système.

Une même personne peut jouer plusieurs rôles et plusieurs personnes peuvent jouer un même rôle. Un acteur n'est pas forcément une personne physique.⁴¹

³⁹ Cadet BUCE NTANYANYA, Opcit , P.88

⁴⁰ Idem

⁴¹ Ibidem

36

Nous distinguons en général deux catégories d'acteurs :

Les acteurs principaux : les acteurs qui utilisent les fonctions principales du système (client, fournisseur).

Les acteurs secondaires : les acteurs qui effectuent les tâches de maintenance, administration et paramétrage du système (manager de la BD). Ces deux catégories d'acteurs forment trois groupes dont : Les êtres humains : Client, Etudiant, Gérant, Comptable, ...

Le matériel externe : Les périphériques informatiques (capteurs, imprimantes) ; Les systèmes informatiques avec lequel le système interagit (autres applications informatiques).

V' Un cas d'utilisation correspond à un certain nombre d'actions que le système devra exécuter en réponse à un besoin d'un acteur.

Un cas d'utilisation doit produire un résultat observable pour un ou plusieurs acteurs ou parties prenantes du système.

V' Une interaction permet de décrire les échanges entre un acteur et un cas d'utilisation.

V' Relation d'utilisation « uses » : une relation d'utilisation entre cas d'utilisation signifie qu'une instance du cas d'utilisation source comprend également le comportement décrit par le cas d'utilisation destination.

V' Relation d'extension « Etend » : Une relation d'extension entre cas d'utilisation signifie que le cas d'utilisation source étant le comportement du cas d'utilisation destination.

V' Relation de généralisation : Une relation de généralisation de cas d'utilisation peut être définie conformément au principe de la spécialisation-généralisation comme pour les classes

37

Tableau 4 : Fiche descriptive de cas d'utilisation « S'authentifier »

Scénario 1 « S'authentifier »
Objectif		: Décrire le processus d'authentification pour accéder aux fonctionnalités du site.
Acteurs concernés		: client, utilisateur
Pré conditions		: le client ou utilisateur doit être connecté au site et avoir un compte
Scénario nominal		: 1. Saisie le mot de passe et le mail/nom d'utilisateur 2. le client ou utilisateur valide l'authentification 3. le système vérification le mot de passe et le mail/nom d'utilisateur (existence du compte). 4. le système ouvre la session. 5. le client/utilisateur accède à son compte
Scénarios alternatifs		· (A1) : Si un champ de saisis est vide, alors le système indique qu'un champ est incomplet et demande de ressaisir.

38

· (A2) : Si l'Email(username) et/ou le mot de passe est incorrect, le système affiche un message d'erreur.

· Le cas d'utilisation reprend à l'action 2 du scénario nominal.

Tableau 5 : Fiche descriptive de cas d'utilisation « Supprimer un produit »

Scénario 2 « Supprimer un produit »
Objectif		: L'utilisateur a la possibilité de supprimer un produit.
Acteurs concernés		: Utilisateur (Agent)
Pré conditions		: L'utilisateur doit S'authentifier
Scénario nominal		1. l'utilisateur s'authentifie. 2. l'utilisateur demande la suppression du produit 3. Le système demande une confirmation. 4. l'utilisateur valide la suppression du produit. 5. Le système supprime le produit et affiche le message de confirmation
Scénarios alternatifs		: Erreur de non existence : Le système affiche message d'erreur. Le cas d'utilisation reprend à l'action 2 du scénario nominal.