Transparents(PowerPoint

(1)

2 Processus de conception de BD

Planification

Analyse

Conception

Spécification des besoins

Modèle conceptuel

Construction

Modèle physique

Mise en oeuvre

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

Pourquoi ?

Quoi ?

Comment ?

(2)

Processus de développement

 Cycle de vie en cascade

 Cycle de vie itératif

 ...

(3)

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

(4)

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

(5)

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

(6)

Diagramme de contexte de SyLeRat

GérerPrêts Membre

SystèmeAcquisition ProduireRapportActivités

InclureAcquisitions

Bibliothécaire

Administrateur Système GererSystème

Commis au prêt

Consulter

(7)

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.

(8)

2.1Analyse : modèle

conceptuel de données

 Modèle conceptuel de données : représentation graphique

abstraite des informations à placer dans la base de données qui est

indépendante de la technologie

utilisée pour l’implémentation

(9)

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)

(10)

2.3 Diagrammes de classes UML

Personne nom : String prénom : String

Membre

télépho neRésidence : String nbMaxPrêts : Integer = 5 duréeMaxPrêts : Integer = 7

PrêtEnCours PrêtArchivé

dateRetour : Date

{dateRetour >= datePrêt}

{statut = "prêté" ssi PrêtEnCours de

l'Exemplaire est non vide}

{Le nombre de PrêtEnCours d'un Membre <= nbMaxPrêts}

Employé {UNIQUE : codeMatricule}

codeMatricule : String

catégorieEmployé : enum(bibliothécaire, commis) catégorieUtilisateur

Catégorie {UNIQUE: code}

code : String

* enfant

* Auteur

Editeur {UNIQUE: nomEditeur}

nomEditeur : String ville : String

Livre {UNIQUE: ISBN}

ISBN : String titre : String

ann éeParution : Type Do nnéesAge 1 **

1 1..*

1..* 1..*

1..*

1

1..*

1

1..*

Exemplaire {UNIQUE: idExemplaire}

idExemplaire : String dateAchat : Date

statut : enum(prêté, disponible, retiré)

1 1..*1..*

1 Prêt datePrêt : Date

1

*

1

* Utili sateur

{UNIQUE :idUtilisateur}

idUtilisateur : String

motPasse : String 11 **

{ordonné}

{Il ne peut y avoir plus d'un PrêtEnCours pour un même Exemplaire}

{disjointe, complète}

{di sjoin te, comp lète}

{chevauchante, complète}

(11)

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

(12)

Représentation d ’un objet en UML

u n L i v r e I S B N : S t r i n g = 0 - 2 0 1 - 5 7 1 6 8 - 4

t it r e : S t r in g = T h e U n if ie d M o d e li n g L a n g u a g e U s e r G u i d e a n n é e P a r u t i o n : I n t e g e r = 1 9 9 9

u n A u t r e L i v r e I S B N : S t r in g = 0 - 2 0 1 - 3 0 9 9 8 - X

t i t r e : S t r in g = T h e U n i f i e d M o d e lin g L a n g u a g e R e f e r e n c e M a n u a l a n n é e P a r u t io n : I n t e g e r = 1 9 9 9

u n E d i t e u r

n o m E d i t e u r : S t r i n g = A d d is o n W e s le y v ill e : S t r in g = R e a d in g , M A

u n A u t e u r n o m : S t r i n g = B o o c h p r é n o m : S t r i n g = G r a d y

u n A u t r e A u t e u r n o m : S t r in g = R u m b a u g h p r é n o m : S t r in g = J a m e s

(13)

Classe

 Abstraction

 Caractéristiques communes à un ensemble d'objets

– attributs

– associations

– opérations

(14)

Représentation d ’une classe en UML

L i v r e

I S B N : S t r in g t i t r e : S t r i n g

a n n é e P a r u t io n : I n t e g e r

E d i t e u r

n o m E d i t e u r : S t r in g v il le : S t r in g

A u t e u r

n o m : S t r in g

p r é n o m : S t r i n g

(15)

 Intention (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 ?

(16)

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

(17)

Stéréotype UML

Livre ISBN : String

titre : String

annéeParution : Integer

<<entity>>

(18)

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

(19)

Pas besoin d ’identificateur explicite !

 Par opposition au relationnel

: P r ê t

d a t e P r ê t : d a t e = 1 0 / 1 0 / 2 0 0 0

: P r ê t

d a t e P r ê t : d a t e = 1 0 / 1 0 / 2 0 0 0 O I D = 1 5 4 3 9 6 O I D = 2 0 4 3 9 5

(20)

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

{ U N I Q U E : i d M e m b r e ,

U N I Q U E : n o m , p r é n o m } id M e m b r e

n o m p r é n o m

M e m b r e

(21)

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*

(22)

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 stéréotypée «datatype»

 ~domaine en modélisation conceptuelle

(23)

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 :$)

(24)

2.3.2 Notion de lien et d'association binaire

u n L i v r e : L i v r e

I S B N : S t r in g = 0 - 2 0 1 - 5 7 1 6 8 - 4

t i t r e : S t r in g = T h e U n if ie d M o d e li n g L a n g u a g e U s e r G u i d e a n n é e P a r u t i o n : I n t e g e r = 1 9 9 9

u n A u t r e L i v r e : L i v r e

I S B N : S t r in g = 0 - 2 0 1 - 3 0 9 9 8 - X

t i t r e : S t r in g = T h e U n if ie d M o d e li n g L a n g u a g e R e f e r e n c e M a n u a l a n n é e P a r u t i o n : I n t e g e r = 1 9 9 9

u n E d i t e u r : E d i t e u r

n o m E d it e u r : S t r in g = A d d is o n W e s le y v il le : S t r in g = R e a d in g , M A

u n A u t e u r : A u t e u r

n o m : S t r in g = B o o c h p r é n o m : S t r in g = G r a d y

u n A u t r e A u t e u r : A u t e u r

n o m : S t r in g = R u m b a u g h p r é n o m : S t r in g = J a m e s E d i t e

E d i t e

R é d i g e

R é d ig e R é d i g e

R é d ig e

L i v r e I S B N : S t r in g t i t r e : S t r i n g

a n n é e P a r u t io n : I n t e g e r E d i t e u r

n o m E d i t e u r : S t r in g v ill e : S t r in g

A u t e u r n o m : S t r i n g p r é n o m : S t r in g 1 . . *

1 E d i t e >

1 . . *

< R é d i g e

Lien

Association

(25)

Rôles et multiplicités

 Nom de rôle

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

n u m é r o d a t e h e u r e

P a r t i e

n o m v ill e

E q u ip e r e c e v e u r

v is it e u r

0 . . * 0 . . *

1 1

p a r t i e l o c a le

p a r t i e à l'é t r a n g e r

numéro

Partie

nom

Equipe receveur

0..* 1

1

< Est receveur pour partie locale

(26)

Association réflexive

Personne nom

prénom

dateNaissance sexe

* 2

enfant

*

parent

2

(27)

Contraintes pré-définies pour les associations

 Ordonné (ordered)

 Modifiable (changeable)

 InsertionSeulement (addOnly)

 Fixe (frozen)

 Exclusives

– entre deux associations

L i v r e I S B N : S t r i n g t i t r e : S t r in g

a n n é e P a r u t io n : I n t e g e r

A u t e u r n o m : S t r i n g p r é n o m : S t r in g 1 . . *

1 . . *

< R é d i g e

{ o r d o n n é }

(28)

2.3.3 Agrégation

 Cas particulier d ’association

Moteur Châssis Porte Pneu

Auto

0..1 1

0..1

2,4 0..1

4 0..1

1 2,4 0..1 1

0..1

(29)

Composition

TableDesMatières

Chapitre

Bibliographie

Index Livre

1 1

1

1 1

1..*

1

1..*

1

1 1

1

Glossaire 1

0..1 1

0..1 tableDesMatières

chapitres

bibliographie index

glossaire

Livre

tableDesMatières : TableDesMatières chapitres[1..*] : Chapitre

bibliographie : Bibliographie

(30)

2.3.4 Associations qualifiées

 Partition des objets associés

Groupe

nb_maximum_inscrits Cours

sigle titre

nb_crédits 0..1

numéro session

1 0..1

1 numéro session

Groupe numéro

session

nb_maximum_inscrits Cours

sigle titre

nb_crédits 1 1 0..* 0..*

Contrainte d ’identification locale

{UNIQUE : Cours, numéro, session}

(31)

2.3.5 Classes associatives

 Données spécifiques à

l ’association _Cours

sigle titre Etudiant

nom

prénom * * * *

NoteObtenue note

session

Incorrect si plusieurs notes

pour un Etudiant et un Cours

(32)

Réification de l ’association

 Plusieurs notes pour un Etudiant et un Cours

Etudiant nom

prénom

NoteObtenue note

session

* 1

Cours sigle titre

*

1 *

1

(33)

Autre solution : classe

associative + agrégation

Cours sigle titre Etudiant

nom

prénom * * * *

NotesObtenues

Note note

1 * 1

*

(34)

Solution avec classe Groupe

NoteObtenue note

Etudiant nom

prénom

Cours sigle titre Groupe

nb_maximum_inscrits

*

* *

*

numéro session 1

0..1 1

numéro session 0..1

Créer un objet session ?

(35)

2.3.6 La généralisation/

spécialisation

Personne nom

prénom adresse

téléphoneRésidence

Etudiant codePermanent Employé

codeMatricule téléphoneBureau

Etudiant nom

prénom adresse

téléphoneRésidence Employé

nom prénom adresse

Propriétés communes : classe plus générale

Héritage

(36)

Notation multi-segments

Personne nom

prénom adresse

téléphoneRésidence

Etudiant

codePermanent Employé

codeMatricule

téléphoneBureau

(37)

Mise en facteur par délégation ?

Employé codeMatricule

Etudiant codePermanent Personne

nom prénom adresse

téléphoneRésidence 1

0..1

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

1 1

(38)

Discriminant

Employé {UNIQUE : codeMatricule}

codeMatricule : String

catégorieEmployé : enum(bibliothécaire, commis)

Membre

téléphoneRésidence : String nbMaxPrêts : Integer = 5 duréeMaxPrêts : Integer = 7 Utilisateur

{UNIQUE :idUtilisateur}

idUtilisateur : String motPasse : String catégorieUtilisateur

(39)

2.3.6.1 Contraintes pré-définies pour la généralisation

Personne nom

prénom adresse

téléphoneRésidence

Etudiant

{UNIQUE: codePermanent}

codePermanent Employé

{UNIQUE: codeMatricule}

codeMatricule

{complète, chevauchante}

Italique pour nom de classe abstraite

Complète /incomplète

Disjointe/chevauchante

(40)

Notation alternative par une note UML

Personne nom

prénom adresse

téléphoneRésidence

Etudiant

{UNIQUE: codePermanent}

codePermanent Employé

{UNIQUE: codeMatricule}

codeMatricule téléphoneBureau

{chevauchante, complète}

(41)

2.3.7 Héritage multiple

Personne nom

prénom adresse

Etudiant

{UNIQUE: codePermanent}

codePermanent Employé

{UNIQUE: codeMatricule}

(42)

2.3.7.1 Multi-classification et héritage multiple

Personne nom

prénom adresse

Etudiant

{UNIQUE: codePermanent}

codePermanent Employé

Enseignant

Cadre Soutien

catégorieEmployé

EtudiantPremierCycle EtudiantGradué {disjointe, complète}

{disjointe, complète} catégorieEtudiant

(43)

Sous-classes de jointure?

Personne nom

prénom adresse

Etudiant {UNIQUE: codePermanent}

codePermanent Employé

Enseignant département Cadre

mur

Soutien fonction catégorieEmployé

EtudiantPremierCycle EtudiantGradué sujetRecherche {disjointe, complète}

{disjointe, complète} catégorieEtudiant

CadreEtudiantPremierCycle SoutienEtudiantPremierCycle EnseignantEtudiantPremierCycle CadreEtudiantGradué SoutienEtudiantGradué EnseignantEtudiantGradué

(44)

Modélisation par rôle

En sei gnant département Cadre

mur

Soutien fonction catég orie Empl oyé

EtudiantPremierCycl e Etudi antGradué

sujetRecherche {disjoi nte, complète}

{disj oi nte, complète } catégori eEtudiant

Employé {UNIQUE: codeMatricule}

cod eMatricul e télé phoneBureau

Person ne nom

prénom adresse

téléph oneRésidence

0..1 1

Etudi ant {UNIQUE: codePermanen t}

codePermanent 0..1

1 1 0..1

1

rô leEmployé 0..1 rôlele Etudi ant

(45)

2.3.8 Attribut de classe

Souligner l ’attribut (UML 1.1)

Membre

téléphoneRésidence nbMaxPrêts = 5

duréeMaxPrêts = 7

(46)

2.3.9 Opérations

 Signature d'une opération

–

nom et type des paramètres

Employé codeMatricule : String nom : String prénom : String getCodeMatricule() : String salaire () : Real

Cadre prime : Real setPrime(p : Real)

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

salaireAnnuel : Real setSalaireAnnuel(s : Real) salaire() : Real

(47)

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)

(48)

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

(49)

Interface

 Opérations publiques visibles

 Définition d ’une interface de classe

– classe stéréotypée

(50)

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

(51)

Catégories d ’opérations

 Constructeur

 Modifieur

 Lecteur

 ...

(52)

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)

(53)

2.3.11 Eléments dérivés

Prêt datePrêt Utilisateur

{UNIQUE :idUtilisateur}

idUtilisateur motPasse

/ nbPrêtsEnCours

1 *

PrêtEnCours {nbPrêtsEnCours = nombre de

PrêtEnCours pour un Utilisateur}

Utilisateur

(54)

2.4 Modèle entité-association :

ERD de Oracle Designer

(55)

Notation des multiplicités

C l a s s e A C l a s s e B

0 . . *

1 . . 1

E n t i t é A E n t i t é B

M a x im u m p lu s ie u r s

U M L

D e s i g n e r ( E R D )

M in im u m 0 ( o p t io n n e l )