III.2. Modélisation du système
III.2.1. Présentation de la méthode UP et
du langage UML
Le Processus Unifié (PU ou UP en anglais pour
Unified Process) est une méthode de développement pour les
logiciels orientés objets. Elle est une méthode
générique, itérative et incrémentale. Cette
méthode nous sert à compléter la systémique des
modèles ou diagrammes UML.
Le langage de modélisation unifié (UML en
anglais pour Unified Modeling process) est un langage de
modélisation graphique à bases des pictogrammes conçu pour
fournir une méthode normalisée pour visualiser la conception d'un
système.
Ce langage nous offre un standard de modélisation,
lequel nous permet de spécifier, visualiser, modifier, construire et
représenter l'architecture logicielle en mettant en évidence des
éléments représentables tels que les acteurs, les
processus, le schéma de bases de données, les composants
logiciels, etc.
III.2.2. Identification des profils
utilisateurs
Le système décisionnel dont nous concevons sera
géré en amont par les administrateurs et manipulé en aval
par les autres utilisateurs ou les analystes. Évidemment qu'il ne
concerne pas tous les utilisateurs de l'entreprise, il est plutôt
dédié aux managers,
38
aux analystes de l'entreprise, les personnes ayant
l'habileté de prendre les décisions dans la
société.
Un acteur est l'idéalisation d'un rôle
joué par une personne externe, un processus ou un objet qui interagit
avec un système. Las acteurs sont donc à l'extérieur du
système et dialoguent avec lui. Le tableau suivant nous montre la liste
des acteurs qui utiliseront le système.
Tableau 5: Tableau des acteurs
|
Acteur
|
Rôle
|
|
1
|
Administrateur
|
Cet acteur a le rôle de collecter les données
externes afin de les charger dans l'entrepôt de données.
|
|
2
|
Analyste
|
Cet acteur est chargé de se connecter à
l'entrepôt et faire des
analyses des données sur les données
intégrées par
l'administrateur.
|
III.2.3. Diagramme de cas d'utilisation
Dans la plupart de cas, la maitrise d'ouvrage et les
utilisateurs des systèmes dans des entreprises ne sont forcément
pas informaticiens. Il leur faut donc un moyen pour exprimer leurs besoins.
C'est précisément le rôle des diagrammes de cas
d'utilisation qui permettent de recueillir, d'analyser et d'organiser les
besoins, et de recenser les grandes fonctionnalités du
système.
Un diagramme de cas d'utilisation (CU) capture le comportement
d'un système, d'un sous-système, d'une classe ou d'un composant
tel qu'un utilisateur extérieur le voit [6]. Il scinde la
fonctionnalité du système en unités cohérentes, les
cas d'utilisation, ayant un sens pour les acteurs.
La représentation d'un cas d'utilisation met en jeu
trois concepts : l'acteur, le cas d'utilisation et l'interaction entre l'acteur
et le cas d'utilisation.
Nous représentons dans ce travail les diagrammes de
séquences qui semblent importants et qui nous exhibent des
fonctionnalités pertinentes de notre système.
39
III.2.4. Cas d'utilisation
Un cas d'utilisation est une entité
cohérente d'une fonctionnalité visible de l'extérieur. Il
réalise un service de bout en bout, avec un déclenchement, un
déroulement et une fin. Un CU modélise donc un service rendu par
le système, sans importer le mode de réalisation de ce
service.
Il représente un ensemble de séquences d'actions
qui sont réalisées par le système et qui produisent un
résultat observable intéressant pour un acteur.
Le diagramme de CU de notre système est
représenté ci-dessous :
Figure 6 : Diagramme de cas d'utilisation du système
décisionnel
III.2.5. Diagrammes de séquences
Les diagrammes de séquences ont comme objectif de
représenter les interactions entre objets et les messages que ces objets
échangent lors de leur interaction.
40
III.2.5.1. DSS DU CU « S'authentifier
»
Figure 7:DSS DU CU « S'authentifier »
III.2.5.2. Description textuelle du CU «
S'authentifier »
+ Nom : S'authentifier
+ Résumé : L'utilisateur doit pouvoir introduire
ses coordonnées
d'authentification pour être identifié dans le
système.
+ Acteurs impliqués : Utilisateur
+ Date de création : 23 Juin 2018
+ Date de mise à jour : 28 Août 2018
+ Nom du responsable : Cédric Massamba
+ Numéro de version : 1.0
+ Pré-conditions : L'utilisateur doit
préalablement exister dans le système.
:
+ Scénario nominal
1. Le système affiche le formulaire d'authentification
;
Figure 8 : DSS DU CU « Alimenter l'entrepôt
»
41
2. L'utilisateur introduit son nom d'utilisateur, le mot de
passe et valide ;
3. Accès au système et ouverture de la session.
? Scénario alternatif :
2.a. Si les coordonnées d'authentification sont
incorrectes, le système bloque le processus et ramène
l'utilisateur à l'étape 2.
? Post condition : Ouverture de la session.
III.2.5.3. DSS DU CU « Alimenter l'entrepôt
»
42
III.2.5.4. Description textuelle du CU «
Alimenter l'entrepôt »
+ Nom : Alimenter entrepôt
+ Résumé : L'administrateur sélectionne
les données externes et les
intègre dans le data warehouse.
+ Acteurs impliqués : Administrateur
+ Date de création : 23 Juin 2018
+ Date de mise à jour : 29 Août 2018
+ Nom du responsable : Cédric Massamba
+ Numéro de version : 1.0
+ Pré-conditions : Les sources externes doivent
être disponibles.
:
+ Scénario nominal
1. L'administrateur importe les sources externes vers la zone de
préparation de données ;
2. Le système extrait, transforme et charge les
données dans le data warehouse ;
3. L'administrateur charge les données dans
l'entrepôt.
+ Scénario alternatif :
2.a. Si les données externes sont incohérentes
ou incompatibles avec la table de destination, le système bloque le
processus et ramène l'administrateur à l'étape 1.
+ Post condition : Intégration des données dans le
data warehouse réussie.
43
III.2.4.4. DSS DU CU « Gérer comptes
utilisateurs »
Figure 9: DSS DU CU "Gérer comptes
utilisateurs"
44
III.2.5.5. Description textuelle du CU «
Gérer comptes utilisateurs »
+ Nom : Gérer comptes utilisateurs
+ Résumé : L'administrateur gère les comptes
des utilisateurs et/ou analystes du
système. Il peut ajouter un nouveau compte, le modifier ou
le supprimer.
+ Acteurs primaire : Administrateur
+ Acteur secondaire : Analyste
+ Date de création : 24 Juin 2018
+ Date de mise à jour : 30 Août 2018
+ Nom du responsable : Cédric Massamba
+ Numéro de version : 1.0
+ Pré-conditions : S'authentifier, être
administrateur et avoir des comptes utilisateurs
disponibles dans le
système.
+ Scénario nominal :
1. L'administrateur demande l'ouverture du formulaire de
gestion des comptes utilisateurs ;
2. Le système lui demande de s'authentifier ;
3. L'administrateur saisit ses coordonnées
d'authentification ;
4. Le système affiche la page de gestion de comptes
des utilisateurs
5. L'administrateur choisit une opération à
effectuer (Ajouter, Modifier ou supprimer un compte utilisateur) ;
6. Le système affiche la page d'ajout, de modification
ou de suppression de compte utilisateur ;
7. L'administrateur remplit les coordonnées, valide et
envoie le formulaire au système ;
8. Le système met à jour les coordonnées
de l'utilisateur;
+ Scénario alternatif :
3.a. Les informations d'authentification erronées : le
système bloque le processus et retour à l'étape 2 du
scénario nominal.
7.b. Formulaire mal rempli : le système affiche le message
d'erreur et retourne à l'étape 6.
+ Post condition : Intégration des données dans le
data warehouse
réussie.
45
III.2.5.6. DSS DU CU « Analyser les données
»
Figure 10: DSS DU CU « Analyser les données
»
III.2.5.7. Description textuelle du CU « Analyser
les données »
+ Nom : Analyser les données
+ Résumé : L'analyste fait des analyses et
l'exploration des données du DWH.
+ Acteurs primaire : Analyste
+ Acteur secondaire : ---
+ Date de création : 24 Juin 2018
+ Date de mise à jour : 01 Septembre 2018 + Nom du
responsable : Cédric Massamba + Numéro de version : 1.1
+ Pré-conditions : S'authentifier, accéder à
l'entrepôt.
+ Scénario nominal :
1. Le système affiche à l'analyste le formulaire
d'authentification ;
2. L'analyste insère des coordonnées pour
s'authentifier au système ;
3. Le système ouvre la session ;
4. L'analyste accède au data warehouse ;
5. Le système affiche la structure complète du
modèle de BD ;
46
6. L'analyste construit le modèle dimensionnel logique
comprenant les mesures et les dimensions, axes d'analyse.
+ Scénario alternatif :
2.a. Les informations d'authentification insérées
non valides : le système
bloque le processus et retour à l'étape 1 du
scénario nominal.
5.b. Absence de connexion à la source de données
(Dwh) : le système affiche le message d'erreur et retourne à
l'étape 4.
+ Post condition : Modèle dimensionnel construit.
III.2.5.8. DSS DU CU « Visualiser les cubes des
données »
Figure 11 : DSS DU CU « Visualiser les cubes des
données »
III.2.5.9. Description textuelle du CU « Visualiser
les cubes des données »
+ Nom : Visualiser les cubes des données
+ Résumé : L'analyste se connecte à
l'entrepôt pour faire des analyses les
données intégrées.
+ Acteurs primaire : Analyste + Acteur secondaire : ---
47
+ Date de création : 24 Juin 2018
+ Date de mise à jour : 01 Septembre 2018 + Nom du
responsable : Cédric Massamba + Numéro de version : 1.1
+ Pré-conditions : Accéder à
l'entrepôt, modèle dimensionnel disponible.
+ Scénario nominal :
1. Le système affiche la page de création des
cubes OLAP;
2. L'analyste construit le cube sur base des dimensions, faits
et mesures ;
3. Le système valide et affiche le cube;
4. L'analyste conçoit le rapport et/ou le tableau de bord
;
5. L'analyste affiche et publie le résultat.
+ Scénario alternatif :
4.a. Si le cube n'est pas construit le système bloque le
processus et ramène l'utilisateur à l'étape 1.
+ Post condition : Production du rapport.
III.2.6. Diagramme de classes de
participantes
III.2.6.1. DCP du CU « S'authentifier
»
Figure 12:DCP du CU « S'authentifier »
48
III.2.6.2. DCP du CU « alimenter entrepôt
»
Figure 13: DCP du CU « alimenter entrepôt
»
III.2.6.3. DCP du CU « Gérer comptes
utilisateurs »
Figure 14: DCP du CU « Gérer comptes utilisateurs
»
49
III.2.6.4. DCP du CU « Analyser les données
»
Figure 15: DCP du CU « Analyser les données
»
50
III.2.6.5. DCP du CU « Visualiser les cubes des
données »
Figure 16: DCP du CU « Visualiser les cubes des
données »
51
III.2.7. Diagramme de classes de conception
Figure 17 : Diagramme de classes de conception
III.2.8. Modèle logique des
données
Figure 18: Modèle logique des données
52
| 
