Modelisation Uml

REPUBLIQUE DU CAMEROUN REPUBLIC OF CAMEROON
Paix - Travail - Patrie Peace - Work - Fatherland

******** ********
MINISTERE DE L’ENSEIGNEMENT MINISTRY OF HIGHER
SUPERIEUR EDUCATION
******** ********
UNIVERSITE DE YAOUNDE I UNIVERSITY OF YAOUNDE I
******** ********
ECOLE NATIONALE SUPERIEURE NATIONAL ADVANCED SCHOOL OF
POLYTECHNIQUE DE YAOUNDE ENGINEERING OF YAOUNDE
******** ********
DEPARTEMENT DE GENIE CIVIL ET CIVIL ENGINEERING AND URBAN
URBANISME PLANNING DEPARTMENT
INFORMATIQUE-PROGRAMMATION (GCU 332)

MODELISATION D’UNE BASE DE DONNEES RELATIONNELLES
AVEC UML
REALISE ET PRESENTE PAR LE GROUPE 8 DONT LES MEMBRES SONT :

 ELOGO ELOGO ULRIC ALBERT 22P168
 KOHL MBOCK QUENTIN FRIDOLIN 20P115
 MBAMBA IGNACE 22P162
 NGOUEKO KENFACK LOLI 20P391
 NTOLLA YVES PATRICK 20P184
 SOP KAMDEM VANECK CLINSOR 22P170
 TCHOFFO ERIC 20P382
 TEKONGMO DJUAZON GUERIN 20P338
 TSATEU NGUEMO FRANK URSAIN 20P132
SOUS LA SUPERVISION DE :
M. ENYEGUE GERMAIN, Ingénieur de Conception de Génie Civil et

Chercheur à l’Ecole Doctorale de l’UYI
Année académique 2022/2023

MODELISATION D’UNE BASE DE DONNEES AVEC UML | GROUPE 8
DEDICACE
Nous dédions ce travail à tous nos camarades de la promotion 2025 de

GENIE CIVIL ET URBANISME
~1
RESUME
L’organisation, le stockage et la manipulation de données constituent un enjeu essentiel de

performance. C’est pourquoi le recours aux bases de données en particulier les relationnelles
est aujourd’hui une solution rependue. Ces dernières ont donc un principe de fonctionnement
pour s'assurer de la bonne des données, une multitude de concepts que sont le domaine,
l'attribut et la relation (ou table). Par ailleurs, une BDDR est aussi constituée de 5 éléments
principaux qui sont indispensable pour celle-ci. Ce sont le matériel, le logiciel, les données, la
procédure, et le langage d'accès à la dîtes base de données. Afin de modéliser une base de
données, il est important d'user d'un langage de modélisation et ici nous avons employé UML.
UML est un langage de modélisation graphique utilisé pour concevoir les systèmes logiciels
(bases de données). Dans ce langage, nous retrouvons les concepts tels que les objets, les
activités et les acteurs. Par ailleurs, ce langage est subdivisé en 3 parties à savoir les vues, les
modèles d'éléments et les diagrammes qui sont de 2 catégories (de structure et de
comportement) et ces catégories ont chacune 7 diagrammes. Le diagramme le plus courant
dans la modélisation UML est le diagramme de classe car il décrit la conception logique et
physique d'un système et représente les entités et leurs attributs. Ainsi, avec UML, la
modélisation des bases de données relationnelles permet de représenter les entités, les
relations et les contraintes que l'on peut retrouver dans cette base de données. Mais aussi, c'est
un moyen utile de générer automatiquement le code SQL nécessaire à la création de la base de
données. Donc la modélisation des bases de données avec UML est un outil puissant de
conception des bases de données efficaces et bien structurées.
~2
ABSTRACT
The organization, storage and manipulation of data is an essential performance issue. This is
why the use of databases, particularly relational databases, is now a popular solution. The
latter therefore have an operating principle to ensure the correctness of the data, a multitude of
concepts such as the domain, the attribute and the relationship (or table). In addition, a BDDR
is also made up of 5 main elements which are essential for this one. These are the hardware,
the software, the data, the procedure, and the language of access to the said database. In order
to model a database, it is important to use a modeling language and here we used UML. UML
is a graphical modeling language used to design software systems (databases). In this
language, we find concepts such as objects, activities and actors. In addition, this language is
subdivided into 3 parts namely the views, the models of elements and the diagrams which are
of 2 categories (of structure and behavior) and these categories each have 7 diagrams. The
most common diagram in UML modeling is the class diagram because it describes the logical
and physical design of a system and represents entities and their attributes. Thus, with UML,
the modeling of relational databases makes it possible to represent the entities, the relations
and the constraints that can be found in this database. But also, it is a useful way to
automatically generate the SQL code needed to create the database. So database modeling
with UML is a powerful tool for designing efficient and well-structured databases.
~3
TABLE DES MATIERES
DEDICACE.............................................................................................................................................1
RESUME.................................................................................................................................................2
ABSTRACT.............................................................................................................................................3
INTRODUCTION..................................................................................................................................6
I. LES BASES DE DONNEES RELATIONNELLES.....................................................................7
1. DEFINITION..............................................................................................................................7
2. PRINCIPE DE FONCTIONNEMENT DES BDDR...............................................................8
3. CONCEPTS DES BDDR...........................................................................................................8
a. LE DOMAINE........................................................................................................................8
b. L'ATTRIBUT..........................................................................................................................9
c. LA RELATION (OU TABLE)...............................................................................................9
4. COMPOSANTS DES BDDR.....................................................................................................9
5. AVANTAGES ET INCONVENIENTS DES BDDR...............................................................10
a. AVANTAGES.........................................................................................................................10
b. INCONVENIENTS..............................................................................................................10
6. EXEMPLE D’UNE BASE DE DONNEES RELATIONNELLE : SYSTEME DE
GESTION D’UNE BIBLIOTHEQUE............................................................................................11
II. PRÉSENTATION DU LANGAGE UML...............................................................................13
1. DEFINITION............................................................................................................................13
2. LES CONCEPTS DE BASE ET PARTIES DE UML...........................................................13
a. CONCEPTS DE BASE........................................................................................................13
b. PARTIE DE UML.................................................................................................................16
3. LES DIAGRAMMES D’UML.................................................................................................19
a. LES DIAGRAMMES DE STRUCTURE...........................................................................20
b. LES DIAGRAMMES UML DE COMPORTEMENT......................................................23
4. AVANTAGES ET INCONVENIENTS DE UML...................................................................29
a. AVANTAGES.........................................................................................................................29
b. INCONVENIENTS..............................................................................................................30
III. MODELISATION D’UNE BASE DE DONNEES RELATIONNELLE AVEC UML.......31
1. MODELISATION CONCEPTUELLE..................................................................................31
a. Les concepts et leurs associations........................................................................................31
b. Multiplicités des associations...............................................................................................32
c. Renforcement des associations grâce à la composition.....................................................35
d. Amélioration du diagramme des classes.............................................................................36
e. Restriction de l’instanciation des classes grâce aux classes abstraites............................38
2. MODÉLISATION LOGIQUE................................................................................................39
a. Identifier les éléments clés du modèle relationnel.............................................................39
~4
b. Créer le lien entre tables et clés étrangères........................................................................41
c. Transformer les associations de notre diagramme de classe............................................41
CONCLUSION.....................................................................................................................................51
LISTE DES FIGURES.........................................................................................................................52
LISTES DE TABLEAUX.....................................................................................................................53
REFERENCES BIBLIOGRAPHIQUES...........................................................................................54
~5
INTRODUCTION
Les données sont des informations pouvant être liées à n’importe quel objet. Afin de gérer,
structurer et manipuler ces dernières, il est idoine d’avoir une collection organisée. Cette
collection est appelée Base De Données. Elle est généralement stockée électroniquement dans
un ordinateur. Il en existe une large variété ; nous avons entre autres les bases de données
relationnelles, les bases de données orientées objet, les bases de données distribuées et les
bases de données No SQL (non-relationnelle) mais dans le cadre de ce travail, nous allons
nous intéresser aux BDDR. En outre, toute fois avant la réalisation d’un système, il faut le
modéliser car cela permet de mieux comprendre le fonctionnement du système et est
également un bon moyen de maitriser sa complexité et d’assurer sa cohérence. De plus, la
modélisation d’un système nécessite un langage de modélisation. Dès lors, comment
concevoir une base de données relationnelle efficace avec UML pour répondre aux besoins de
la société ? Dans la suite de ce travail, nous allons tout d’abord donner un aperçu d’une Base
De Données Relationnelle, ensuite nous allons présenter le langage qui sera utilisé au cours de
notre travail à savoir UML et enfin nous allons parler de la modélisation d’une Base De
Données Relati avec UML.
~6
I. LES BASES DE DONNEES RELATIONNELLES

1. DEFINITION
Une base de données relationnelle est un ensemble d'informations qui organise les données
dans des relations prédéfinies et les stockent dans une ou plusieurs tables (ou "relations") de
colonnes et de lignes, ce qui permet de les consulter et de comprendre les relations entre
différentes structures de données. C’est aussi une base de données où l'information est
organisée dans des tableaux à deux dimensions appelés des relations ou table, selon le modèle
introduit par Edgar
F. Codd en 1960. Selon ce modèle relationnel, une base de données consiste en une ou
plusieurs relations. Les relations sont des connexions logiques entre différentes tables qui sont
établies en fonction de l'interaction entre ces tables. Les lignes de ces relations sont appelées
des n- uplets ou enregistrements. Les colonnes sont appelées des attributs.
Figure 1:Structure générale d'une base de données relationnelle
Les logiciels qui permettent de créer, utiliser, maintenir et contrôler les bases de données
relationnelles sont des systèmes de gestion de bases de données relationnelles (SGBDR) de
l’anglais Relational Data Base Management System (RDBMS). Il s’agit de l’interface entre la
base de données et leur utilisateurs finaux ou les programmes.
Pratiquement tous les systèmes relationnels utilisent le langage SQL pour interroger les bases
de données. Ce langage permet de demander des opérations d'algèbre relationnelle telles que
l'intersection, la sélection et la jointure.
~7
2. PRINCIPE DE FONCTIONNEMENT DES BDDR

Une base de données relationnelle est un type de base de données dans lequel les données
sont stockées dans des tableaux, connus sous le nom de "tables". Les tables sont organisées en
colonnes et chaque colonne stocke un type de données spécifique, par exemple un nom, une
adresse ou un numéro de téléphone. Chaque ligne dans la table représente un enregistrement
de données, qui correspond à un élément unique (comme une personne, un produit ou une
commande).
Le principe de fonctionnement des bases de données relationnelles est basé sur le modèle
de donnée relationnel. Ce modèle implique l'utilisation de clés primaires 1et clés étrangères
2
pour lier les tables entre elles.
Ainsi, pour obtenir les informations d'un enregistrement spécifique, le système de gestion
de base de données (SGBD) doit effectuer une opération appelée "jointure" en utilisant les
clés de référence entre les tables. Cette opération permet de relier les colonnes de la table à
d'autres tables, afin de rassembler toutes les informations qui concernent l'enregistrement.
L'utilisation d'une base de données relationnelle permet une meilleure intégrité des
données, une efficacité améliorée dans le stockage, la récupération des données et une
simplicité accrue dans la mise à jour des enregistrements.
3. CONCEPTS DES BDDR

Le domaine, l'attribut et la relation (ou table) sont des concepts fondamentaux des bases
de données relationnelles. Voici une description de chacun de ces concepts :
a. LE DOMAINE
C’est l'ensemble de valeurs qu'un attribut peut prendre dans une table. Il est souvent associé à
un type de données, tel que INTEGER, CHAR ou DATE, et peut inclure des propriétés telles
que la longueur maximale pour les types de données de caractères, la précision et l'échelle
pour les types de données numériques, et la plage de dates pour les types de données de date
et d'heure. Les contraintes de domaine peuvent être utilisées pour garantir que seules les
valeurs appropriées sont stockées dans une colonne.
1
Attributs qui identifient de manière unique chaque entité dans une table
2
Attributs qui référencent les clés primaires d'autres tables et permettent de définir des relations entre les tables
~8
b. L'ATTRIBUT
L'attribut est une caractéristique ou une propriété d'une entité. Il est utilisé pour décrire les
caractéristiques des données dans une table. Par exemple, une table d'employés pourrait
inclure des attributs tels que le nom, le prénom, le numéro d'identification et le salaire. Les
attributs sont souvent associés à un domaine qui spécifie le type de données et les contraintes
pour l'attribut.
c. LA RELATION (OU TABLE)

La relation est la structure de base dans une base de données relationnelle. Elle représente une
collection d'entités ayant des attributs similaires. Par exemple, une table d'employés pourrait
représenter une collection d'entités d'employés ayant des attributs tels que le nom, le prénom,
le numéro d'identification et le salaire. Les relations sont souvent représentées sous forme de
table avec des colonnes pour chaque attribut et des lignes pour chaque entité. Les relations
sont liées entre elles par des clés primaires et des clés étrangères.
4. COMPOSANTS DES BDDR

Une BDDR se compose de 5 éléments principaux
 Le matériel
Encore appelé Hardware, c’est l’élément constitué d’appareils électroniques tels que des
ordinateurs et des systèmes de stockage.
 Le logiciel
Cette partie est un ensemble de programmes utilisés pour gérer et contrôler la base de
données. Elle regroupe le logiciel de BDD, le système d’exploitation le logiciel de réseau
permettant le partage de données et les applications qui permettent l’accès aux données.
 Les données
Ce sont des informations brutes qui sont stockées dans la base de données. Elles peuvent
prendre divers formats.
 La procédure
Ensemble de règles et d’instructions permettant d’utiliser le logiciel de gestion de base de
données.
 Langage d’accès à la BDD
Utilisé pour accéder aux données, pour entrer de nouvelles, pour mettre à jour les données
existantes ou pour les récupérer via les requêtes.
~9
MODELISATION D’UNE BASE DE DONNEES AVEC UML | GROUPE
5. AVANTAGES ET INCONVENIENTS DES BDDR

Les bases de données relationnelles ont été la pierre angulaire de la gestion des données
pendant des décennies et sont toujours utilisées dans des applications de toutes tailles
aujourd'hui. Voici quelques avantages et inconvénients courants des bases de données
relationnelles :
a. AVANTAGES
 Structuration des données :
Les données sont organisées de manière SQL (Structured Query Language) et sont liées entre
elles pour former une architecture logique. Cela permet des requêtes complexes et des
analyses de données approfondies.
 Intégrité des données :
Les bases de données relationnelles ont des contraintes d'intégrité pour s'assurer de la qualité
et de la validité des données stockées. Les données ne peuvent pas être altérées ou supprimées
sans autorisation.
 Adaptabilité :
Les bases de données relationnelles peuvent être mises en réseau pour permettre une
utilisation flexible à travers plusieurs applications et systèmes. Les bases de données peuvent
être étendues à mesure que les besoins de stockage de données augmentent.
 Sécurité :
Les bases de données relationnelles ont des fonctionnalités de sécurité développées pour
s'assurer que les utilisateurs n'ont accès qu'aux données qui leur sont autorisées.
 Cohérence :
Les bases de données relationnelles sont construites pour être cohérentes avec la théorie des
ensembles et les mathématiques, ce qui élimine les incohérences éventuelles.
b. INCONVENIENTS :
 Complexité :
Les bases de données relationnelles peuvent être complexes à comprendre et à utiliser. Les
débutants peuvent avoir besoin d'une formation en SQL et dans la manipulation de données
des bases de données relationnelles.
 Coût :
Les bases de données relationnelles peuvent être coûteuses à mettre en œuvre, à gérer et à
soutenir, car elles nécessitent souvent un personnel expert pour les installer, les configurer et
les maintenir.
~ 10
 Limitation de performances :
Les requêtes complexes pourraient ralentir significativement les performances de la base de
données.
 Conflit de données :
Les conflits de données peuvent survenir lorsque des données sont stockées dans des tables
différentes et qu'elles doivent être mises à jour en même temps.
 Taille :
La taille est souvent limitée sur les bases de données relationnelles en raison de la manière
dont elles sont organisées. Les performances peuvent diminuer à mesure que la taille de la
base de données augmente.
En fin de compte, le choix d'une base de données dépend des besoins de l'entreprise et
des caractéristiques de la solution. Certaines applications se prêtent mieux aux bases de
données relationnelles, tandis que d'autres peuvent bénéficier des bases de données non
relationnelles ou distribuées.
6. EXEMPLE D’UNE BASE DE DONNEES RELATIONNELLE : SYSTEME

DE GESTION D’UNE BIBLIOTHEQUE
Un système de gestion de bibliothèque est un exemple courant d'utilisation de bases de
données relationnelles. La base de données contiendrait des tables pour les livres, les auteurs,
les emprunteurs, les emprunter, domaine etc. Le schéma de la base de données pourrait
ressembler à ceci :
Figure 2: système de gestion d'une bibliothèque
~ 11
Dans ce schéma, il y a quatre tables principales : "Livre", "Auteur", "Emprunteur" et

"Emprunter". Les tables "Livre" et "Auteur" sont liées par une relation "one-to-many" ou
encore “un à plusieurs” car un auteur peut écrire plusieurs livres, mais un livre n'a qu'un seul
auteur. De même, la table "Emprunteur" est liée à la table "Emprunter" par une relation "one-
to-many", car un emprunteur peut emprunter plusieurs livres, mais un livre ne peut être
emprunté plusieurs fois en même temps.
~ 12
II. PRÉSENTATION DU LANGAGE UML
1. DEFINITION
Le langage de modélisation unifié, de l’anglais unified modeling language, est un langage de
modélisation graphique à base de pictogrammes conçu comme une méthode normalisée de
visualisation dans les domaines du développement logiciel et en conception orienté objet.
L’UML est une synthèse de langages de modélisation objet antérieurs : Booch, OMT, OOSE.
Principalement issu des travaux de Grady Booch, James Rumbaugh et Ivar Jacobson, UML
est à présent un standard adopté par l’OMG (Object Management Group). UML 1.0 a été
normalisé en janvier 1997 ; UML 2.0 a été adopté par l’OMG en juillet 2005. La dernière
version de la spécification validée par l’OMG est 2.5.1 en 2017. UML à partir de sa version
1.3 propose neuf
(9) diagrammes tandis qu’il en existe quatorze (14) depuis l’UML 2.3
2. LES CONCEPTS DE BASE ET PARTIES DE UML
a. CONCEPTS DE BASE
Aujourd’hui, il existe deux principaux modèles de représentations des systèmes. Le modèle
fonctionnel et le modèle objet (ou de « l’orienté-objet »). L’approche fonctionnelle n’est pas
adaptée au développement d’applications qui évoluent sans cesse et dont la complexité croit
continuellement et l'approche objet qui a été inventée pour faciliter l'évolution d'applications
complexes, dont les concepts sont :
 MODELE OBJET
L’objet, la classe, l’héritage, l’encapsulation, l’agrégation et le polymorphisme.
 Objet
Un objet est une abstraction d’un élément du monde réel. Il possède des informations, par
exemple nom, prénom, adresse etc., et se comporte suivant un ensemble d’opérations qui lui
sont applicables. De plus, un ensemble d'attributs caractérisent l'état d'un objet, et l'on dispose
d'un ensemble d'opérations (les méthodes) qui permettent d’agir sur le comportement de
l’objet. Ce dernier est le cœur de cette approche. Tout objet donné possède deux
caractéristiques : Son état courant (attributs) et Son comportement (méthodes).
 Classe
On appelle classe la structure d’un objet, c’est-à-dire la déclaration de l’ensemble des entités
qui composeront un objet. Les objets de même nature ont en général la même structure et le
même comportement. La classe factorise les caractéristiques communes de ses objets et
permet de les classifier. Un objet est l’instance d’une classe, et une classe est un type de
~ 13
données
~ 14
abstrait, caractérisé par des propriétés (ses attributs et ses méthodes) communes à ses objets et
un mécanisme permettant de créer des objets ayant ces propriétés. Le concept de classe
permet donc de regrouper des objets de même nature.
Figure 3: exemple de classe d'une voiture
 Heritage
L’héritage est un principe propre à la programmation orientée objet, permettant de créer une
nouvelle classe à partir d’une classe existante. Le nom d’"héritage" (ou parfois dérivation de
classe) provient du fait que la classe dérivée (la classe nouvellement créée) contient les
attributs et les méthodes de sa superclasse (la classe dont elle dérive). L’intérêt majeur de
l’héritage est de pouvoir définir de nouveaux attributs et de nouvelles méthodes pour la classe
dérivée, qui viennent s’ajouter à ceux et celles héritées. Par ce moyen on crée une hiérarchie
de classes de plus en plus spécialisées.
Figure 4: exemple de hiérarchie de classe des œuvres
 L’encapsulation
L'encapsulation est un concept clé de la programmation orientée objet (POO) et se réfère à la
pratique de cacher les détails internes d'un objet de manière à ce que les utilisateurs de cet
objet ne puissent pas y accéder directement. En UML, cela est représenté par la classe
principale qui
~ 15
contient des attributs et des méthodes qui sont définis comme privés. Cela signifie que ces
attributs et méthodes ne peuvent être accédés que par la classe elle-même et pas par les autres
classes.
 L’agrégation
L'agrégation est un autre concept important en UML qui est utilisé pour représenter les
relations entre les classes. Il s'agit d'une relation "partie-tout" où une classe peut être
composée de plusieurs instances d'autres classes. En UML, cela est représenté par une flèche
creuse qui pointe de la classe qui contient les instances vers les instances elles-mêmes. Cette
flèche creuse est appelée une « flèche d'agrégation ».
Figure 5: exemple de l'agrégation
 Polymorphisme
Le polymorphisme en UML permet de créer une structure de classes et de méthodes qui peut
être élargie et modifiée sans compromettre le fonctionnement de l'ensemble du système. Cela
rend le code plus facile à réutiliser et à maintenir à long terme.
Figure 6: exemple de polymorphisme
 MODELE FONCTIONNELLE
Ce sont des concepts utilisés pour créer des diagrammes d’activités UML pour modéliser les
comportements des systèmes. Nous avons entre autres :
~ 16
 L’activité
Une tache ou un comportement effectué par un objet ou un acteur d’un système. Les activités
peuvent être représentées par des rectangles avec bords arrondis.
 L’action
Une étape individuelle dans une activité et représentées par des formes rectangulaires.
 La transition
La connexion entre deux étapes de l’activité et représentés par des flèches.
 Le point de décision
C’est une étape ou une décision prise en fonction d’une condition, et peuvent être représentés
par des losanges.
 Point de fusion
Une étape ou deux branches de l’activité qui se rejoignent et sont représentés par des losanges
avec un ou plusieurs entrées.
 La fourche
Une étape ou une branche d’activités se divisant en plusieurs branches, et sont représentés par
des losanges aves une ou plusieurs sorties.
 L’objet
Un élément du système sur le quelle l’activités est effectués et est représentés par des
rectangles avec coins arrondis.
 L’acteur
Elément extérieur au système qui interagis avec le système et peuvent être représentés par des
silhouettes humaines, rectangle arrondis ou une icône.
b. PARTIE DE UML
UML se décompose en 3 parties :
 LES VUES
Ce sont les observables du système. Elles décrivent le système d'un point de vue donné, qui
peut être organisationnel, dynamique, temporel, architectural, géographique, logique, etc. En
combinant toutes ces vues, il est possible de définir (ou retrouver) le système complet.
 La vue logique
Cette vue de bas niveau (aussi appelée "vue de réalisation"), montre l'allocation des éléments
de modélisation dans des modules (fichiers sources, bibliothèques dynamiques, bases de
données, exécutables, …). En d'autres termes, cette vue identifie les modules qui réalisent
(physiquement) les classes de la vue logique. L'organisation des composants, c'est-à-dire la
~ 17
distribution du code en gestion de configuration, les dépendances entre les composants... Les
contraintes de développement (bibliothèques externes...). La vue des composants montre aussi
l'organisation des modules en "sous-systèmes", les interfaces des sous-systèmes et leurs
dépendances (avec d'autres sous-systèmes ou modules).
 La vue des processus
Cette vue est très importante dans les environnements multitâches ; elle montre la
décomposition du système en terme de processus (tâches) et les liens entre les processus (leur
communication). La synchronisation et la communication des activités parallèles (threads).
 La vue de déploiement
Cette vue très importante dans les environnements distribués, décrit les ressources matérielles
et la répartition du logiciel dans ces ressources, la disposition et nature physique des
matériels, ainsi que leurs performances, l’'implantation des modules principaux sur les nœuds
du réseau et les exigences en terme de performances (temps de réponse, tolérance aux fautes
et pannes...).
 La vue des besoins des utilisateurs
Cette vue (dont le nom exact est "vue des cas d'utilisation"), guide toutes les autres. Dessiner
le plan (l'architecture) d'un système informatique n'est pas suffisant, il faut le justifier ! Cette
vue définit les besoins des clients du système et centre la définition de l'architecture du
système sur la satisfaction (la réalisation) de ces besoins. À l'aide de scénarios et de cas
d'utilisation, cette vue conduit à la définition d'un modèle d'architecture pertinent et cohérent.
Cette vue est la "colle" qui unifie les quatre autres vues de l'architecture.
 La vue d’implémentation
C’est une vue qui se concentre sur les détails de mise en œuvre du système tels que les
attributs et les méthodes. Elle fournit une représentation détaillée de la façon dont les
éléments du système sont réalisés avec des diagrammes.
Une façon de mettre en œuvre UML est de considérer différentes vues qui peuvent se
superposer pour collaborer à une définition du système :
~ 18
Figure 7: Superposition des vues d’UML
~ 19
 LES MODELES D'ELEMENT EN UML

Il décrit les différents types d'éléments qui peuvent être présents dans un modèle UML. Les
éléments sont les "briques de construction" de tout modèle UML, et ils représentent des
concepts tels que les classes, les instances de classes, les relations entre les classes, les
packages, les objets, les attributs, les opérations, les interfaces, les collaborations, les
diagrammes et plus encore.
Figure 8: modèles d'élément en UML
Figure 9: modèle d'élément en UML
~ 110
Figure 10:modèle d'élément en UML
Figure 11: modèle d'élément en UML
 LES DIAGRAMMES
Ce sont des ensembles d'éléments graphiques. Ils décrivent le contenu des vues, qui sont des
notions abstraites. Ils peuvent faire partie de plusieurs vues. Nous allons donc plus
approfondir ce sujet dans la suite.
3. LES DIAGRAMMES D’UML

UML est un langage graphique qui permet de modéliser des systèmes sous la forme d’une
collection d’objets.
Un seul type de modèle n’étant pas suffisant pour décrire correctement un système, UML
dispose de plusieurs types de modèles appelés diagrammes (14 en tout), chaque diagramme
représentant une vue distincte du système.
Il n’est bien sûr pas nécessaire d’utiliser tous les diagrammes pour modéliser un système, il
faut choisir parmi tous les diagrammes disponibles ceux qui sont les plus pertinents et les
mieux adaptés à la modélisation de notre système.
Ces 14 diagrammes sont répartis en 2 groupes :
~ 111
 Les diagrammes structurels ou statiques (structure diagrams).

 Les diagrammes comportementaux ou dynamiques (behavior diagrams).
a. LES DIAGRAMMES DE STRUCTURE

Les diagrammes de structure affichent la structure statique d’un logiciel ou d’un système et ils
présentent plusieurs niveaux d’abstraction et de mise en œuvre. Ceux-ci sont utilisés pour
visualiser les différentes structures qui composent un système, telles qu’une base de données
ou une application. Ils montrent la hiérarchie des composants ou des modules ainsi que la
façon dont ils se connectent et interagissent les uns avec les autres. Ces outils fournissent des
conseils et garantissent que toutes les parties d’un système fonctionnent comme prévu par
rapport à toutes les autres.
Ils sont au nombre de sept à savoir :
 Diagramme de classes
Ce modèle, le plus courant dans le développement de logiciels, est utilisé pour décrire la
conception logique et physique d’un système et pour présenter ses classes. Il ressemble à un
organigramme vu que ces dernières sont représentées par des cases. Ce diagramme propose
un visuel des différentes classes et de leur interdépendance. De plus, chaque classe dispose de
trois parties :
Première partie : le nom de la classe ;
Deuxième partie : les attributs de la classe ;
Troisième partie : les méthodes ou les opérations de la classe.
Figure 12: diagramme UML des classes d’un auteur
 Diagramme d’objets :
Il est souvent utilisé comme un moyen de revérifier l’exactitude d’un diagramme de classe.
Autrement dit, s’il fonctionnera dans la pratique. Ce schéma présente les instances de classes
(objets) d’un système et leurs liens à un instant donné, il donne également une meilleure vue
d’ensemble des défauts de conception potentiels qui doivent être corrigés.
~ 20
Figure 13: diagramme d'objets d’un auteur
 Diagramme de composants :
Également connu sous le nom de diagramme de flux des composants, il montre les
composants du système (éléments logiciels), et leurs mis en œuvre (fichiers, bibliothèques,
bases de données...). En d’autres termes, il offre une vue plus simplifiée d’un système
complexe en le désossant en plus petits composants. Chacun des éléments est représenté par
une case rectangulaire comportant son nom. Les connecteurs définissent la relation/les
dépendances entre les différents composants.
Figure 14: Diagramme de composant d’un logiciel de messagerie
 Diagramme de structure composite :

Il est rarement utilisé en dehors du développement de logiciels. En effet, bien qu’il soit
similaire à un diagramme de classes, il va bien plus loin en décrivant sous forme de boîte
blanche la structure interne de plusieurs classes et en présentant leurs interactions. À moins
que vous ne soyez développeur, une vue de haut niveau est probablement suffisante.
 Diagramme de déploiement :
Il affiche les composants matériels que sont les nœuds (ordinateurs, périphériques, réseaux,
systèmes de stockage...) et logiciels (artefacts), la manière dont les composants du système
sont répartis sur ces éléments matériels et interagissent entre eux. Il apporte une représentation
visuelle de l’endroit exact où chaque composant logiciel est déployé.
~ 21
Figure 15: Diagramme de déploiement d'un système de certification d'arbitre
 Diagramme des paquetages :

Il permet de structurer la modélisation de systèmes complexes en décomposant le système en
plusieurs parties (paquetages). C’est donc la représentation des dépendances entre les
paquetages qui composent un modèle.
Figure 16: Gestion des données d’une compagnie aérienne
 Diagramme de profil :
Il s’agit plus d’un langage que d’un diagramme. Un diagramme de profil permet de créer de
nouvelles propriétés et sémantiques pour les diagrammes UML en définissant des stéréotypes
personnalisés, des valeurs balisées et des contraintes. Grâce à ces profils, vous pouvez
personnaliser un méta modèle UML pour différentes plateformes (par exemple Java Platform,
Enterprise Edition (Java EE) ou Microsoft.NET Framework) et plusieurs domaines (par
exemple, la modélisation des processus opérationnels, l’architecture axée sur le service, les
applications médicales et bien d’autres).
~ 22
Figure 17: diagramme de profil de gestion d' un groupe
b. LES DIAGRAMMES UML DE COMPORTEMENT

Ici, l’accent est mis sur les aspects dynamiques du système ou du processus logiciel. Ces
diagrammes présentent la fonctionnalité d’un système et mettent en évidence ce qui est prévu
dans le système modélisé. Dans le groupe des diagrammes de comportement, UML spécifie la
sous-catégorie "diagrammes d’interaction".
 Diagramme d’activité :
C’est une variante du diagramme états-transitions. Il permet de décrire sous forme de flux ou
d'enchaînement d'activités le comportement du système ou de ses composants. Ce diagramme
comprend un ensemble d’activités qui doivent se produire pour atteindre un but. Outre le
développement de logiciels, ce diagramme peut être utilisé dans pratiquement tous les
environnements professionnels. Ils sont également appelés cartographie ou modélisation des
processus opérationnels.
Figure 18: diagramme d'activité d'une interface
 Diagramme de cas d’utilisation

Un cas d'utilisation (en anglais use case) permet de mettre en évidence les relations
fonctionnelles entre les acteurs et le système étudié. Le format de représentation d'un cas
d'utilisation est complètement libre mais UML propose un formalisme et des concepts issus de
~ 23
bonnes pratiques. Il décrit ce que fait un système, mais pas la manière dont il y parvient. Un
cas d’utilisation correspond à un ensemble d’événements qui se produisent lorsqu’un “acteur”
utilise un système pour terminer un processus. Un acteur est défini comme toute personne ou
tout élément qui interagit avec le système (personne, organisation ou application) de
l’extérieur du système. Ainsi, un diagramme de cas d’utilisation décrit visuellement cet
ensemble de séquences et représente les exigences fonctionnelles du système.
Figure 19: diagramme de cas d'utilisation d'une banque
 Diagramme global d’interaction

Souvent complexe, il ressemble au diagramme d’activité puisque les deux montrent une
séquence d’activités étape par étape. Un diagramme global d’interaction est en réalité un
diagramme d’activité composé de différents diagrammes d’interactions. Il décrit les
enchaînements possibles entre les scénarios préalablement identifiés sous forme de
diagrammes de séquences (variante du diagramme d'activité). Il utilise les mêmes annotations
qu’un diagramme d’activité (initial, final, décision, fusion, nœuds « fork » et « join ») avec
l’ajout d’éléments tels que l’interaction, l’utilisation des interactions ainsi que les contraintes
de temps et de durée.
~ 24
Figure 20: Diagramme global d'interaction d'un service d'inspection
 Diagramme de temps
Il est utilisé lorsque le temps est primordial. Aussi connu sous le nom de diagramme de
séquence ou d’événement, il ne montre pas comment les objets interagissent ou se modifient
entre eux. Sur le plan fonctionnel, il montre comment les objets et les acteurs agissent dans
une ligne du temps. L’accent est mis ici sur la durée des événements et sur les changements
qui surviennent en fonction des contraintes de durée. Les principales parties d’un diagramme
de temps comprennent :
 La ligne de vie : le participant individuel ;
 La ligne du temps de l’état : les différents états par lesquels passe la ligne de
vie à l’intérieur d’une branche ;
 La contrainte de durée : le temps nécessaire pour qu’une contrainte soit
remplie ;
 La contrainte de temps : le délai dans lequel un événement doit être accompli
par le participant ;
 L’événement de destruction : l’endroit où la ligne de vie d’un objet se termine.
Aucun autre cas n’apparaîtra après l’événement de destruction sur une ligne de
vie.
~ 25
Figure 21: Utilisation des contraintes et observations de temps d’un appel téléphonique
 Diagramme états-transitions
Aussi appelé « state chart », ce diagramme s’applique lorsque le comportement d’un objet est
complexe et que le souci du détail est essentiel. Il permet de décrire le comportement d’un
objet (ou parfois d’un opérateur) et la façon dont il change en fonction d’événements internes
et externes.
Figure 22: Etats d’un jeu d’échecs
 Diagramme de séquence
Également bien connu en dehors de la communauté des concepteurs, ce diagramme
visuellement attrayant permet de montrer tous les types de processus opérationnels. Il révèle
simplement la structure d’un système, montrant la séquence des messages et les interactions
entre les acteurs ainsi que les objets dans l’ordre chronologique. Le diagramme de séquence
présente des itérations et des ramifications simples. Il est axé sur le multitâche. Il peut être
utilisé pour affiner le comportement ou la description d’un cas d’utilisation. Cette approche
est utile lors de l’analyse des besoins. Ça peut également être l’opportunité de tester un
modèle statique pendant la conception ; il peut représenter un scénario dans lequel les classes
du diagramme de classes sont instanciées pour créer les objets nécessaires à l’exécution du
scénario.
~ 26
Figure 23. Vérification de commande en ligne
 Diagramme de communication
Un diagramme de communication ou de collaboration est similaire à un diagramme de
séquence, mettant toutefois l’accent sur la communication entre les objets. Il présente
l’organisation des objets qui participent à une interaction et reprend des itérations ainsi que
des ramifications plus complexes. Ce diagramme montre des acteurs, des objets (instances de
classes) et leurs lins de communication (liens entre objets), ainsi que les messages qu’ils
échangent. L’ordre dans lequel les messages sont échangés est représenté par les numéros
d’ordre.
Figure 24. Diagramme de communication d’un échange téléphonique
~ 27
Tableau 1 : Récapitulatif sur l’utilité des diagrammes

Type de
Catégorie Utilité
diagramme
Diagramme de
Représente les classes
classes
Diagramme
Affiche l’état d’un système à un moment donné
d’objet
Diagramme des Affiche les dépendances et les composants de
composants structure
Diagramme de
Divise les modules ou les classes en leurs
Diagramme de structure
composantes et clarifie leurs relations.
structure composite
Diagramme de Regroupe les classes en paquets, représente la

paquetage hiérarchie et la structure des paquets
Diagramme de Affiche la distribution des composants aux nœuds

déploiement de l’ordinateur
Diagramme de Illustre les relations d’usage au moyen de

profil stéréotypes, de conditions aux limites, etc.
Diagramme de
Représente divers usages
cas d’utilisation
Diagrammes de Diagramme Décrit le comportement de différents processus
comportement d’activité (parallèles) dans un système.
Diagramme Documente la façon dont un objet passe d’un état

d’état-transition à un autre par le biais d’un événement.
Diagrammes de Diagramme de Représente le moment des interactions entre les
comportement séquence objets.
- diagrammes
Diagramme de Affiche la répartition des rôles des objets au sein
d’interaction
communication d’une interaction.
~ 28
Diagramme de Démontre la limitation temporelle pour les

temps événements qui mènent à un changement d’état.
Diagramme
Montre comment les séquences et les activités
d’aperçu
interagissent.
d’interaction
Ces diagrammes sont dé pendants hiérarchiquement et se complètent de façon à permettre la

modélisation d’un projet tout au long de son cycle de vie.
Figure 25. Hiérarchie des diagrammes UML
4. AVANTAGES ET INCONVENIENTS DE UML

a. AVANTAGES
 UML est un langage standardisé universellement reconnu pour la modélisation
des systèmes
 Il offre une grande flexibilité et peut être utilisés pour modéliser une grande
variété de système complexe ou non.
 Il permet de communiquer efficacement les idées et les concepts entre les
membres d’une équipe de développement, clients ou parties prenantes.
 UML permet de détecter les erreurs et les incohérences dans ma conception
d’un système avant la mise en œuvre.
~ 29
b. INCONVENIENTS
 UML peut être complexe et difficile à apprendre pour les débutants
 Il peut être abstrait et théorique pour certain développeur.
 Il est couteux à mettre en œuvre car il nécessite l’utilisation d’outil de modélisation
spécialisés.
 UML est trop rigide et restrictif dans certain cas, ce qui peut limiter la réactivité et
l’innovation dans la conception des systèmes.
~ 30
III. MODELISATION D’UNE BASE DE DONNEES

RELATIONNELLE AVEC UML
1. MODELISATION CONCEPTUELLE
a. Les concepts et leurs associations
Pour une bonne compréhension de cette partie, nous considèrerons un exemple pour rendre
fluide la compréhension. Nous considèrerons une base de données d’une entreprise
cinématographique qui prend en compte les films tournés, les lieux de tournage, les
réalisateurs, producteurs.
Pour commencer, nous allons représenter les concepts présents dans nos données, et
chercher les associations qui existent entre ces concepts.
Les concepts sont représentés par le diagramme de classe suivant :
Figure 26.
Dans ce diagramme, nous avons formalisé tous nos concepts sous forme de classes : nous
avons les classes film, Lieu de tournage...
Ensuite, il est question de représenter les associations entre ces différentes classes (de
préférence à l’aide de verbes) comme suit :
~ 31
Figure 27.
b. Multiplicités des associations

Il y a un concept très important quand on définit une association : c’est la notion de
multiplicité. Elle permet de dire si un film peut être réalisé par UN SEUL ou par
PLUSIEURS réalisateurs, et inversement : si un réalisateur peut produire UN SEUL ou
PLUSIEURS films. Il existe trois types d’associations :
 Plusieurs à plusieurs (many-to-many) :
o Un film peut être réalisé par plusieurs réalisateurs, et un réalisateur peut avoir
réalisé plusieurs films ;
 Un à plusieurs (one-to-many) ou plusieurs à un (many-to-one) :
o Un film n’est réalisé que par au plus 1 société de production, et une société
peut produire plusieurs films ;
 Un à un (one-to-one) :
o Vous n’avez pas ce cas dans vos données, mais c’est lorsqu’une instance d’une
classe A ne peut être associée qu’à au plus 1 instance d’une classe B. Et
qu’une instance de B ne peut être associée qu’à au plus 1 instance de A.
Par exemple, un cinéma n’a qu’une seule adresse, et une adresse donnée ne
peut accueillir qu’un seul cinéma.
Ensuite, nous pouvons aller plus loin dans la précision des multiplicités.
Par exemple, quand nous disons « au plus 1 », nous pouvons préciser s’il s’agit de «
strictement 1 », ou bien « 0 ou 1 ». Aussi, quand nous disons « plusieurs », nous pouvons
entendre « 0, 1 ou plus », ou bien « strictement plus que 1 », etc.
~ 32
Voici comment noter cela :

Tableau 2
Au plus 1 :
Notation Abréviation Signification
0..1 (pas d'abréviation) 0 ou 1
1..1 1 Exactement 1
Tableau 3
Plusieurs :
Notation Abréviation Signification
0..* * 0, 1 ou plus
1..* (Pas d'abréviation) Au moins 1
n..n n Exactement n (où n est un

nombre entier)
m..n (Pas d'abréviation) Au moins m et au plus n

(avec m et n nombres
entiers tels que m<n)
Ici, “au plus un” signifiera “exactement un”, et “plusieurs” signifiera “strictement plus de un”.
Voici comment s’utilisent ces notations :
 Un film peut être réalisé par au moins 1 réalisateur (noté 1..*), et un réalisateur peut
avoir produit 0, 1 ou plusieurs (noté *) films :
~ 33
Figure 28. Ajout des multiplicités entre Film et Réalisateur-ice
 Un film est réalisé par exactement 1 société de production (1), et une société peut
produire 0, 1 ou plusieurs films (*) :
Figure 29.Les multiplicités entre Film et Société de production
 Un cinéma a exactement 1 adresse (1), et une adresse donnée ne peut accueillir que 0
ou 1 seul cinéma ( 0..1)
Figure 30.Multiplicités entre Cinéma et Adresse
Remarque : Attention aux côtés de l’association ou on écrit les multiplicités.

Voici donc notre modélisation avec les multiplicités :
~ 34
Figure 31.Multiplicité
c. Renforcement des associations grâce à la composition

Il existe un type d’association particulier, appelé l’association de composition. Celle-ci
s’utilise quand une classe est un composant d’une autre classe.
Pour notre appli, nous pourrions considérer qu’un tournage est un composant du film. En
effet, rien ne sert d’enregistrer dans votre BDD un tournage si nous ne savons pas à quel film
il est associé.
On peut aussi avoir une composition entre Film et SocieteDeProduction. En effet, un film ne
peut exister si une société ne l'a pas produit. De plus, il existe parfois des films différents
ayant le même nom (exemple : au moins quatre films portent le titre Home). Ainsi, pour
identifier un film de manière certaine, on a besoin de son titre mais aussi du nom de sa société
de production, ce qui prouve le lien de dépendance entre ces deux classes.
Voici comment cette composition aurait été représentée : avec un losange noir (plein) du côté
du composite :
Figure 32.Représentation d'une composition
La composition s’emploie quand ces trois caractéristiques sont réunies :
~ 35
 Le composite est « composé » de composants.

 L’association de composition est de type un-à-plusieurs, car le composite peut avoir
plusieurs composants (0..1, 1, *ou1..*), et le composant appartient à un et un seul
composite (la multiplicité est donc forcément1, rien d’autre) : on dit que le composite
n’est pas partageable.
 Il y a un lien entre le cycle de vie du composite et du composant : un
composant disparaît dès que l'objet composite auquel il appartient est supprimé.
Nous obtenons finalement la dernière version de notre modélisation UML !
Figure 33. Modélisation UML
d. Amélioration du diagramme des classes
Jusqu’à maintenant, nous avons parlé de films de manière générale. Mais nos données sont un
peu plus précises que cela. En effet, ce que nous avons appelé « film » peut en réalité être un
long-métrage, un téléfilm ou une série (diffusée sur le web ou à la télévision). Pour être plus
correct, nous allons maintenant employer le terme « Œuvre » au lieu de « Film ». Une
œuvre sera donc soit un long-métrage, soit un téléfilm, ou une série.
Un long-métrage est un film tel que nous l’entendons habituellement, un téléfilm est un film
spécialement conçu pour passer à la télévision plutôt qu’au cinéma, et une série est un
enchaînement de plusieurs épisodes, souvent regroupés en saisons.
Jusqu’à maintenant, le type de l'œuvre est enregistré dans l’attribut typeDeTournage.
Or dans le cas des séries, on connaît parfois le numéro de la saison. Il serait donc préférable
d’ajouter un attribut saison dans la classe Œuvre.
~ 36
Cependant, cet attribut ne sera utilisé que si l'œuvre est une série. Il restera vide si l'œuvre est
un téléfilm ou un long-métrage. Cette solution n’est donc pas optimale. L’idéal serait de
placer cet attribut dans une classe Série.
Heureusement, c’est possible ! On fait cela via la notion d’héritage, comme ceci :
Figure 34.La notion d’héritage modélisée
La relation d’héritage se représente par une flèche triangulaire blanche (vide). Elle indique
que la classeOeuvre (appelée classe mère) est plus générale que ses classes filles, qui sont
plus spécialisées.
Ainsi, toutes les classes filles (Telefilm, SerieetLongMetrage) héritent deOeuvre, et cette
dernière transmet automatiquement à ses filles ses attributs et ses méthodes. De cette manière,
toutes les classes filles possèdent l’attribut Titre. La classe Serie a quant à elle deux attributs :
Titre et Saison.
Sur ce schéma, les classes Telefilm et LongMetrage sont vides. Ce n’est pas grave ! Mais si
nous avions eu plus d’informations dans le fichier, nous avions pu ajouter, par exemple, un
attribut chaine pour indiquer la chaîne de télévision sur laquelle est diffusée le Telefilm.
~ 37
On peut aussi enchaîner les relations d’héritage, en créant les classes SerieTV et SerieWeb !
Voici le résultat :
Figure 35.L'ensemble du diagramme de classe
e. Restriction de l’instanciation des classes grâce aux classes abstraites

Lorsque l’on utilise l’héritage, il est parfois utile de spécifier qu’une classe est abstraite, c’est-
à-dire qu’elle ne peut pas être instanciée.
C’est notre cas : dans la BDD, vous voulez qu’une œuvre soit obligatoirement un téléfilm, une
série TV, une série web ou un long-métrage. La notion d'œuvre est trop générale pour que
vous l’acceptiez. En effet, considérer un téléfilm simplement comme une œuvre, c’est perdre
les informations spécifiques au téléfilm.
Par exemple, En Thérapie est une instance de SerieTV, mais pas de Œuvre. De même, 120
Battements par minute est une instance de LongMetrage. Bref, on veut qu’aucune œuvre soit
enregistrée dans la BDD sans préciser si c’est un téléfilm, une série ou un long métrage.
Pour indiquer une classe abstraite, il suffit de mettre son titre en italique. Voici donc ce que
cela donne si nous définissons Œuvre et Serie comme abstraites :
~ 38
Figure 36.Spécification des classes abstraites Œuvre et Serie
Une classe abstraite est toujours héritée. Elle peut d’ailleurs être héritée par d'autres classes
abstraites, mais en fin de chaîne, il doit y avoir une classe non abstraite.
2. MODÉLISATION LOGIQUE
a. Identifier les éléments clés du modèle relationnel
C’est la première étape et la plus simple. Dans un modèle relationnel, les informations sont
stockées sous forme de tableaux, ou simplement tables. Il s’agit donc de transformer notre
diagramme de classe en modèle relationnel, en passant des classes aux table (nous laissons
pour le moment les classes héritées qu’on verra plus tard).
Voici donc les tables que nous avons actuellement :
 Œuvre ;
 Lieu ;
 Tournage ;
 Societe_de_production ;
 Realisateur_ice.
~ 39
Heureusement, le concept d’attribut existe également dans le modèle relationnel, et il a la même

signification qu’en UML. Retenons juste qu’attribut est synonyme de colonne.
Ainsi, nos cinq tables possèdent les mêmes attributs que leurs classes correspondantes en
UML:
 Localisation_de_la_scene, code_postal, latitude, longitude pour la table lieu ;
 Titre pour la table œuvre ;
 Etc.
Ensuite, nous devons représenter ces tables et il existe différentes façons de le faire : l’une sous
forme de texte, et l’autre sous forme graphique.
i. La représentation textuelle
Notre table lieu, qui possède quatre attributs, s’écrit de cette manière :
Lieu (localisation_de_la_scene : Texte, code_postal : Numérique, longitude : Numérique,
latitude : Numérique)
ii. La représentation graphique
Elle est très similaire à l’UML car elle représente les tables par des rectangles divisés en trois
parties, mais ces trois parties sont remplies différemment qu’en UML. Par défaut, les attributs
sont notés dans la troisième partie (au lieu de la deuxième en UML).
Figure 37.Représentation graphique du modèle relationnel
Contrairement au diagramme UML dont la représentation est définie de manière stricte, la

représentation graphique du modèle relationnel peut différer d’un logiciel à l’autre. Les
illustrations de notre exposé sont réalisées avec le logiciel SQLPowerArchitect.
À ces deux représentations, nous ajouterons une troisième, que nous appellerons
représentation en tableaux. Elle n’est pas officielle et servira juste à illustrer les exemples de
ce cours.
La représentation en tableaux ressemble à ce que vous voyez sur votre tableur :
 Les attributs sont placés en colonne tout en haut ;
~ 40
 Quelques exemples (non exhaustifs) sont placés ensuite au niveau des lignes du tableau:
~ 40
Figure 38.Exemple d’une représentation en tableau du modèle relationnel
Sur cette illustration, on voit que la table lieu contient quatre colonnes et plusieurs lignes.
L’une de ces lignes représente la rue Corvisart et contient les valeurs ("rue Corvisart", 75013,
2.3472, 48.8322).
("rue Corvisart", 75013, 2.3472, 48.8322) est aussi appelé un tuple, un enregistrement, plus
rarement un vecteur ou même un n-uplet ! Si nous étions encore à la phase de modélisation
UML, on pourrait aussi dire que ("rue Corvisart", 75013, 2.3472, 48.8322) est une instance de
la classelieu.
Remarque : Dans une table, l'ordre des lignes et des colonnes n'a pas d'importance et pas de
signification. Deux tables contenant les mêmes colonnes (mais dans un ordre différent) et les
mêmes lignes (dans un ordre différent) sont considérées comme identiques.
b. Créer le lien entre tables et clés étrangères

Lorsque nous avons dessiné notre diagramme UML, nous avons défini les associations entre
classes. Par exemple : une œuvre est produite par une (et une seule) société de production. Il
est question dans cette partie d’être plus précis : il faut savoir quel film est produit par quelle
société. Autrement dit, il faut relier chaque ligne de la table œuvre avec les lignes de
societe_de_production.
La modélisation relationnelle permet cela, grâce au concept de clé étrangère abordé dans la
première partie.
c. Transformer les associations de notre diagramme de classe
i. L’association un à plusieurs
Reprenons notre diagramme UML, et regardons l’association entre Œuvre et
SocieteDeProduction.
Elle est de type un-à-plusieurs. Certes, c’est aussi une composition. Mais une composition est
un cas particulier d'un-à-plusieurs. Si vous le voulez bien, oublions l’aspect composition pour
le moment, pour nous concentrer sur l’aspect un-à-plusieurs :
~ 41
Figure 39.L’association entre « Œuvre » et « SocieteDeProduction »
Cette illustration est un diagramme UML, pas un modèle relationnel.

Comme une société de production produit PLUSIEURS œuvres, il faut ajouter une clé
étrangère dans œuvre qui référence la clé primaire de societe_de_production :
Figure 40.Ajout de la clé étrangère « societe_prod »
Figure 41.Représentation graphique de la clé étrangère
Une association un-à-plusieurs se traduit en ajoutant une clé étrangère dans la table qui est du
côté « plusieurs ». Cette clé étrangère référence la clé primaire de la table qui est du côté « un
».
ii. L’association plusieurs à plusieurs
Prenez maintenant l’association œuvre - realisateur_ice, qui est de type plusieurs-à-plusieurs.
Si vous essayez de mettre une clé étrangère dans œuvre référençant la clé primaire de
realisateur_ice, alors vous verrez qu’une œuvre ne peut avoir qu’un réalisateur : ce n’est pas
~ 42
ce que vous voulez. Si inversement vous mettez une clé étrangère dans realisateur_ice, alors
vous ne pourrez avoir qu’une œuvre par réalisateur.
La solution est d’ajouter une table en plus. Cette table contiendra deux clés étrangères : l’une
référençant œuvre, et l’autre référençant realisateur_ice :
Figure 42.Ajout de la troisième table supplémentaire « assoc_oeuvre_real »
Temporairement, comme vous ne savez pas encore quelle est la clé primaire d’œuvre, j’ai
ajouté une clé primaire artificielle id_oeuvre, juste pour cette illustration.
Vous voyez ici qu’une œuvre peut avoir plusieurs réalisateurs, et qu’un réalisateur peut avoir
réalisé plusieurs œuvres.
La clé primaire de cette nouvelle table sera composée des deux clés étrangères :
Figure 43.Représentation graphique des tables avec leurs clés primaires et étrangères
Comme assoc_oeuvre_real et realisateur_ice sont liées par une clé étrangère ( real), et que
cette clé étrangère fait également partie de la clé primaire de assoc_real_oeuvre, on lie les
deux tables par un trait plein (et non pas en pointillés comme précédemment).
iii. Association un à un
Pour une association un-à-un entre une table A et une table B, on utilise aussi une clé
étrangère. La clé étrangère est placée dans A et elle référence la clé primaire de B.
~ 43
Figure 44.L’association un-à-un des tables « cinéma » et « adresse »
Selon le graphique ci-dessus, un cinéma ne peut avoir qu’une adresse, mais deux cinémas
peuvent avoir la même adresse : ce n’est pas ce que l’on veut.
Pour spécifier qu’une adresse ne peut accueillir qu’un seul cinéma, il faut ajouter une
contrainte d’unicité sur l’attribut adresse. Ainsi, la colonne adresse ne pourra pas contenir
deux fois la même valeur. Ce qui signifie qu'une adresse ne pourra pas accueillir plus d’un
cinéma.
Iv. Transformons les compositions associations
Une composition, c’est un cas particulier d’association un-à-plusieurs. Comme nous l’avons
vu précédemment, il faut donc ajouter une clé étrangère dans la table qui est du côté «
plusieurs », cette clé étrangère référence la clé primaire de la table qui est du côté « un ».
Mais vous le savez désormais, ce qui différencie une composition d’une simple association
un- à-plusieurs, c’est que le composant ne peut exister sans son composite. Ainsi, on identifie
un composant à partir de son composite. C’est-à-dire que la clé primaire du composant
inclut/comprend obligatoirement le composite.
C’est le cas entre une œuvre et sa société de production. Car comme vous l’avez vu
précédemment, une œuvre se définit par son titre ET par la société qui l’a produite (car il
arrive que deux œuvres aient le même titre).
Maintenant que nous avons ajouté une clé étrangère societe_prod dans œuvre, qui référence
societe_de_production, il est donc possible d’identifier chaque œuvre par son titre et sa
société. Vous avez donc trouvé la dernière des clés primaires de votre modèle relationnel :
celle de la table œuvre. La voici : (titre, societe_prod).
Ici, societe_prodest à la fois une clé étrangère et une partie de la clé primaire de oeuvre.
Une composition est traduite de la même manière qu’une association un-à-plusieurs ; mais en
plus, on ajoute à la clé primaire de la table composant la clé étrangère vers la table composite.
Maintenant que vous avez la clé primaire de œuvre, il faut actualiser la table
assoc_oeuvre_real avec cette nouvelle clé. Voici le résultat :
~ 44
Figure 45.Représentation graphique des tables avec leurs clés primaires et étrangères
On a donc le modèle final :
3. Modélisation physique
La modèle Physique des données (MPD ou MPhD) permet de préciser les systèmes de
stockage employés. Les données qui sont stockées et gérées dans un ordinateur le sont
souvent par un système de gestion de base de données (SGBD). Le MPD est l'implémentation
du MLD dans le SGBD retenu.
Un modèle physique de données introduit le contexte spécifique à la base de données qui
manque dans les modèles conceptuels et logiques de données. Il représente les tables,
colonnes,
~ 45
types de données, vues, contraintes, indices et procédures au sein de la base de données et/ou
les informations communiquées lors des processus informatiques.
Les modèles de données physiques doivent être construits en fonction d’un système de gestion
de base de données (SGBD) spécifique (relationnelle) ainsi que des exigences spécifiques des
processus qui fonctionnent sur la base de ces données. Cela nécessite souvent la
dénormalisation des constructions de conception logique pour maintenir l’intégrité
référentielle. Un exemple de ces considérations contextuelles à l’étape de la modélisation
physique des données est la nature des données qui peuvent être/seront traitées et les règles
concernant la façon dont ces processus peuvent être exécutés.
Il est également essentiel de s’assurer que les types de colonnes modélisés sont pris en charge
par le SGBD et que les conventions de dénomination des entités et des colonnes sont
respectées, afin d’éviter les chevauchements sémantiques problématiques. La prise en compte
du contexte technologique signifie que les modèles de données physiques reflètent les besoins
de l’environnement technologique tel qu’il est, ou tel qu’il est prévu.
Le model physique consiste plus précise à implémenter une base de donné dans le SGBDR.
Le SQL (Structured Query Language), ou Langage d'Interrogation Structuré, a été reconnu en
tant que norme officielle de langage de requête relationnelle.
Toutefois, les syntaxes d'extractions des données et de créations des tables varient quelques
peu d'un système de gestion de base de données à l'autre.
 Le principe est donc le suivant :
Le modèle physique consiste donc à ressortir le script SQL de création des tables en précisant
la longueur des champs et les différentes clés.
L’implémentation d’une base de données dans le SGBDR se fait de la manière suivante :
Tout d'abord, un SGBDR est un logiciel qui joue le rôle d'interface entre les utilisateurs et la
Base de Données. Il est chargé de décrire, manipuler et interroger les données d'une Base de
Données. Il est chargé de tous les problèmes liés aux accès concurrents, à la sauvegarde et la
restauration des données. Il doit de plus veiller au contrôle, à l'intégrité et la sécurité des
données. Il est géré par plusieurs logiciels en autre MySQL. Le langage utilisé pour
implémenté les bases de donné est le SQL
 Le langage SQL (sigle de Structured Query Language, en français langage de requête
structurée) est un langage informatique normalisé servant à exploiter des bases de
données relationnelles. La partie langage de manipulation des données de SQL permet
de rechercher, d'ajouter, de modifier ou de supprimer des données dans les bases de
données relationnelles.
~ 46
Un modèle physique de données relationnel MySQL (MPDR-MySQL) est composé des deux
sous-modèles suivants :
 Un modèle physique de données relationnel MySQL classique qui est une
extension du modèle logique de données relationnel (MLD-R) intégrant les
spécificités des systèmes de gestion de base de données relationnelles MySQL.
 Des APIs de tables qui étendent les spécifications du modèle classique.
 Un modèle physique de données relationnel MySQL classique est une extension du
modèle logique de données relationnel (MLD-R) intégrant les spécificités des
systèmes de gestion de base de données relationnelles MySQL.
 Un modèle physique de données relationnel MySQL classique s'attache aux tables,
colonnes, contraintes et relations mais pas aux APIS de tables
Ce qui implique la connaissance des types de données MySQL .
~ 47
 Les APIs des tables sont constituées de déclencheurs et de procédures. Selon la nature
de l'enrichissement à réaliser, il y aura encore des tables et des vues.
 Les déclencheurs fournissent un comportement supplémentaire qui peut être associé à
une entité. Typiquement, cela est utilisé pour faire respecter l’intégrité des données
avant ou après les mises à jour, insère et supprime. Les procédures stockées de base de
données fournissent un moyen d’étendre les fonctionnalités de base de données par les
extensions du langue propriétaire utilisé pour construire des unités fonctionnelles
(scripts). Ces procédures fonctionnelles ne correspondent pas directement à des
entités, ni avoir une relation logique pour eux. La Navigation par des ensembles de
données relationnels est basée sur la rangée. SQL est la langue principale utilisée pour
sélectionner les lignes et de localiser les cas d’un ensemble de table.
 L’enrichissement est l’ajout d’une portion de code permettant d’effectuer une tache
spécifique supplémentaire dans une base de données.
~ 48
 Représentation
Un paquetage UML stéréotypé <<TAPIS>> comporte un conteneur de déclencheurs
<<Triggers>>. Ce paquetage fait usage du conteneur de procédures et fonctions globales
SQL/PSM <<Procedures>>.
La génération de la base de données au format SQL standard donne le code suivant :
Sélectionnez
-- ============================================================
-- Nom de la base : Cameroon_prime_vidéo
-- Nom de SGBD : ANSI Niveau 2
-- Date de création : 16/01/ 2001 22:24
-- Copyright : Groupe 8
-- ============================================================
-- ============================================================
-- Table :LIEU
-- ============================================================
create table LIEU (
Locdelascene CHAR
CODEPOSTAL SMALLINT not null,
LONGITUDE NUMERIC(1) not null
LATITUDE NUMERIC(1) not null
LONGLAT NUMERIC(1) not null
primary key ( LONGLAT)

);
-- ============================================================
-- Index : T_C
-- ============================================================
create unique index T_LIEU_ PK on T_ LIEU ( LONGLAT asc);
-- ============================================================
-- Table : OEUVRE
-- ============================================================
create table T_OEUVRE (
TITRE CHAR
SOC_DE_PROD. CHAR
Type_ de_tournage CHAR
primary key (
SOC_DE_PROD)
);
-- ============================================================
-- Index : T_OEUVRE
============================================================
create table T_TOURNAGE (
LOC_SCENE VARCHAR
CODEPOSTAL VARCHAR
TITRE_OEUVRE VARCHAR( 32)
~ 49
SOCIETE_PROD VARCHAR( 32)

DATE_ DEBUT. VARCHAR( 32)
DATE_ FIN. VARCHAR( 32)
foreign key ( LOC_SCENE)
);
Pour le SGBDR Paradox, nous pouvons :
1. Mettre le fichier des ordres SQL d'insertion dans une colonne de table via un
import de données. Par exemple dans une table Paradox de nom
INSERT_EXEMPLE possédant une colonne de nom SQL_ORDER ;
2. Jouer le script ci-dessus afin d'insérer les données :
Sélectionnez
var
tc TCursor
svarString
sqlVar SQL
dbDatabase endvar
error Trap OnWarnings(True)

db.open(...) => chemin de la base de données cible tc.open(" INSERT_EXEMPLE.db")
scan tc :
svar = TC. SQL_ ORDER
try
sql Var. read FromString(svar) sql Var. executeSQL(db)
on Fail
errorShow() msg Info("ORDRE SQL",s Var) quitLoop
endTry endscan
error Trap OnWarnings(False) endMethod
~ 50
CONCLUSION
Parvenu au terme de ce travail où il a été question pour nous de présenter les généralités sur
les bases de données relationnelles, le langage UML et la modélisation de ces bases avec ce
langage. Il en ressort que, la modélisation d'une base de données relationnelle avec UML offre
de nombreux avantages. Elle permet de réduire les erreurs de conception, d'améliorer la
qualité de la base de données, et d'accélérer le processus de développement grâce à une
meilleure compréhension des besoins. UML offre également une grande adaptabilité,
permettant ainsi aux développeurs de s'adapter aux changements de l'environnement et de la
structure de la base de données. En somme, la modélisation d'une base de données
relationnelle avec UML est un élément crucial pour toute entreprise qui souhaite concevoir
une base de données de qualité.
~ 51
LISTE DES FIGURES

Figure 1:Structure générale d'une base de données relationnelle......................................................7
Figure 2: système de gestion d'une bibliothèque...............................................................................11
Figure 3: exemple de classe d'une voiture..........................................................................................14
Figure 4: exemple de hiérarchie de classe des œuvres.......................................................................14
Figure 5: exemple de l'agrégation.......................................................................................................15
Figure 6: exemple de polymorphisme.................................................................................................15
Figure 7: Superposition des vues d’UML...........................................................................................17
Figure 8: modèles d'élément en UML.................................................................................................18
Figure 9: modèle d'élément en UML..................................................................................................18
Figure 10:modèle d'élément en UML.................................................................................................19
Figure 11: modèle d'élément en UML.................................................................................................19
Figure 12: diagramme UML des classes d’un auteur........................................................................20
Figure 13: diagramme d'objets d’un auteur......................................................................................21
Figure 14: Diagramme de composant d’un logiciel de messagerie..................................................21
Figure 15: Diagramme de déploiement d'un système de certification d'arbitre............................22
Figure 16: Gestion des données d’une compagnie aérienne.............................................................22
Figure 17: diagramme de profil de gestion d' un groupe..................................................................23
Figure 18: diagramme d'activité d'une interface...............................................................................23
Figure 19: diagramme de cas d'utilisation d'une banque.................................................................24
Figure 20: Diagramme global d'interaction d'un service d'inspection............................................25
Figure 21: Utilisation des contraintes et observations de temps d’un appel téléphonique............26
Figure 22: Etats d’un jeu d’échecs......................................................................................................26
Figure 23. Vérification de commande en ligne...................................................................................27
Figure 24. Diagramme de communication d’un échange téléphonique...........................................27
Figure 25. Hiérarchie des diagrammes UML.......................................................................................29
Figure 26................................................................................................................................................31
Figure 27................................................................................................................................................32
Figure 28. Ajout des multiplicités entre Film et Réalisateur-ice......................................................34
Figure 29.Les multiplicités entre Film et Société de production......................................................34
Figure 30.Multiplicités entre Cinéma et Adresse...............................................................................34
Figure 31.Multiplicité...........................................................................................................................35
Figure 32.Représentation d'une composition.....................................................................................35
Figure 33. Modélisation UML.............................................................................................................36
Figure 34.La notion d’héritage modélisée..........................................................................................37
Figure 35.L'ensemble du diagramme de classe..................................................................................38
Figure 36.Spécification des classes abstraites Œuvre et Serie..........................................................39
Figure 37.Représentation graphique du modèle relationnel............................................................40
Figure 38.Exemple d’une représentation en tableau du modèle relationnel...................................41
Figure 39.L’association entre « Œuvre » et « SocieteDeProduction ».............................................42
Figure 40.Ajout de la clé étrangère « societe_prod »........................................................................42
Figure 41.Représentation graphique de la clé étrangère..................................................................42
Figure 42.Ajout de la troisième table supplémentaire « assoc_oeuvre_real »................................43
Figure 43.Représentation graphique des tables avec leurs clés primaires et étrangères...............43
Figure 44.L’association un-à-un des tables « cinéma » et « adresse ».............................................44
Figure 45.Représentation graphique des tables avec leurs clés primaires et étrangères...............45
~ 52
LISTES DE TABLEAUX
Tableau 1 : Récapitulatif sur l’utilité des diagrammes.........................................................................28

Tableau 2................................................................................................................................................33
Tableau 3................................................................................................................................................33
~ 53
REFERENCES BIBLIOGRAPHIQUES
1. IUT de Nice, Cours SGBD 1, 224 pages, P28-30 ; 33-44.

2. Odile PAPINI, Bases de données, ESIL, Université de la méditerranée,
https://www.cours-gratuit.com/cours-bases-de-donnees/generalites-sur-les-bases-de-
donnees/amp, 41 pages
3. « Qu’est ce qu’une base de données relationnelle | Oracle France »,
https://www.oracle.com/fr/database/base-de-donnees-relationnelle-definition.html
(05/05)
4. « CONCEPTION DES BASES DE DONNEES RELATIONNELLES »,
http://tecfatu.unige.ch/staf-h/tassini/staf2x/Heidi/last_bd.htm (05/05)
5. « Base de données : qu’est-ce que c’est, et comment ça fonctionne ? »,
https://datascientest.com/base-de-donnees-definition (05/05)
6. « Les Bases de Données Relationnelles – l’Informatique, c’est fantastique! »,
https://info.blaisepascal.fr/cpge-bases-de-données-relationnelles/ (05/05)
7. « CHAPITRE II : PRESENTATION DU LANGAGE DE MODELISATION UML |
Université du Lac Tanganyika », https://ult.bi/fr/chapitre-ii-presentation-du-langage-
de-modelisation-uml (05/05)
8. « Présentation d’UML[Introduction à la modélisation conceptuelle de données avec
UML] », https://librecours.net/module/bdd/mod1/mod1c21.xhtml (05/05)
9. « Qu’est-ce que le langage UML | Lucidchart »,
https://www.lucidchart.com/pages/fr/langage-uml (05/05)
10. « IFT6825 Génie logiciel – UML »,
https://www.iro.umontreal.ca~DIFT6825/UML.htm (05/05)
11. « UML (informatique) – Wikipédia »,
https://fr.m.wikipedia.org/wiki/UML_(informatique) (05/05)
12. « Présentation di langage de modélisation unifié (UML) – Cybermédiane »,
https://www.cybermedian.com/fr/unified-modeling-language-uml-introduction/
(05/05)
~ 54

Modelisation Uml

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Modelisation Uml

Transféré par

Droits d'auteur :

Formats disponibles

REPUBLIQUE DU CAMEROUN REPUBLIC OF CAMEROON

Paix - Travail - Patrie Peace - Work - Fatherland

INFORMATIQUE-PROGRAMMATION (GCU 332)

REALISE ET PRESENTE PAR LE GROUPE 8 DONT LES MEMBRES SONT :

M. ENYEGUE GERMAIN, Ingénieur de Conception de Génie Civil et

Année académique 2022/2023

Nous dédions ce travail à tous nos camarades de la promotion 2025 de

L’organisation, le stockage et la manipulation de données constituent un enjeu essentiel de

TABLE DES MATIERES

I. LES BASES DE DONNEES RELATIONNELLES

Figure 1:Structure générale d'une base de données relationnelle

2. PRINCIPE DE FONCTIONNEMENT DES BDDR

3. CONCEPTS DES BDDR

c. LA RELATION (OU TABLE)

4. COMPOSANTS DES BDDR

5. AVANTAGES ET INCONVENIENTS DES BDDR

6. EXEMPLE D’UNE BASE DE DONNEES RELATIONNELLE : SYSTEME

Figure 2: système de gestion d'une bibliothèque

Dans ce schéma, il y a quatre tables principales : "Livre", "Auteur", "Emprunteur" et

II. PRÉSENTATION DU LANGAGE UML

Figure 3: exemple de classe d'une voiture

Figure 4: exemple de hiérarchie de classe des œuvres

Figure 5: exemple de l'agrégation

Figure 6: exemple de polymorphisme

 LES MODELES D'ELEMENT EN UML

Figure 8: modèles d'élément en UML

Figure 9: modèle d'élément en UML

Figure 10:modèle d'élément en UML

Figure 11: modèle d'élément en UML

3. LES DIAGRAMMES D’UML

 Les diagrammes structurels ou statiques (structure diagrams).

a. LES DIAGRAMMES DE STRUCTURE

Figure 12: diagramme UML des classes d’un auteur

Figure 13: diagramme d'objets d’un auteur

Figure 14: Diagramme de composant d’un logiciel de messagerie

 Diagramme de structure composite :

Figure 15: Diagramme de déploiement d'un système de certification d'arbitre

 Diagramme des paquetages :

Figure 16: Gestion des données d’une compagnie aérienne

Figure 17: diagramme de profil de gestion d' un groupe

b. LES DIAGRAMMES UML DE COMPORTEMENT

Figure 18: diagramme d'activité d'une interface

 Diagramme de cas d’utilisation

Figure 19: diagramme de cas d'utilisation d'une banque

 Diagramme global d’interaction

Figure 20: Diagramme global d'interaction d'un service d'inspection

Figure 22: Etats d’un jeu d’échecs

Figure 23. Vérification de commande en ligne

Figure 24. Diagramme de communication d’un échange téléphonique

Tableau 1 : Récapitulatif sur l’utilité des diagrammes

Diagramme de Regroupe les classes en paquets, représente la

Diagramme de Affiche la distribution des composants aux nœuds

Diagramme de Illustre les relations d’usage au moyen de

Diagrammes de Diagramme Décrit le comportement de différents processus

comportement d’activité (parallèles) dans un système.

Diagramme Documente la façon dont un objet passe d’un état

Diagrammes de Diagramme de Représente le moment des interactions entre les

comportement séquence objets.

Diagramme de Démontre la limitation temporelle pour les

Ces diagrammes sont dé pendants hiérarchiquement et se complètent de façon à permettre la

Figure 25. Hiérarchie des diagrammes UML

4. AVANTAGES ET INCONVENIENTS DE UML

III. MODELISATION D’UNE BASE DE DONNEES