41
1 D'après G.Gardarin Méthodes de conception 1. Objectifs et principes 2. Rappels sur le modèle objet 3. Passage au modèle relationnel 4. Raffinement du schéma 5. Optimisation physique 6. Conclusion

Méthodes de conception

Embed Size (px)

DESCRIPTION

Méthodes de conception. 1. Objectifs et principes 2. Rappels sur le modèle objet 3. Passage au modèle relationnel 4. Raffinement du schéma 5. Optimisation physique 6. Conclusion. 1. Objectifs de la modélisation. Permettre Une bonne compréhension de systèmes réels très complexes. - PowerPoint PPT Presentation

Citation preview

Page 1: Méthodes de conception

1

D'après G.Gardarin

Méthodes de conception 1. Objectifs et principes 2. Rappels sur le modèle objet 3. Passage au modèle relationnel 4. Raffinement du schéma 5. Optimisation physique 6. Conclusion

Page 2: Méthodes de conception

2

D'après G.Gardarin

1. Objectifs de la modélisation Permettre

Une bonne compréhension de systèmes réels très complexes. La formulation abstraite des aspects cruciaux du problème.

Permettre une conception progressive Abstractions et raffinements successifs. Définition de méthodes de prototypage rapides. Découpage en modules ou vues. Génération des structures de données et de traitements.

Faciliter la visualisation du système Diagrammes avec des notations simples et précises. Compréhension visuelle et non seulement intellectuelle.

Page 3: Méthodes de conception

3

D'après G.Gardarin

Générations et méthodes Méthodes d'analyse et de décomposition hiérarchiques

1ère génération Diviser pour régner (le problème est décomposé en sous-problèmes) Warnier, SADT, Jackson, De Marco

Méthodes d'analyse et de représentation systémiques

2ième génération Séparation des données et traitements Merise, Axial, SSADM

Méthodes d'analyse et de conception orientées objet

3ième génération Réconciliation données et traitements. Réutilisation de composants logiciels.

Page 4: Méthodes de conception

4

D'après G.Gardarin

Objectifs des méthodes objet Réduction de la distance sémantique entre le langage des

utilisateurs et celui des concepteurs Amélioration de la communication entre utilisateurs et concepteurs. Abstraction du monde réel perçu en termes compréhensibles.

Regroupement de l'analyse des données et des traitements Meilleure compréhension des phénomènes. Meilleure cohérence entre les aspects statique et dynamique.

Simplification des transformations entre les niveaux conceptuel et interne

Implémentation directe éventuelle du schéma conceptuel. Établissement possible de règles de transformations automatisées.

Page 5: Méthodes de conception

5

D'après G.Gardarin

Principales méthodes objet OOD

G. Booch 1991 HOOD

HOOD Technical Group (B. Delatte, M. Heitz, J.F. Muller) 1993

OOAS. Shlaer & S. Mellor 1992

OOA/OODT. Coad & E. Yourdon 1991

OMTJ. Rumbaugh, M. Blaha, W. Premerlani, et. al.1991

OOSEI. Jacobson, M. Christerson, P. Jonson, G.Vergaard 1992

OOMM. Bouzeghoub, A. Rochfeld1994

FUSIOND. Coleman, P. Arnold, S. Bodoff, C. Dollin et. al. 1994

La notation UMLUniversel Modelisation Langage.Rationale et OMG.Une notation universelle.

Page 6: Méthodes de conception

6

D'après G.Gardarin

Les principaux modèles Le Modèle Objet (Object model)

Utilise les définitions des objets (données et opérations). Utilise la définition des associations entre objets.

Le Modèle dynamique (Dynamic model) Considère les états successifs des objets (cycle de vie). Réagit aux interactions temporelles et peut répondre à certains

stimulis.

Le Modèle fonctionnel (Functional model) Utilise les processus de transformation des objets. Gère des flots de données entre acteurs.

Page 7: Méthodes de conception

7

D'après G.Gardarin

Les cycles de réalisation d'une base Analyse (Analysis)

Étude du problème utilisateur. Génération de modèles de problèmes.

Conception (Design) Raffinement des modèles de problèmes. Génération de modèles d'implémentation (prototypes).

Implémentation (Implementation) Codage de modèles d'implémentation. Génération du code des programmes.

Page 8: Méthodes de conception

8

D'après G.Gardarin

2. Rappels sur le modèle Objet Objet (Object)

Concept, abstraction ou entité clairement distinguable.

Classe (Class) Description d'un groupe d'objets dotés de propriétés similaires.

Attribut (Attribute) Propriété nommée d'une classe représentée par une valeur dans

chaque instance.

Opération (Operation) Une fonction/transformation applicable aux objets d'une classe.

Méthode (Method) Une implémentation d'une opération dans une classe.

Page 9: Méthodes de conception

9

D'après G.Gardarin

Nom_classe

attributs

opérations

Voitures

NV: Int Type: String Marque: Constructeur Vitesse: Int Km : Int

Démarrer() Accélérer() Rouler(km:Int) Freiner()

Représentation UML (Universal Modelling Language)

La classe est une extension du concept d'entité dotée d'opérations.

Représentation d'entités

Page 10: Méthodes de conception

10

D'après G.Gardarin

Association Association (Association)

Une relation entre des instances de deux classes ou plus.

Lien (Link) Une instance d'association.

Rôle (Role) Une extrémité d'une association.

Attribut de lien (Link attribute) Un attribut de l'association instancié pour chaque lien.

Page 11: Méthodes de conception

11

D'après G.Gardarin

Représentation (UML) d'associations

Personne Voiture

Possède

Propriétaire Possédée

Date Prix

Buveurs Vins

Boire

DateQuantité

Abus Est_bu

Entité 1 Entité 2Association

Page 12: Méthodes de conception

12

D'après G.Gardarin

Cardinalités d'association (1/2) Cardinalité (Multiplicity)

Le nombre d'instances d'une classe associées à chaque instance de l'autre.

Cardinalité d'association Cardinalités minimale et maximale associées à chacun des rôles de

l'association, indiquant le nombre minimal et maximal d'instances d'association auxquelles participe une instance de l'entité du rôle.

Page 13: Méthodes de conception

13

D'après G.Gardarin

Cardinalités d'association (2/2)

1 (minimum et maximum)

plusieurs (0 à N)

0..1

*

optionnel (0 ou 1)

1..*obligatoire (1 ou plus)

ordonné (0 à N){ord}

3..5limité (de 3 à 5)

1

0..*

Page 14: Méthodes de conception

14

D'après G.Gardarin

Représentation d'associations en UML

Personne Voiture

Possède

Propriétaire Possédée

Date Prix

Buveurs Vins

Boire

Abus

DateQuantité

Abus Est_bu

Entité 1 Entité 2Association

1 *

* 1..*

Page 15: Méthodes de conception

15

D'après G.Gardarin

Poste-Travail

BureauBarre-Menus Corbeille

Outils-BureauDossiers

Sélectionner

NbreEléments

Ouvrir

Taille

Vider

Nom

Type

Ranger

* *

*

Agrégation : représentation UML de l'héritage

Agrégation (Aggregation) Forme spéciale d'association entre un tout et ses parties (part-of)

Page 16: Méthodes de conception

16

D'après G.Gardarin

Personnes

Employés Etudiants

Personnes

Employés Etudiants

Etudiants

Personnes

Employés Hommes Femmes

Généralisation Généralisation (Generalization)

Relation de factorisation permettant de regrouper les attributs et opérations communs de classes dérivées dans une classe mère.

Page 17: Méthodes de conception

17

D'après G.Gardarin

Module Un module (Module) est un groupe de classes apparentées

conçues ensemble. Un sous-système (Sub-system) est un groupe de modules. Ce concept permet de définir des vues et groupes de vues

d'une BD ou plus généralement d'une application.

Page 18: Méthodes de conception

18

D'après G.Gardarin

Conseils pratiques Bonne compréhension du problème à résoudre. Essayer de conserver un modèle simple. Bien choisir les identificateurs. Ne pas camoufler les pointeurs sous la forme d'attributs mais

utiliser les associations. Faire vérifier le modèle par d'autres pour un contrôle des

définitions communes des objets de l'entreprise. Documenter conventions et significations pour l'élaboration

ultérieure du dictionnaire des données.

Page 19: Méthodes de conception

19

D'après G.Gardarin

3. Passage au modèle relationnel Implémentations des attributs, généralisation, et associations

sous de forme de tables qui mémorisent les états des objets. Il n'est pas nécessaire d'avoir une BD objet.

Implémentation des méthodes sous forme de procédures stockées

L'état de l'objet est transmis en argument (clés), Les méthodes sont associées à une base de données.

C'est très important pour l'optimisation dans l'architecture client-serveur.

Page 20: Méthodes de conception

20

D'après G.Gardarin

Implémentation des associations Une association est représentée par une table dont le schéma est :

le nom de l'association, la liste des clés qui représente les classes participantes et les attributs de

l'association.

Exemple : POSSEDE (N° SS, N° VEH, DATE , PRIX ) BOIRE(NV, NB, CRU, MILLESIME, DEGRE)

Amélioration possible Regrouper les associations 1 n avec la classe cible.

Exemple : VOITURE (N°VEH, MARQUE, TYPE, PUISSANCE, COULEUR) POSSEDE (N° SS, N° VEH, DATE , PRIX ) regroupés si toute voiture a un et un seul propriétaire.

Page 21: Méthodes de conception

21

D'après G.Gardarin

C

C1 C2

C

C1

C2

K

K

K

(a)

C1

C2

C

C

C C1 C2

(b) (c)

Réduction des généralisations p 674 Aplatissage des hiérarchies

1 table par classe avec jointuresune seule table avec valeurs nullesune table par feuille

Réalisation de l'héritagestatique :

problème des valeurs nulles pour les objets sans descendants

dynamique :jointures sur clés, bien prévoir les indexes !

Page 22: Méthodes de conception

22

D'après G.Gardarin

Tabulation des collections Nombre maximum de valeurs connu

N attributs déclarés Manque de dynamicité Maximum souvent difficile à estimer Requêtes complexes Valable pour N < 5

Table des valeurs avec clé Passage en 1ière forme normale. Nécessité de jointure pour reconstituer la collection. Performance nécessitant un index.

Page 23: Méthodes de conception

23

D'après G.Gardarin

Exemple

Personnenssnom

prenomsdatenaisvieillir()dormir()

Employéfonctionsalaireprimes

travailler()

Buveurtypeétat

boire()

Vincru

millésimedegré

qualité

Appart.étage

norue

codeville

Supérieur

Inférieur Boire

Bu_par

Habite

Loge

Voiturenveh

couleurmarque

kmrouler()

Possède

Appartient

EmployéBuveur

Page 24: Méthodes de conception

24

D'après G.Gardarin

4. Raffinement du schéma Risques de mauvaise conception

classe trop importante ou classe trop petite.

Exemples : Propriétaire-de-véhicule (n° ss, nom, prénom, n° veh,  marque, type,

puissance, couleur, date, prix) Propriétaire-de-véhicule = personne |x| possède |x| voiture Cru (cru, qualité, degré) et Vin (nv, cru, millésime) Cru = (vins) et Vin = (vins)

Anomalies redondance de données, valeurs nulles, perte de sémantique.

Page 25: Méthodes de conception

25

D'après G.Gardarin

Dépendances fonctionnelles Définition

Soient R(A1, A2, … ,An) un schéma de relation, X et Y des sous-ensembles de {A1, A2, … ,An};

On dit que X Y (X détermine Y) ou encore que Y dépend fonctionnellement de X si et seulement si, pour toute extension r de R, il existe une fonction qui a partir de toute valeur de X détermine une valeur unique de Y.

Formellement r extension de R, tuples t1, t2 de r on a :

X(t1) = X(t2) Y(t1) = Y(t2)

Page 26: Méthodes de conception

26

D'après G.Gardarin

Exemples PERSONNE

N° SS NOM ? NOM N° SS ?

VOITURE (MARQUE, TYPE) PUISSANCE ? MARQUE PUISSANCE ? PUISSANCE TYPE ?

POSSEDE N° VEHP N° PROP ? N° PROP N° VEHP ? (N° VEHP, N° PROP) DATE ACHAT ?

Page 27: Méthodes de conception

27

D'après G.Gardarin

N° VEH

COULEUR

TYPE MARQUE

PUISSANCE

Graphe des dépendances

VOITURE (N°VEH, TYPE, COULEUR, MARQUE, PUISSANCE)

Page 28: Méthodes de conception

28

D'après G.Gardarin

CRU TYPE

TYPE, CLIENT REMISE

TYPE CLIENT REMISE

A A B

C1 C2 C1

3% 5% 4%

TYPE CLIENT REMISE

A A B

C1 C2 C1

3% 5% 4%

CRU

CHENASMEDOC

JULIENAS

Autre exemple

CRU

TYPE

CLIENT

REMISE

Page 29: Méthodes de conception

29

D'après G.Gardarin

Notion formelle de Clé Définition :

Un groupe d'attribut X est une clé du schéma de la relation

R (A1,A2, …, An) si et seulement si : 1) X A1 A2 … An

2) Il n'existe pas de sous-ensemble Y de X tel que Y A1 A2 … An

Plus simplement Une clé représente un ensemble minimum d'attributs qui détermine

tous les autres. Exemple : (n° veh) voiture ? (n° veh, type) voiture ?

Non unicité Il peut exister plusieurs clés pour une relation (clés candidates). Une clé doit alors être choisie comme clé primaire.

Page 30: Méthodes de conception

30

D'après G.Gardarin

Formes normales Objectifs

Définir des règles de décomposition des relations tout en préservant les Dépendances Fonctionnelles, sans perte d'informations,

pour représenter des objets et associations canoniques du monde réel (les molécules d'informations).

Éviter les anomalies de mises à jour. Éviter les réponses erronées.

Page 31: Méthodes de conception

31

D'après G.Gardarin

Une telle relation doit être décomposée en répétant les noms pour chaque profession (Opération UNNEST)

PERSONNE NOM PROFESSION

DUPONT Ingénieur, Professeur

MARTIN Géomètre

1ière forme normale Définition

Une relation est en 1ière forme normale si tout attribut contient une valeur atomique (unique).

Exemple

Page 32: Méthodes de conception

32

D'après G.Gardarin

R K1   K2 X Y

Une telle relation doit être décomposée en

R1(K1, K2, X) et R2(K2, Y)

2ième forme normale Définition

une relation est en 2ième forme normale si et seulement si : 1) elle est en 1ière forme normale. 2) tout attribut non clé ne dépend pas d'une partie de clé.

Schéma

Page 33: Méthodes de conception

33

D'après G.Gardarin

Exemple 2ième forme normale Exemple 1

Fournisseur (nom, adresse, article, prix) La clé est (nom, article) Mais nom adresse : la relation n'est pas en 2ième forme normale.

Exemple 2 R (cru, type, client, remise) La clé est (cru, client) Mais cru type : la relation n'est pas en 2ième forme normale.

Page 34: Méthodes de conception

34

D'après G.Gardarin

R K X Y Z

Une telle relation doit être décomposée en

R1(K, X, Y) et R2(X, Z)

3ième forme normale Définition

une relation est en 3ième forme normale si et seulement si : 1) elle est en 2ième forme normale. 2) tout attribut n'appartenant pas a une clé ne dépend pas d'un autre attribut

non clé.

Schéma

Page 35: Méthodes de conception

35

D'après G.Gardarin

Exemple : 3ième forme normale Exemple

Voiture (n° veh, marque, type, puissance, couleur) Type marque Type puissance Pas en 3ième forme.

Il est judicieux que les relations logiques soient en 3 ième forme normale ce qui garanti :

l'élimination des redondances, la non-perte d'information. la non-perte de dépendance.

La 3ième forme normale est la représentation canonique du monde réel !

Page 36: Méthodes de conception

36

D'après G.Gardarin

Exemples de décomposition Voiture (n° veh, marque, type, puissance, couleur)

Se décompose en : véhicule (n° veh, type, couleur) Modèle (type, marque, puissance)

Réduction (cru, type, client, remise) Se décompose en :

Remise (cru, client, remise) Type (cru, type)

Page 37: Méthodes de conception

37

D'après G.Gardarin

R K1      K2 X Y

Une telle relation peut être décomposée en

R1(K1, K2, X) et R2(Y, K1)

Une forme plus simple : la BCNF Définition

Une relation est en BCNF (Boyce-Codd Normal Form) si et seulement si les seules dépendances fonctionnelles élémentaires sont celles dans lesquelles une clé entière détermine un attribut.

Plus simple que 3NF, un peu plus fort.

Schéma

Page 38: Méthodes de conception

38

D'après G.Gardarin

5. Optimisation physique Le schéma logique n'est pas forcément implémenté.

Le regroupement de relations interrogées simultanément peut être parfois avantageux.

La dénormalisation évite des jointures coûteuses. Il est alors nécessaire de gérer la redondance lors de mises à jour.

Choix du placement indexe primaire plaçant = clé primaire hachage parfois avantageux (groupes de relations).

Choix des indexes contraintes référentielles, attributs de sélections fréquentes, indexes B-tree ou bitmap.

Page 39: Méthodes de conception

39

D'après G.Gardarin

Réglage des schémas Partitionnement de relations

horizontal supporter par certains SGBD, gestion d'indexe maître.

vertical découpage en plusieurs tables, attributs de jointures redondants.

Utilisation de données redondantes agrégats pré-calculés, jointures pré-calculées, vues concrètes.

Page 40: Méthodes de conception

40

D'après G.Gardarin

Résumé du réglage 1. Régler les requêtes en premier :

vérifier les plans d'exécution générés; reformuler les requêtes sans changer le schéma; pour éviter des sous requêtes inefficaces, régler l'usage des relations

temporaires intermédiaires; ...

2. Régler les dimensions des tables par partitionnement. 3. Régler les indexes et l'organisation des relations. 4. Considérer l'usage de données redondantes. 5. Revoir les décisions de normalisation. L'usage de vues permet de masquer ces réorganisations.

Page 41: Méthodes de conception

41

D'après G.Gardarin

6. Conclusion Intérêt de l'utilisation d'une méthode objet

proche du monde réel, la démarche sémantique est claire, Utilise les diagrammes UML standards.

Passage au relationnel automatique outils du commerce utilisables (Rationale Rose, etc.) supporteront les extensions objet-relationnel à venir.

Normalisation à l'exception utile quand sémantique confuse.

Optimisation et réglage une étape essentielle et permanente (suivi nécessaire).