0% ont trouvé ce document utile (0 vote)
114 vues55 pages

Chap 2

Le document décrit les étapes du processus de conception d'une base de données, notamment la planification, l'analyse, la conception et la construction. Il inclut des exemples et des diagrammes pour illustrer ces étapes.

Transféré par

hamid kamal
Copyright
© © All Rights Reserved
Nous prenons très au sérieux les droits relatifs au contenu. Si vous pensez qu’il s’agit de votre contenu, signalez une atteinte au droit d’auteur ici.
Formats disponibles
Téléchargez aux formats PPT, PDF, TXT ou lisez en ligne sur Scribd
0% ont trouvé ce document utile (0 vote)
114 vues55 pages

Chap 2

Le document décrit les étapes du processus de conception d'une base de données, notamment la planification, l'analyse, la conception et la construction. Il inclut des exemples et des diagrammes pour illustrer ces étapes.

Transféré par

hamid kamal
Copyright
© © All Rights Reserved
Nous prenons très au sérieux les droits relatifs au contenu. Si vous pensez qu’il s’agit de votre contenu, signalez une atteinte au droit d’auteur ici.
Formats disponibles
Téléchargez aux formats PPT, PDF, TXT ou lisez en ligne sur Scribd

2 Processus de

conception de BD
Planification Pourquoi ?
Spécification des
besoins

Analyse
Quoi ?
Modèle conceptuel

Conception Comment ?
Modèle physique

Construction

Schémas (LDD),
modules codés et testés

Mise en oeuvre

Maintenance

04/09/23 © Robert Godin. Tous droits réservés. 1


Processus de développement

 Cycle de vie en cascade


 Cycle de vie itératif
 ...

04/09/23 © Robert Godin. Tous droits réservés. 2


2.1 Planification
 Pourquoi développer un système ?
 Étude d'opportunité
– risques
– coûts
– bénéfices
 Document des exigences logicielles
– spécification de haut niveau du système
– diagramme de contexte
 UML : diagramme des cas d ’utilisation

04/09/23 © Robert Godin. Tous droits réservés. 3


2.1.1 Etude de cas : SyLeRat

 Développement d'un système d’information


pour la bibliothèque LeRat
– gestion des collections
– service de prêt
– suivi des retards
– service de repérage documentaire
– alimenté par SystèmeAcquisitions

04/09/23 © Robert Godin. Tous droits réservés. 4


2.1.2 Acteurs et cas
d'utilisation
 Cas d ’utilisation (use cases) Jacobson (92)
– interface au système d'un point de vue de son
utilisation par acteurs
 Acteur
– entité externe qui interagit avec le système

04/09/23 © Robert Godin. Tous droits réservés. 5


Diagramme de contexte de SyLeRat

Consulter ProduireRapportActivités
Membre Bibliothécaire

InclureAcquisitions
SystèmeAcquisition

GérerPrêts
Commis au prêt

GererSystème
Administrateur
Système

04/09/23 © Robert Godin. Tous droits réservés. 6


Documentation d'accompagnement
pour le cas d'utilisation GérerPrêt
Nom: GérerPrêts
Description courte : Gérer les prêts.
Type: Interactif
Description: Ce cas d'utilisation est déclenché par le commis au prêt suite à une requête d'un
membre ou d'un employé. Il lui permet d'enregistrer un prêt ou un retour, de consulter les prêts,
de gérer les données d'identification des membres, i.e. l'identificateur d'utilisateur de sa carte de
membre, le mot de passe du membre, son nom, prénom et le numéro de téléphone de sa
résidence. Il permet aussi de produire un rapport des retards. Lors d'un prêt ou d'un retour,
l'identificateur d'utilisateur et l'identificateur de l'exemplaire peuvent être saisis en utilisant un
lecteur optique ou manuellement.
Règles du domaine d'application:

1. La durée maximale d’un prêt est fixée à 7 jours pour un membre.

2. Le nombre maximal d'emprunts est fixé à cinq pour un membre.

3. Il est interdit d'effectuer un prêt lorsqu'un membre a un retard.

4. Les contraintes précédentes ne s'appliquent pas aux emprunts effectués par les employés.

Exigence de performance : Le temps d'attente de la validation de l'identificateur de l'utilisateur


et de la vérification des conditions requises pour un emprunt doit être inférieur à 1 seconde.

Exigence de sécurité : Le commis doit être autorisé à l'aide de son identificateur d'utilisateur et
de son mot de passe.

04/09/23 © Robert Godin. Tous droits réservés. 7


2.1 Analyse : modèle
conceptuel de données
 Modèle conceptuel de données :
représentation abstraite des informations à
placer dans la base de données qui est
indépendante de la technologie utilisée pour
l’implémentation
 ~Données persistantes du Platform
Independent Model (PIM) de Model Driven
Architecture (MDA) de l’OMG

04/09/23 © Robert Godin. Tous droits réservés. 8


Représentation du
modèle conceptuel
 Formalisme entité/association (Chen, 76)
– diverses extensions
 Modèles sémantiques
– graphes conceptuels (Sowa), SDM, ...
 UML
– ~ entité/association++
– diagramme de structure statique (diagrammes de
classes)

04/09/23 © Robert Godin. Tous droits réservés. 9


2.3 Diagrammes de
classes UML {chevauchante,
Personne
complète} {Le nombre de PrêtEnCours
nom : String
prénom : String d'un Membre <= nbMaxPrêts}
{dateRetour >= datePrêt}
Utilisateur
{UNIQUE :idUtilisateur} Prêt
idUtilisateur : String datePrêt : Date
1 *
motPasse : String
* {statut = "prêté" ssi
PrêtEnCours de
catégorieUtilisateur {disjointe, complète} l'Exemplaire est non vide}

{disjointe, complète}
PrêtArchivé PrêtEnCours
dateRetour : Date
Employé Membre
{UNIQUE : codeMatricule} téléphoneRésidence : String
codeMatricule : String nbMaxPrêts : Integer = 5
catégorieEmployé : enum(bibliothécaire, commis) duréeMaxPrêts : Integer = 7
1

Livre Exemplaire
{ordonné} {UNIQUE: ISBN} {UNIQUE: idExemplaire}
Auteur
ISBN : String idExemplaire : String
1..* 1..* titre : String 1 1..* dateAchat : Date
annéeParution : TypeDonnéesAnnée statut : enum(prêté, disponible, retiré)
1..* 0..*
Editeur 1
1 {Il ne peut y avoir plus d'un PrêtEnCours pour
{UNIQUE: nomEditeur} Catégorie un même Exemplaire}
nomEditeur : String enfant
{UNIQUE: code}
ville : String code : String
* <<datatype>>
descripteur : String TypeDonnéesAnnée
parent 0..1 {Integer > 0 }

04/09/23 © Robert Godin. Tous droits réservés. 10


2.3.1 Notion d'objet et
de classe
 Objet (instance d'une classe)
– significatif pour le domaine d'application
– caractérisé par
 identité
 état
 comportement
 Attribut (variable membre, variable d'instance)
– contenant pour une valeur
– état

04/09/23 © Robert Godin. Tous droits réservés. 11


Représentation d ’un objet
en UML

unLivre unEditeur

ISBN : String = 0-201-57168-4 nomEditeur : String = Addison W esley


titre : String = The Unified Modeling Language User G uide ville : String = Reading, MA
annéeParution : Integer = 1999

unAuteur
unAutreLivre
nom : String = Booch
ISBN : String = 0-201-30998-X prénom : String = G rady
titre : String = The Unified Modeling Language Reference Manual
annéeParution : Integer = 1999

unAutreAuteur

nom : String = Rumbaugh


prénom : String = James

04/09/23 © Robert Godin. Tous droits réservés. 12


Classe
 Abstraction
 Caractéristiques communes à un ensemble
d'objets
– attributs
– associations
– opérations

04/09/23 © Robert Godin. Tous droits réservés. 13


Représentation d ’une
classe en UML
Editeur

nomEditeur : String
Livre ville : String

ISBN : String
titre : String
annéeParution : Integer

Auteur

nom : String
prénom : String

04/09/23 © Robert Godin. Tous droits réservés. 14


Intension/extension
 Intension (intent) d'une classe
– propriétés communes (attributs, associations et
opérations)
 Extension (extent) d'une classe
– ensemble des objets correspondant à la classe
 extension représentée par un objet ?

04/09/23 © Robert Godin. Tous droits réservés. 15


Terminologie
 Objet
– instance, occurrence, entité
 Classe à l ’analyse
– abstraction
– pas toujours une classe d ’implémentation
– concept, entité, type (stéréotype UML)
– stéréotype « entité » pour données persistantes du
domaine d ’application
– valeur étiqueté {persistent}

04/09/23 © Robert Godin. Tous droits réservés. 16


Stéréotype UML

<<entity>>
Livre
ISBN : String
ti tre : String
annéeParution : Integer

04/09/23 © Robert Godin. Tous droits réservés. 17


Identifiant d'objet (OID,
object identifier)
 Mécanisme d ’identification
– pas deux objets avec le même OID
 Implicite
– non visible
– réalisation traitée à la conception
 Mécanisme de référence

04/09/23 © Robert Godin. Tous droits réservés. 18


Pas besoin d ’identificateur
explicite !
 Par opposition au relationnel

O ID =154396 O ID = 204395

: Prêt : Prêt

datePrêt : date = 10/10/2000 datePrêt : date = 10/10/2000

04/09/23 © Robert Godin. Tous droits réservés. 19


Identifiant naturel (ou clé
«key») pour une classe
 Ensemble d'attributs minimal qui identifie
chacun des objets de manière unique
– ~clé candidate du relationnel
 Représentation par une contrainte UML
Membre

{UNIQ UE:idMembre,
UNIQ UE:nom, prénom}
idMembre
nom
prénom
téléphone

04/09/23 © Robert Godin. Tous droits réservés. 20


Syntaxe générale pour la spécification
des attributs en UML

 [visibilité] nom [multiplicité] [: type] [= valeurInitiale]


[{propriétés}
– visibilité peut être :
 + publique
 # protégé
 - privé
– nom de l'attribut
– multiplicité ( [1..1] par défaut)
 téléphone[1..2]: String
 adresse [0..1]: String
 auteurs [1..*]: String

04/09/23 © Robert Godin. Tous droits réservés. 21


Syntaxe pour attributs (suite)
 [visibilité] nom [multiplicité] [: type] [= valeurInitiale] [{propriétés}]
– type
 OCL
– Boolean, Integer, Real, String, enum{valeur1,…, valeurn}
 types de la plate-forme visée
 type non pré-défini
– classe de stéréotype «datatype»
• stéréotype « enumeration »
 ~domaine en modélisation conceptuelle

04/09/23 © Robert Godin. Tous droits réservés. 22


Syntaxe pour attributs (suite)

 [visibilité] nom [multiplicité] [: type] [= valeurInitiale] [{propriétés}]


– valeurInitiale
 à la création de l ’objet
– propriétés
 prédéfinies :
– changeable (par défaut)
– addOnly
– frozen
– portée
 souligner attribut de classe (Rational Rose 98 :$)

04/09/23 © Robert Godin. Tous droits réservés. 23


2.3.2 Notion de lien et
d'association binaire
Lien
Rédige unAuteur : Auteur
unLivre : Livre
nom : String = Booch
ISBN : String = 0-201-57168-4 prénom : String = G rady
unEditeur : Editeur titre : String = T he Unified Modeling Language User Guide
Edite annéeParution : Integer = 1999
nomEditeur : String = Addison W esley Rédige
ville : String = Reading, MA

Rédige
Edite
unAutreLivre : Livre unAutreAuteur : Auteur

ISBN : String = 0-201-30998-X nom : String = Rumbaugh


titre : String = T he Unified Modeling Language Reference Manual prénom : String = James
annéeParution : Integer = 1999 Rédige

Association

Editeur Livre Auteur


1..* 1..*

1 Edite> ISBN : String <Rédige 1..*


nomEditeur : String nom : String
ville : String titre : String prénom : String
annéeParution : Integer

04/09/23 © Robert Godin. Tous droits réservés. 24


Rôles et multiplicités
 Nom de rôle
Partie 0..* 1 Equipe
partie locale receveur
numéro nom
date 0..* 1 ville
heure visiteur
partie à l'étranger

 Exemple avec nom de rôle et d ’association


Partie 0..* < Est receveur pour 1 Equipe
partie locale receveur
numéro nom
date 0..* < Est visiteur pour 1 ville
heure visiteur
partie à l'étranger

04/09/23 © Robert Godin. Tous droits réservés. 25


Association réflexive

Personne
parent nom
prénom
2 dateNaissance
sexe

* enfant

04/09/23 © Robert Godin. Tous droits réservés. 26


Contraintes pré-définies
pour les associations
 Ordonné (ordered)
Livre Auteur
1..* {ordonné}
ISBN : String <Rédige 1..* nom : String
titre : String prénom : String
annéeParution : Integer
 Modifiable (changeable)
 InsertionSeulement (addOnly)
 Fixe (frozen)
 Exclusives
– entre deux associations

04/09/23 © Robert Godin. Tous droits réservés. 27


2.3.3 Agrégation
 Cas particulier d ’association

Auto

0..1
0..1 0..1 0..1

1 1 2,4 4
Moteur Châssis Porte Pneu

04/09/23 © Robert Godin. Tous droits réservés. 28


Composition
Livre
1
tableDesMatières 1
1
1 1 1 0..1
TableDesMatières
glossaire Glossaire
chapitres 1..*
index 1
Chapitre bibliographie 1 Index
Bibliographie

Livre
tableDesMatières : TableDesMatières
chapitres[1..*] : Chapitre
bibliographie : Bibliographie
index : Index
glossaire[0..1] : Glossaire

04/09/23 © Robert Godin. Tous droits réservés. 29


2.3.4 Associations
qualifiées
 Partition des objets associés
Contrainte d ’identification locale
Cours
sigle numéro Groupe
titre session nb_maximum_inscrits
nb_crédits 0..1
1

{UNIQUE : Cours, numéro, session}


Cours Groupe
sigle numéro
titre session
nb_crédits 1 0..* nb_maximum_inscrits

04/09/23 © Robert Godin. Tous droits réservés. 30


2.3.5 Classes associatives

 Données spécifiques à l ’association


Etudiant Cours
nom sigle
prénom * * titre

Incorrect si plusieurs notes


pour un Etudiant et un Cours
NoteObtenue
note
session

04/09/23 © Robert Godin. Tous droits réservés. 31


Réification de l ’association

 Plusieurs notes pour un Etudiant et un Cours

Etudiant Cours
nom sigle
prénom titre

1 1

* NoteObtenue *
note
session

04/09/23 © Robert Godin. Tous droits réservés. 32


Autre solution : classe
associative + agrégation
Etudiant Cours
nom sigle
prénom * * titre

NotesObtenues

*
Note
note
session

04/09/23 © Robert Godin. Tous droits réservés. 33


Solution avec classe Groupe

Etudiant Groupe Cours


numéro
nom nb_maximum_inscrits sigle
session
prénom * * 0..1 1 titre

NoteObtenue
note

Créer un objet session ?

04/09/23 © Robert Godin. Tous droits réservés. 34


2.3.6 La généralisation/
spécialisation
Personne
nom
prénom
adresse
téléphoneRésidence Propriétés communes :
classe plus générale

Employé Etudiant
codeMatricule codePermanent
téléphoneBureau

Em pl oyé Etudiant

nom nom
prénom prénom
adresse
Héritage
adresse
téléphoneRésidence téléphoneRésidence
codeMatricule codePermanent
téléphoneBureau

04/09/23 © Robert Godin. Tous droits réservés. 35


Notation multi-segments
Personne
nom
prénom
adresse
téléphoneRésidence

Employé Etudiant
codeMatricule codePermanent
téléphoneBureau

04/09/23 © Robert Godin. Tous droits réservés. 36


Mise en facteur par
délégation ?
Personne
nom
prénom
adresse
téléphoneRésidence
1 1

0..1 0..1

Employé Etudiant
codeMatricule codePermanent
téléphoneBureau

04/09/23 © Robert Godin. Tous droits réservés. 37


Discriminant
Utilisateur
Discriminant {UNIQUE :idUtilisateur}
idUtilisateur : String
motPasse : String
catégorieUtilisateur

Employé Membre
{UNIQUE : codeMatricule} téléphoneRésidence : String
codeMatricule : String nbMaxPrêts : Integer = 5
catégorieEmployé : enum(bibliothécaire, commis) duréeMaxPrêts : Integer = 7

04/09/23 © Robert Godin. Tous droits réservés. 38


2.3.6.1 Contraintes pré-définies
pour la généralisation
Complète /incomplète Personne
nom Italique pour nom de
Disjointe/chevauchante prénom classe abstraite
adresse
téléphoneRésidence

{complète, chevauchante}

Employé Etudiant
{UNIQUE: codeMatricule} {UNIQUE: codePermanent}
codeMatricule codePermanent
téléphoneBureau

04/09/23 © Robert Godin. Tous droits réservés. 39


Notation alternative par
une note UML
Personne
nom
prénom
adresse
téléphoneRésidence {chevauchante, complète}

Employé Etudiant
{UNIQUE: codeMatricule} {UNIQUE: codePermanent}
codeMatricule codePermanent
téléphoneBureau

04/09/23 © Robert Godin. Tous droits réservés. 40


2.3.7 Héritage multiple
Personne
nom
prénom
adresse
téléphoneRésidence

Employé Etudiant
{UNIQUE: codeMatricule} {UNIQUE: codePermanent}
codeMatricule codePermanent
téléphoneBureau

EmployéEtudiant
dégrèvement

04/09/23 © Robert Godin. Tous droits réservés. 41


2.3.7.1 Multi-classification
et héritage multiple
Personne
nom
prénom
adresse
téléphoneRésidence

Employé
{UNIQUE: codeMatricule} Etudiant
codeMatricule {UNIQUE: codePermanent}
téléphoneBureau codePermanent

catégorieEmployé {disjointe, complète} catégorieEtudiant {disjointe, complète}

Cadre Soutien Enseignant EtudiantPremierCycle EtudiantGradué


mur fonction département sujetRecherche

04/09/23 © Robert Godin. Tous droits réservés. 42


Sous-classes de jointure?

Personne
nom
prénom
adresse
téléphoneRésidence

Employé
{UNIQUE: codeMatricule} Etudiant
codeMatricule {UNIQUE: codePermanent}
téléphoneBureau codePermanent

catégorieEmployé {disjointe, complète} catégorieEtudiant {disjointe, complète}

Cadre Soutien Enseignant EtudiantPremierCycle EtudiantGradué


mur fonction département sujetRecherche

CadreEtudiantPremierCycle SoutienEtudiantPremierCycle EnseignantEtudiantPremierCycle CadreEtudiantGradué SoutienEtudiantGradué EnseignantEtudiantGradué

04/09/23 © Robert Godin. Tous droits réservés. 43


Modélisation par rôle
Person ne
nom
prénom
adresse
télé ph oneRési dence

1 1
rô leEmployé 0..1 0..1 rôl ele Etudi ant

Employé Etudi ant


{UNIQUE: codeMatricule} {UNIQUE: codePerma nen t}
cod eMatri cul e codePermanent
télé phoneBureau

catég orie Empl oyé {disj oi nte, co mpl ète } catégori eEtu di ant {disjoi nte, comp lète}

Cadre Soutien En sei gnant EtudiantPremierCycl e Etudi antGradué


mur foncti on dépa rtement sujetRecherche

04/09/23 © Robert Godin. Tous droits réservés. 44


2.3.8 Attribut de classe

Membre
téléphoneRésidence
nbMaxPrêts = 5
duréeMaxPrêts = 7
Souligner l ’attribut (UML 1.1)

04/09/23 © Robert Godin. Tous droits réservés. 45


2.3.9 Opérations
Employé
 Signature d'une opération codeMatricule : String
nom : String
– nom et type des paramètres prénom : String

getCodeMatricule() : String
salaire () : Real

Permanent Surnuméraire
salaireAnnuel : Real tauxHoraire : Real
nbHeures : Real
setSalaireAnnuel(s : Real)
salaire() : Real setNbHeures(h : Real)
setTauxHoraire(t : Real)
salaire() : Real

Cadre
prime : Real

setPrime(p : Real)
salaire() : Real

04/09/23 © Robert Godin. Tous droits réservés. 46


Syntaxe générale pour la spécification
des opérations en UML

 [«stéréotype»][visibilité] nom [(listeParamètres)] [: typeRetour] [{propriétés}]


– visibilité peut être :
 + publique
 # protégé
 - privé
– nom de l ’opération
– listeParamètres
 syntaxe d ’un paramètre
 [direction] nomParamètre : typeParamètre [ =
valeurDeDéfaut]
– direction (in, out ou inout)

04/09/23 © Robert Godin. Tous droits réservés. 47


Syntaxe pour opérations
(suite)
 [«stéréotype»][visibilité] nom [(listeParamètres)] [: typeRetour]
[{propriétés}]
– typeRetour
 optionnel
– portée
 souligner opération de classe (Rational Rose 98 : $)
– abstraite
 en italique

04/09/23 © Robert Godin. Tous droits réservés. 48


Interface
 Opérations publiques visibles
 Définition d ’une interface de classe
– classe stéréotypée

04/09/23 © Robert Godin. Tous droits réservés. 49


Définitions
 Méthode
– une implémentation d'une opération
 Polymorphisme
– même signature d'opération
– méthodes distinctes pour des classes distinctes
 Surcharge (« overloading »)
– même nom avec signatures différentes

04/09/23 © Robert Godin. Tous droits réservés. 50


Catégories d ’opérations

 Constructeur
 Modifieur
 Lecteur
 ...

04/09/23 © Robert Godin. Tous droits réservés. 51


2.3.10 Spécification de
contraintes
 Entre { }
 A proximité de l ’élément concerné
– après spécification d ’un attribut
– avant un ensemble d ’attributs
 Note reliée aux éléments
 Près d ’un trait pointillé
 Près d ’une flèche pointillée
 Syntaxe
– langue naturelle
– OCL (version 1.1 d ’UML)

04/09/23 © Robert Godin. Tous droits réservés. 52


2.3.11 Eléments dérivés
Utilisateur
{UNIQUE :idUtilisateur} Prêt
idUtilisateur
datePrêt
motPasse 1 *
/ nbPrêtsEnCours

{nbPrêtsEnCours = nombre de
PrêtEnCours
PrêtEnCours pour un Utilisateur}

Utilisateur

self.nbPrêtsEnCours = self.prêtEnCours -> size


04/09/23 © Robert Godin. Tous droits réservés. 53
2.4 Modèle entité-
association : ERD de Oracle
Designer

04/09/23 © Robert Godin. Tous droits réservés. 54


Notation des multiplicités

1..1
UML Classe A Classe B
0..*

Maximum plusieurs Minimum 0 (optionnel)

D esigner Entité A Entité B


(E R D )

04/09/23 © Robert Godin. Tous droits réservés. 55

Vous aimerez peut-être aussi