Méthodes de conception

1. 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

2. 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.

3. 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.

4. 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.

5. OOD G. Booch 1991 HOOD HOOD Technical Group (B. Delatte, M. Heitz, J.F. Muller) 1993 OOA S. Shlaer & S. Mellor 1992 OOA/OOD T. Coad & E. Yourdon 1991 OMT J. Rumbaugh, M. Blaha, W. Premerlani, et. al. 1991 OOSE I. Jacobson, M. Christerson, P. Jonson, G.Vergaard 1992 OOM M. Bouzeghoub, A. Rochfeld 1994 FUSION D. Coleman, P. Arnold, S. Bodoff, C. Dollin et. al. 1994 La notation UML Universel Modelisation Langage. Rationale et OMG. Une notation universelle. Principales méthodes objet

6. 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.

7. 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.

8. 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.

9. Voitures NV: Int Type: String Marque: Constructeur Vitesse: Int Km : Int Nom_classe attributs opérations 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

10. 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.

11. Représentation (UML) d'associations Entité 2 Entité 1 Association Personne Voiture Possède Propriétaire Possédée Date Prix Vins Buveurs Boire Est_bu Abus Date Quantité

12. 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.

13. Cardinalités d'association (2/2) 1 1 (minimum et maximum) * plusieurs (0 à N) 0..1 optionnel (0 ou 1) 1..* obligatoire (1 ou plus) 0..* ordonné (0 à N) {ord} 3..5 limité (de 3 à 5)

14. Représentation d'associations en UML Entité 2 Entité 1 Association Personne Voiture Possède Propriétaire Possédée * 1 Date Prix Vins Buveurs 1..* * Boire Est_bu Abus Abus Date Quantité

15. 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) Poste-Travail Type Bureau Corbeille Barre-Menus Taille Vider Sélectionner Ranger * * Dossiers Outils-Bureau * NbreEléments Nom Ouvrir

16. Personnes Personnes Etudiants Employés Etudiants Employés Personnes Femmes Hommes Employés Etudiants 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.

17. 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.

18. 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.

19. 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.

20. 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.

21. p 674 Aplatissage des hiérarchies 1 table par classe avec jointures une seule table avec valeurs nulles une table par feuille Réalisation de l'héritage statique : problème des valeurs nulles pour les objets sans descendants dynamique : jointures sur clés, bien prévoir les indexes ! Réduction des généralisations C C1 C2 K C K C1 C C1 C C1 C2 C2 K C2 C (c) (b) (a)

22. 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.

23. Voiture nveh couleur marque km rouler() Exemple Habite Appartient Appart. étage no rue code ville Personne nss nom prenoms datenais vieillir() dormir() Loge Possède Boire Inférieur Vin cru millésime degré qualité Buveur type état boire() Employé fonction salaire primes travailler() Bu_par Supérieur EmployéBuveur

24. 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.

25. 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)

26. 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 ?

27. Graphe des dépendances VOITURE (N°VEH, TYPE, COULEUR, MARQUE, PUISSANCE)

28. CRU TYPE TYPE CLIENT CLIENT REMISE REMISE CHENAS A A C1 C1 3% 3% MEDOC A A C2 C2 5% 5% B B C1 C1 4% 4% JULIENAS Autre exemple CRU TYPE CLIENT CRU  TYPE TYPE, CLIENT  REMISE REMISE

29. 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.

30. 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.

31. 1ière forme normale • Définition • Une relation est en 1ière forme normale si tout attribut contient une valeur atomique (unique). • Exemple PERSONNE NOM PROFESSION DUPONT Ingénieur, Professeur MARTIN Géomètre Une telle relation doit être décomposée en répétant les noms pour chaque profession (Opération UNNEST)

32. 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 R K1   K2 X Y Une telle relation doit être décomposée en R1(K1, K2, X) et R2(K2, Y)

33. 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.

34. 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 R K X Y Z Une telle relation doit être décomposée en R1(K, X, Y) et R2(X, Z)

35. 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 3iè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 !

36. 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)

37. 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 R K1      K2 X Y Une telle relation peut être décomposée en R1(K1, K2, X) et R2(Y, K1)

38. 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.

39. 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.

40. 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.

41. 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).