Vous êtes sur la page 1sur 47

Chapitre2 : Analyse et

conception

2.1 Introduction :
Durant ce chapitre, on analysera les besoins formulés par l’organisme d’accueil et ce,
en se basant sur l’existant étudié dans le chapitre précédant et en identifiant les lacunes utilisé,
jusqu’aujourd’hui par OTA pour ce qui du répertoire de leurs composants et ce afin de faire
une conception de l’outil qui sera développé et qui viendra combler ces lacunes et de ce fait,
ce chapitre, comportera deux parties globales et qui sont :
- L’analyse des besoins d’OTA vis-à-vis de ce service
- La conception et la mise en place d’un croquis de l’outil demandé.

2.2 Présentation des méthodes utilisées :


2.2.1 Définition d’Unified Modeling Language (UML) [] :
UML (UNIFIED MODELING LANGUAGE) se définit comme un langage de modélisation
graphique et textuel destiné à comprendre et à définir les besoins, spécifier et documenter les
systèmes, esquisser les architectures logicielles, concevoir les solutions et communiquer les
points de vue. Ce langage véhicule en particulier :
- Le concept des approches par objets : classe, instance, classification, etc.
- Intégration des aspects d’association, fonctionnalités, évènements, état et séquences.
- Il définit 9 diagrammes de deux catégories différentes et qui sont :

- Diagrammes statiques (structurels) : diagramme de classe, diagramme d’objet,


diagramme de composant, diagramme de déploiement et diagramme de cas
d’utilisation.
- Diagrammes dynamiques (comportementaux) : diagramme d’activité,
diagramme de séquence, diagramme d’état-transition et diagramme de
collaboration.
Pour la modélisation des besoins, on utilisera les diagrammes UML suivants :
- Diagramme de cas d’utilisation
- Diagramme de cas d’utilisation détaillé
- Diagramme de séquence
- Diagramme d’activité
- Diagramme de classe
-

2.2.2 Définition de Rational Unified Process (RUP) [] :


Le processus utilisé pour la conception du nouveau système est le « RUP », Rational
Unified Process est un processus qui servira uniquement à canaliser et à ordonner la créativité
de la personne en charge de la modélisation d’une application.
Le RUP organise les diagrammes d’UML selon les étapes suivantes :
Chapitre2 : Analyse et
conception
Etape 01 : La collecte des besoins : C’est une étape primordiale au début de chaque
démarche de développement dont le but est de veiller à développer un logiciel adéquat, sa
finalité est la description générale des fonctionnalités du système, en répondant à la question :
Quelles sont les fonctions du système ?
Etape 02 : L’analyse : C’est une étape très important, elle vise à accéder à une
compréhension plus aigüe de raffinement des exigences.
Etape 03 : La conception : Cette étape est une description logique de la façon dont le
système va fonctionner. Elle consiste à façonner le système et lui donner une forme et une
architecture.
Etape 04 : Implémentation

2.3 Collecte des besoins :


2.3.1 Les besoins :
A travers l’étude et les interactions avec les individus au sein du service IT, on a
déterminé les besoins auxquels l’application doit répondre.
On a distingué deux types de besoins : les besoins fonctionnels et les besoins non
fonctionnels.
a) Les besoins fonctionnels :

- Permettre au responsable de bien répertorier ses différents composants tout en ayant


une vue détaillée sur chacun d’eux.
- Fournir un outil flexible qui puisse être opérationnel.
- Instaurer une hiérarchie en implémentant la notion des privilèges pour la bonne
gestion du contenu
b) Les besoins non fonctionnels
- Besoin de sécurité : L’utilisateur doit être identifié à travers un nom d’utilisateur et d’un
mot de passe
- Besoin d’ergonomie : Le système doit faciliter l’utilisation, en mettant à sa disposition
une interface claire, qui ne demande pas un grand effort intellectuel pour pourvoir l’exploiter
- Présentation de formulaires simples.

2.3.2 Diagramme de cas d’utilisation :


Un diagramme de cas d’utilisation est un graphe d’acteurs, un ensemble de cas
d’utilisation englobés par la limite du système, des associations de communication entre les
acteurs et les cas d’utilisation, et des généralisations entre cas d’utilisation. []
Il est destiné à représenter les besoins des utilisateurs par rapport au système.

a) Identification des acteurs :


Les acteurs d’un système sont les entités externes à ce système qui interagissent avec,
dans notre application, on distingue deux types d’acteurs : l’administrateur et l’utilisateur
lambda.
Chapitre2 : Analyse et
conception
1- L’utilisateur :
- Consultation des listes de composants avec le détail de chaque composant.
2- L’administrateur :
- Gestion des différents composants
- Gestion des utilisateurs
- Consultation et gestion de la liste des composants avec le détail de chaque
composant.
b) Identification des cas d’utilisations :
Un cas d’utilisation est utilisé pour définir le comportement d’un système où chaque
cas d’utilisation spécifie une séquence d’action [].
Cas d’utilisation Acteurs Spécifications du cas utilisation
Authentification Utilisateurs -Remplir le formulaire d’authentification
Administrateurs
-Consulter la liste des BDD avec le détail
de chaque instance
- Consulter la liste des applications avec le
Consulter les Utilisateurs détail de chaque instance
composants Administrateurs - Consulter la liste des liens avec le détail
de chaque instance
-Consulter la liste de tous les composants
Consulter les BDD’s Utilisateurs -Consulter la liste des BDD’s avec le détail
Administrateurs sur chacune d’elles.
Consulter les Utilisateurs -Consulter la liste des applications avec le
applications Administrateurs détail sur chacune d’elles.
Consulter les liens Utilisateurs -Consulter la liste des liens avec le détail
Administrateurs sur chacun d’eux.
Consulter les utilisateurs Utilisateurs -Consulter la liste des utilisateurs avec le
Administrateurs détail sur chacun d’eux.
Gestion des composants Administrateurs -Supprimer un composant
Gestion des BDD’s Administrateurs - Ajouter une BDD
-Modifier une BDD
-Supprimer une BDD
Gestion des applications Administrateurs -Ajouter une Application
-Modifier une Application
-Supprimer une Application
Gestion des liens Administrateurs -Ajouter un lien
-Modifier un lien
-Supprimer un lien
Gestion des utilisateurs Administrateurs -Ajouter un utilisateur
-Modifier un utilisateur
-Supprimer un utilisateur
Table 2.1 Identification des cas d'utilisations
Chapitre2 : Analyse et
conception

c) Cas d’utilisation générale 

Figure 2.3.1 : Diagramme de cas d’utilisation général


Chapitre2 : Analyse et
conception

d) Cas d’utilisation détaillés :


Voici les cas d’utilisation détaillés de notre application :
- Le diagramme de cas d’utilisation authentification

Figure 2.3.2 : Diagramme de cas d’utilisation authentification

Titre Cas d’utilisation authentification


Acteur Administrateur, Utilisateur
Description Ce cas d’utilisation vise à décrire les étapes relatives à l’authentification des
Textuel acteurs (Administrateur, utilisateur) afin d’effectuer les différentes opérations.
Pré Le système en état de fonctionnement
condition
Scénario 1. L’administrateur ou l’utilisateur ouvre l’application
nominal 2. Le système affiche le formulaire d’authentification
3. L’administrateur ou l’utilisateur saisit le pseudo et le mot de passe puis
clique sur « login »
4. Le système vérifie le nom d’utilisateur et le mot de passe
5. Le système ouvre une session à l’administrateur ou l’utilisateur et affiche
l’interface accessible
Scénario 1. Vérification du nom d’utilisateur et le mot de passe au niveau du serveur
Alternatif 2. Le système affiche un message d’erreur
Table 2.2 : Description du scénario d’authentification
Chapitre2 : Analyse et
conception

- Le diagramme de cas d’utilisation gestion des composants 

Figure 2.3.3 : diagramme de cas d’utilisation gestion des composants

- Cas d’utilisation « gestion des composants» 

Titre Cas d’utilisation gestion des composants


Acteur Administrateur
Description Sert à gérer les composants comme l’ajout, la modification et la suppression
Textuel d’un composant
Pré 1. Authentification
condition 2. L’administrateur a déjà choisi gérer les composants
Scénario 1. L’administrateur choisit gérer les composants
nominal 2. Le système affiche les options correspondantes (ajouter, modifier,
supprimer)
3. En cas d’ajout ou de modification, le système affiche le formulaire
correspondant
Table 2.3 : description du scénario cas d’utilisation « gestion des composants ».
Chapitre2 : Analyse et
conception

-  Cas d’utilisation « gestion des composants (ajouter un composant) »

Titre Cas d’utilisation ajouter un composant


Acteur Administrateur
Description Vise à décrire toutes les étapes relatives pour ajouter un composant qui n’existe
Textuel pas dans la liste
Pré 1. Authentification
condition 2. L’administrateur a déjà choisi gérer les composants.
Scénario 1. L’administrateur clique sur ajouter un composant
nominal 2. Le système affiche le formulaire d’ajout
3. L’utilisateur rempli les informations concernant le composant
4. L’administrateur clique sur ajouter.
5. Le système ajoute le composant et réaffiche la page de gestion des
composants.
Scénario Le système affiche un message d’erreur au cas où le composant existe déjà ou
Alternatif qu’un champ important manque.
L’utilisateur clique sur « annuler ».
Table 2.4 : Description textuel du scénario gestion des composants « ajouter un composant »

_ Remarque : Pour « l’ajout d’applications, liens, bases de données et utilisateur », la


description textuelle est équivalente au tableau ci-dessus
Chapitre2 : Analyse et
conception

- Le diagramme de cas d’utilisation gestion des applications 

Figure 2.3.4 : Diagramme de cas d’utilisation gestion des applications

Titre Cas d’utilisation gestion des applications


Acteur Administrateur
Description Sert à gérer les applications tell que l’ajout, la modification et la suppression
Textuel d’une application
Pré 1. Authentification
condition 2. L’administrateur a déjà choisi gérer les applications
Scénario 1. L’administrateur choisit gérer les applications
nominal 2. Le système affiche les options correspondantes (ajouter, modifier,
supprimer)
3. En cas d’ajout ou de modification, le système affiche le formulaire
correspondant
Table 2.5 : Description du scénario gestion des applications
Chapitre2 : Analyse et
conception

- Cas d’utilisation « gestion des applications (modifier une application) »

Titre Cas d’utilisation modifier une application


Acteur Administrateur
Description Vise à décrire toutes les étapes relatives pour supprimer une application
Textuel disponible dans la liste des applications
Pré 1. Authentification
condition 2. L’administrateur a déjà choisi gérer les applications
Scénario 1. L’administrateur clique sur modifier correspondant à l’application qu’il
nominal veut modifier
2. Le système affiche le formulaire de modification.
3. L’administrateur modifie les données et clique sur « Modifier ».
4. Le système affiche la page de gestion des applications
Scénario Le système affiche un message d’erreur si les données saisies sont incorrectes
Alternatif ou bien quand il laisse un champ important vide.
L’utilisateur clique sur « annuler ».
Table 2.6 : Description textuel du scénario modifier une application

_ Remarque : Pour « la modification des composants, liens, bases de données et utilisateur », la
description textuelle est équivalente au tableau ci-dessus
Chapitre2 : Analyse et
conception

- Le diagramme de cas d’utilisation gestion des BDD

Figure 2.3.5 : Diagramme de cas d’utilisation gestion des BDD

Titre Cas d’utilisation gestion des BDD


Acteur Administrateur
Description Sert à gérer les BDD tel que l’ajout, la modification et la suppression d’une base
Textuel de données
Pré 1. Authentification
condition 2. L’administrateur a déjà choisi gérer les BDD
Scénario 1. L’administrateur choisit gérer les BDD
nominal 2. Le système affiche les options correspondantes (ajouter, modifier,
supprimer)
3. En cas d’ajout ou de modification, le système affiche le formulaire
correspondant
Table 2.7 : Description textuel du scénario gestion des BDD
Chapitre2 : Analyse et
conception

- Cas d’utilisation « gestion des BDD (supprimer une BDD) »

Titre Cas d’utilisation supprimer une BDD


Acteur Administrateur
Description Vise à décrire toutes les étapes relatives pour supprimer une BDD disponible
Textuel dans la liste des bases de données
Pré 1. Authentification
condition 2. L’administrateur a déjà choisi gérer les BDD
Scénario 1. L’administrateur clique sur supprimer correspondant à la base de
nominal données qu’il veut supprimer
2. Le système affiche une boite de dialogue de confirmation.
3. L’administrateur choisit « OK»
4. Le système supprime la BDD sélectionnée et réaffiche la page de
gestion des Bases de données.
Scénario L’administrateur choisit « Annuler » et le système annule la suppression.
Alternatif
Table 2.8 : Description textuel du scénario supprimer une base de données

_ Remarque : Pour « la suppression des composants, applications, liens, et utilisateurs », la


description textuelle est équivalente au tableau ci-dessus

- Le diagramme de cas d’utilisation gestion des liens

Figure 2.3.6 : Diagramme de cas d’utilisation gestion des liens


Chapitre2 : Analyse et
conception

Titre Cas d’utilisation gestion des liens


Acteur Administrateur
Description Sert à gérer les liens tell que l’ajout, la modification et la suppression d’un lien
textuel
Pré 1. Authentification
condition 2. L’administrateur a déjà choisi gérer les liens
Scénario 1. L’administrateur choisit gérer les liens
nominal 2. Le système affiche les options correspondantes (ajouter, modifier,
supprimer)
3. En cas d’ajout ou de modification, le système affiche le formulaire
correspondant
Table 2.9 : Description textuel du scénario gestion des liens
Chapitre2 : Analyse et
conception

- Le diagramme de cas d’utilisation gestion des utilisateurs

Figure 2.3.7 : Diagramme de cas d’utilisation gestion des utilisateurs

Titre Cas d’utilisation gestion des utilisateurs


Acteur Administrateur
Description Sert à gérer les utilisateurs, comme l’ajout, la modification et la suppression
textuel d’un utilisateur
Pré 1. Authentification
condition 2. L’administrateur a déjà choisi gérer les utilisateurs.
Scénario 1. L’administrateur choisit gérer les utilisateurs
nominal 2. Le système affiche les utilisateurs
3. Le système affiche les options correspondantes (ajouter, modifier,
supprimer)
4. En cas d’ajout ou de modification, le système affiche le formulaire
correspondant
Table 2.10 : Description textuel du scénario gestion des utilisateurs
Chapitre2 : Analyse et
conception

- Le diagramme de cas d’utilisation consulter la liste des utilisateurs

Figure 2.3.8 : Diagramme de cas d’utilisation consulter les utilisateurs

Titre Cas d’utilisation consulter la liste des utilisateurs


Acteur Administrateur, Utilisateurs
Description Consulter la liste des utilisateurs
Textuel
Pré 1. Authentification
condition 2. L’administrateur/Utilisateur a déjà choisi consulter les utilisateurs
Scénario 1. L’acteur choisit « consulter les utilisateurs »
nominal 2. Le système affiche les utilisateurs avec le détail de chacun d’eux.
Table 2.11 : Description textuelle du scénario consulter la liste des utilisateurs
Chapitre2 : Analyse et
conception

- Le diagramme de cas d’utilisation consulter les composants

Figure 2.3.9 : Diagramme de cas d’utilisation consulter les composants

Titre Cas d’utilisation consulter les composants


Acteur Administrateur, Utilisateur
Description Consulter les composants disponibles
Textuel
Pré 1. Authentification
condition 2. L’acteur a déjà choisi consulter les composants
Scénario 1. L’acteur choisit « consulter les composants »
nominal 2. Le système affiche les composants disponibles.
Table 2.12 : Description textuelle du scénario consulter les composants
Chapitre2 : Analyse et
conception

- Le diagramme de cas d’utilisation consulter la liste des applications

Figure 2.3.10 : Diagramme de cas d’utilisation consulter la liste des applications

Titre Cas d’utilisation consulter la liste des applications


Acteur Administrateur, Utilisateur
Description Consulter la liste des applications disponibles et ainsi tous les détails concernant
Textuel ces dernières (le nom, catégorie…).
Pré 1. Authentification
condition 2. L’acteur a déjà choisi consulter les applications
Scénario 1. L’acteur choisit « consulter la liste des applications»
nominal 2. Le système affiche toutes les applications répertoriées
3. Le système affiche le détail concernant les applications.

Table 2.13 : Description textuelle du scénario consulter la liste des applications


Chapitre2 : Analyse et
conception

- Le diagramme de cas d’utilisation consulter la liste des BDD’s

Figure 2.3.11 : Diagramme de cas d’utilisation consulter la liste des BDD’s

Titre Cas d’utilisation consulter la liste des BDD’s


Acteur Administrateur, Utilisateurs
Description Consulter la liste des BDD’s disponible et ainsi tous les détails concernant ces
textuel dernières (localisation, le nom…).
Pré 1. Authentification
condition 2. L’acteur a déjà choisi consulter les BDD’s
Scénario 1. L’acteur choisit « 
nominal 2. la liste des BDD’s »
3. Le système affiche toutes les BDD’s répertoriées
4. Le système affiche le détail concernant les BDD’s.
Table 2.14 : Description textuelle du scénario consulter la liste des BDD’s
Chapitre2 : Analyse et
conception

- Le diagramme de cas d’utilisation consulter la liste des liens

Figure 2.3.12 : Diagramme de cas d’utilisation consulter la liste des liens

Titre Cas d’utilisation consulter les liens


Acteur Administrateur, Utilisateur
Description Consulter la liste des liens disponible et ainsi que tous détails concernant ces
textuel derniers (le nom, le type…).
Pré 1. Authentification
condition 2. L’acteur a déjà choisi consulter les liens
Scénario 1. L’acteur choisit « consulter la liste des liens».
nominal 2. Le système affiche tous les liens répertoriés.
3. Le système affiche le détail concernant les liens.
Table 2.15 : Description textuel du scénario consulter les liens

2.3.3 Diagramme de séquence :


Il permet de décrire les scénarios de chaque cas d’utilisation en mettant l’accent sur la
chronologie des opérations en interaction avec les objets. Un diagramme de séquence montre
une interaction présentée en séquence de temps.

En particulier, il montre aussi les objets qui participent à l’interaction par leur « ligne de vie »
et les messages qu’ils échangent présentés en séquence dans le temps. Voici quelques notions
essentielles [] :
Chapitre2 : Analyse et
conception
- Scénario : Représente une succession particulière d'enchaînements, s'exécutant du
début à la fin du cas d'utilisation, un enchaînement étant l'unité de description de
séquences d’actions.
- Ligne de vie : Représente l'ensemble des opérations exécutées par un objet.
- Message : Un message est une transmission d'information unidirectionnelle entre deux
Objets, l'objet émetteur et l'objet récepteur. Dans un diagramme de séquence, deux
Types de messages peuvent être distingués :

- Message synchrone : Dans ce cas l'émetteur reste en attente de la réponse à


son Message avant de poursuivre ses actions.
- Message asynchrone : Dans ce cas, l'émetteur n'attend pas la réponse à son
message, il poursuit l'exécution de ses opérations.

a) Diagramme de séquence du cas d’utilisation « Authentification » :

Figure 2.3.13 : Diagramme de séquence du cas d’utilisation « Authentification »


Chapitre2 : Analyse et
conception

b) Diagramme de séquence consultation des composants :


Chapitre2 : Analyse et
conception

Figure 2.3.14 : Diagramme de séquence du cas d’utilisation consultation des composants


Chapitre2 : Analyse et
conception

c) Diagramme de séquence Gestion des composants :

Figure 2.3.15 : Diagramme de séquence du cas d’utilisation « gestion des composants »

d) Diagramme de séquence Ajouter composant :


Chapitre2 : Analyse et
conception

F
igure 2.3.16 : Diagramme de séquence du cas d’utilisation « ajouter composant »

_ Remarque : Pour « l’ajout d’applications, liens, bases de données et utilisateur », le


diagramme de séquence est équivalent à la figure di dessus

e) Diagramme de séquence Gestion des utilisateurs


Chapitre2 : Analyse et
conception

Figure 2.3.17 : Diagramme de séquence du cas d’utilisation « Gestion des utilisateurs »

_ Remarque : Pour « gestion d’applications, liens et bases de données », le diagramme de


séquence est équivalent à la figure au-dessus
Chapitre2 : Analyse et
conception
f) Diagramme de séquence Modifier une application

Figure 2.3.18 : Diagramme de séquence des cas d’utilisations «Modifier une application »

_ Remarque : Pour « modifier un lien, base de données et utilisateur », le diagramme de


séquence est équivalent à la figure au-dessus
Chapitre2 : Analyse et
conception
g) Diagramme de séquence supprimer une BDD

Figure 2.3.19 : Diagramme de séquence des cas d’utilisation «supprimer une BDD »
Chapitre2 : Analyse et
conception
_ Remarque : Pour « supprimer une application, lien et utilisateur », le diagramme de séquence
est équivalent à la figure au-dessus
Chapitre2 : Analyse et
conception
h) Diagramme de séquence Gestion des liens :
Chapitre2 : Analyse et
conception
Figure 2.3.20 : Diagramme de séquence du cas d’utilisation « Gestion des liens »

i) Diagramme de séquence Ajouter un lien :

Figure 2.3.21 : Diagramme de séquence du cas d’utilisation « Ajouter un lien »


Chapitre2 : Analyse et
conception

j) Diagramme de séquence Modifier un lien

Figure 2.3.22 : Diagramme de séquence des cas d’utilisations « Modifier un lien »


Chapitre2 : Analyse et
conception
Chapitre2 : Analyse et
conception
k) Diagramme de séquence Supprimer un lien

Figure 2.3.23 : Diagramme de séquence des cas d’utilisations « Supprimer un lien »


Chapitre2 : Analyse et
conception

2.3.4 Diagramme d’activité :


Le diagramme d’activité est l’un des diagrammes dynamiques d’UML. Il permet de
représenter les flots de contrôle d’action en action.

Les éléments de base du diagramme d’activité sont les suivants : []

- Les actions 
- Les flots de contrôle : l’enchainement des actions
- Les décisions
- Un début et une ou plusieurs terminaison (s) possible (s).

a) Diagramme d’activité de l’authentification

Utilisateur Système

Démarrer Ouvrir
l’application l’application

Saisir le nom
d’utilisateur, mot de
passe et valider Afficher le formulaire
d’authentification

Vérifier les
données

Afficher un
message d’erreur

[Échec de connexion]

[Connexion réussie]

Afficher la page
d’accueil
Chapitre2 : Analyse et
conception

Figure 2.3.24 : Diagramme d’activité de l’authentification

b) Diagramme d’activité de l’ajout d’un utilisateur

Figure 2.3.25 : Diagramme d’activité de l’ajout d’un utilisateur


Chapitre2 : Analyse et
conception

c) Diagramme d’activité de suppression d’une application 

Figure 2.3.26 : Diagramme d’activité de suppression d’une application


Chapitre2 : Analyse et
conception

d) Diagramme d’activité de la modification d’une BDD

Figure 2.3.27 : Diagrammes d’activité de la modification d’une BDD


Chapitre2 : Analyse et
conception

2.3.5 Diagramme de classe :

Le diagramme de classes est considéré comme le plus important de la modélisation


orientée objet, car il représente la structure interne des classes d'un système ainsi que les
diverses relations qui les lient. []
Une class contient : []
- Nom : Le nom de la classe.
- Attributs : Décrivent la structure de ses instances.
- Méthodes : Décrivent les opérations qui sont applicables aux instances de la classe.

a) Le diagramme de classe :
Figure 2.3.28 : Diagramme de classe
Chapitre2 : Analyse et
conception

b) Description des classes :


Chapitre2 : Analyse et
conception

Les classes Les attributs Les méthodes


Composant (‘idcrud’,‘nom’) Ajouter ( ),
Modifier ( ),
Supprimer ( ),
Exporter ( )
Base_de_données (‘idcrud’,‘nom’,‘service_business’, Ajouter ( ),
‘instance_name’, ‘HW_model’, ‘OS’, ‘VM’, Modifier ( ),
‘VM_type’, ‘Protocole’, ‘cluster’, Supprimer ( ),
‘technology’, ‘version’, ‘impact_client’, Exporter ( )
‘production’)
Application (‘idcrud’,‘area’,‘nom’,‘localisation’, Ajouter ( ),
‘owner_it_departement’, Modifier ( ),
‘owner_it_personnel’, ‘impact_client’, Supprimer ( ),
‘description’, ‘vendeur’) Exporter ( )
Liens (‘idcrud’,’nom’,’technology’) Ajouter ( ),
Modifier ( ),
Supprimer ( ),
Exporter ( )
Utilisateurs (‘idcrud’,’nom’,’prenom’,’departement’, Ajouter ( ),
‘adresse’, ‘email’, ‘focntion’) Modifier ( ),
Supprimer ( ),
Exporter ( )
Users (‘id’, ‘username’, ‘password’, ‘role’) /
Liaison_BD (‘idcrud’,‘base_de_données’,‘composant_lié’, Ajouter ( ),
‘type_de_lien’, ‘composants_parcourus’, Modifier ( ),
‘liens’, ‘services’) Supprimer ( ),
Exporter ( )
Liaison_application (‘idcrud’, ‘application’, ‘composant_lié’, Ajouter ( ),
‘type_de_lien’, ‘composants_parcourus’, Modifier ( ),
‘liens’, ‘services’) Supprimer ( ),
Exporter ( )
Liaison (‘idcrud’, ‘lien’, ‘composant_emeteur’, Ajouter ( ),
‘composant_recepteur’, ‘service’) Modifier ( ),
Supprimer ( ),
Exporter ( )

Tableau 2.16 : Description des classes


Chapitre2 : Analyse et
conception

c) Description des attributs :

Classe Libelle Description Type Taille


Id_crud L’indentifiant du Numérique 11
Composant composant
Nom Le nom du Alpha- 20
composant numérique
Id_crud L’identifiant de Numérique 11
la BD
Nom Nom de la base Alpha- 20
numérique
Service_business Alpha- 40
numérique
Instance_name Alpha- 20
numérique
HW_Model Modele du Alpha- 20
materiel numérique
OS Système Alpha- 20
d’exploitation numérique
VM Machine Alpha- 5
virtuelle numérique
Base_de_données VM_Type Type de la Alpha- 30
machine numérique
virtuelle
Protocole Protocole utilisé Alpha- 10
numérique
Cluster Alpha- 5
numérique
Technology Alpha- 40
numérique
Version Alpha- 30
numérique
Chapitre2 : Analyse et
conception
Impact_client Alpha- 25
numérique
Production Alpha- 40
numérique

Tableau 2.17 : Description des attributs 1

Classe Libelle Description Type Taille


Idcrud L’id de Numérique 11
l’application
Area Catégorie Alpha- 5
numérique
Nom Nom de Alpha- 20
l’application numérique
Localisation L’emplacement Alpha- 20
materiel de numérique
l’application
Owner_it_departement Departement Alpha- 20
Application responsable de numérique
l’application
Owner_it_personnel La personne Alpha- 25
responsable de numérique
l’application
Impact_client L’utilisateur de Alpha- 25
l’application numérique
Description Description de Alpha- 200
l’application numérique
Vendeurs Vendeur de Alpha- 25
l’application numérique

Idcrud L’identifiant du Numérique 11


Liens lien
Nom Le nom du lien Alpha- 20
numérique
Technology La technologie Alpha- 20
utilisée numérique

Tableau 2.18 : Description des attributs 2


Chapitre2 : Analyse et
conception

Classe Libelle Description Type Taille


Idcrud L’identifiant de Numérique 11
l’utilisateur
Nom Le nom de Alpha- 20
l’utilisateur numérique
Prénom Le prénom de Alpha- 20
l’utilisateur numérique
Utilisateurs Département Département de Alpha- 20
l’utilisateur numérique
Adresse L’adresse de Alpha- 35
l’utilisateur numérique
Email L’adresse mail Alpha- 20
de l’utilisateur numérique
Fonction La fonction de Alpha- 20
l’utilisateur numérique
Id L’identifiant du Numérique 11
user
Username Le nom du user Alpha- 10
Users numérique
Password Mot de passe du Alpha- 20
user numérique
Role Le type du user Alpha- 20
numérique
Idcrud L’identifiant Numérique 11
Base_de_données Le nom de la Alpha- 20
base de données numérique
liée
Composant_lié Le composant Alpha- 20
lié à la BD numérique
Chapitre2 : Analyse et
conception
Type_de_lien Le type de lien Alpha- 10
Liaisons_BD numérique
Composants_parcourus Les composants Alpha- 50
parcourus pour numérique
avoir le lien
Liens La technologie Alpha- 20
du lien numérique
Service La ressource Alpha- 25
obtenue grâce numérique
au lien

Tableau 2.19 : Description des attributs 3

Classe Libelle Description Type Taille


Idcrud L’identifiant Numérique 11
Application Le nom de Alpha- 20
l’application numérique
liée
Composant_lié Le composant Alpha- 20
lié à numérique
l’application
Type_de_lien Le type de lien Alpha- 10
Liaison_application numérique
Composants_parcourus Les composants Alpha- 50
parcourus pour numérique
avoir le lien
Liens La technologie Alpha- 20
du lien numérique
Service La ressource Alpha- 25
obtenue grâce numérique
au lien
Idcrud L’identifiant Numérique 11
Liens La technologie Alpha- 20
du lien numérique
Composant_emeteur Le composant Alpha- 20
Liaison émetteur numérique
Composant_recepteur Le composant Alpha- 20
récepteur numérique
Service La ressource Alpha- 25
obtenue grâce numérique
au lien

Tableau 2.20 : Description des attributs 4


Chapitre2 : Analyse et
conception

2.3.6 Modèle relationnel [] :


Suite à la conception de l’application à développer, il est obligatoire de passer par l’étape
de convertir les diagrammes UML en un modèle relationnel et pour ce, on a utilisé une
procédure suivant les étapes précises, ce procédé se base sur les principes suivants :

- Domaine : l'ensemble des valeurs d'un attribut


- Relation : liste de domaines, c'est un tableau à deux dimensions (colonnes, lignes)
- Les colonnes correspondent aux domaines ou chaque colonne est caractérisée par un
nom.
- Les lignes correspondent à des tuples.
- Attribut : colonne d'une relation, caractérisé par un nom.
- Tuple : valeurs d'une ligne d'une relation.
- Cardinalité : elle permet de définir les conditions de participation d'une entité à une
relation. Toutefois, une entité peut participer à plusieurs relations.
- L'arité : est le nombre d'attributs d'une relation [03].
- Clé : on distingue deux types de clés :
1. Clé primaire : ensemble d'attributs dont les valeurs permettent de distinguer les
tuples les uns des autres (notion d'identifiant).
2. Clé étrangère : attribut qui est clé primaire d'une autre entité qui permet de lier
cette dernière à l'entité contenant sa clé primaire comme clé étranger.
Chapitre2 : Analyse et
conception

Table 2.21 : Règles de passage

a) Schéma relationnel :
Chapitre2 : Analyse et
conception
- Composant (Idcrud*, Nom)
- Base_de_données (Idcrud*, Nom, Service_business, instancen_name, HW_model,
OS, VM, VM_type, Protocole, Cluster, Technology, Version, Impact_client,
Production)
- Application (Idcrud*, Area, Nom, Localisation, Owner_it_departement,
Owner_it_personnel, Impact_client, Description, Vendeurs)
- Liens (Idcrud*, Nom, Technology)
- Utilisateurs (Idcrud*, Nom, Prénom, Département, Adresse, Email, Fonction)
- Users( Id, Username, Password, Role)
- Liaison_BD (Idcrud*, base_de_données, composant_lié, Type_de_lien,
composants_parcourus, liens, service)
- Liaison_application (Idcrud*, Application, composant_lié, Type_de_lien,
composants_parcourus, liens, service)
- Liaison (Idcrud*, Liens, Composants_emeteurs, Composants_recepteurs,Service)

Conclusion :

Apres avoir élaboré les différents diagrammes à savoir le diagramme de cas


d’utilisation, le diagramme de séquence, le diagramme d’activité et le diagramme de classe
nous avons pu avoir une idée claire sur les objectifs attendus du futur système à implémenter.
Nous pouvons maintenant passer à la partie de l’implémentation.