Bonsoir,
Je redonde avec certaines remarques faites par f-leb et CinePhil, mais tant pis, j’envoie.
Envoyé par
hegros
Voilà quelques règles d'or pour moi
hegros, vous prenez vos responsabilités et c’est bien. Mais il m'arrive d'être en désaccord avec vous.
Envoyé par
hegros
-Ne jamais fournir un MCD sans les règles de gestion et un dictionnaire de données
Exact. Ces éléments doivent faire partie du Dossier de Conception Détaillé (DCD), lequel doit faire l’objet d’une revue serrée, à laquelle participent le directeur de projet, ses collaborateurs concernés et les représentants de la Maîtrise d’Oeuvre, voire de la Maîtrise d’Ouvrage. Et comme au fil du temps les règles évolueront, ce dossier devra être maintenu, sinon il perdra de son crédit et restera confiné au fond d‘une armoire.
Envoyé par
hegros
-Modélisez en couvrant l'aspect offre, tarification et tiers
Vous faires sans doute référence à un univers du discours particulier. Si l’univers que je modélise est celui de la philosophie, des pathologies, du cosmos ou des Schtroumfs, je ne vois pas le rapport.
Envoyé par
hegros
-Ne pas mettre de clé primaire auto-incrémenté comme #id_voiture pour une entité voiture
Le concept de clé primaire est du niveau MLD et n’a donc pas à être mentionné dans le Dossier de Conception Détaillé. En revanche, celui-ci fait mention des identifiants des entités-types, car le concept d’identifiant est du niveau MCD. En passant, je rappelle à nouveau ce qu’a écrit l’excellentissime Yves Tabourier (De l’autre côté de MERISE page 81), et ça c’est une règle d’or, qui a plus de vingt ans :
« ... la fonction d’une propriété est de décrire les objets (et les rencontres), alors que l’identifiant ne décrit rien. Son rôle fondamental est d’être sûr de distinguer deux jumeaux parfaits, malgré des descriptions identiques.
L’expérience montre d’ailleurs que l’usage des “identifiants significatifs” (ou “codes significatifs”) a pu provoquer des dégâts tellement coûteux que la sagesse est d’éviter avec le plus grand soin de construire des identifiants décrivant les objets ou, pis encore, leurs liens avec d’autres objets... »
Autrement dit, identifier une entité-type telle qu’un véhicule automobile par un numéro d’immatriculation ou autres informations portées sur une carte grise est à éviter. De la même façon identifier une entreprise par son numéro Siren est à prohiber dans un MCD. En effet, quand l’INSEE procède à une modification, ça peut être extrêmement pénalisant. A ce sujet voyez la discussion avec KristofNancy. Dans cette discussion, je me situe aux deux niveaux, MCD (je parle des identifiants) et MLD (je parle des clés), mais ce que j’ai écrit rejoint totalement ce qu’a écrit Y. Tabourier. En l’occurrence, comme dit mon ami Chris Date : Better prevent than cure...
Envoyé par
hegros
-Évitez les relations ternaires et plus, ramenez toujours à une relation binaire
Il est vrai que certaines ternaires et plus ne se justifient pas. J’extrais cette image d’une discussion au cours de laquelle le toujours serviable CinePhil a pris en charge vivicente (qui débute) pour lui montrer comment ramener ces n-aires à des binaires :
Mais :
Considérons les règles de gestion suivantes :
— Tel de nos ingénieurs a pu mettre en œuvre tel ou tel SGBD chez tel ou tel de nos clients ;
— Tel client a pu avoir besoin des services de tel et tel de nos ingénieurs pour mettre en œuvre tel et tel SGBD ;
— Etc.
Par exemple :
L’ingénieur Albert a mis en œuvre SQL Server et DB2 chez Dubicobit. Il a aussi mis en œuvre Oracle, Sybase et DB2 chez Yadupour.
L’ingénieur Bernard a mis en œuvre DB2 et IMS chez Dubicobit. Il a aussi mis en œuvre IDMS et Sybase chez Yaudpoil.
Le MCD correspondant est le suivant :
Mathématiquement parlant, la ternaire n’est pas réductible à des binaires (on démontre en effet qu’elle est en sixième forme normale). Je rappelle encore qu’une association-type correspond à un prédicat, en l’occurrence :
L’ingénieur x met en œuvre le SGBD y chez le client z
Ou à la façon ramassée des logiciens :
x met en œuvre y chez z
Et de façon encore plus ramassée :
Fxyz
Ceci ne date pas d’aujourd’hui, voyez G. Frege, le père de la logique moderne. Dans sa théorie générale de la quantification (voyez Methods of Logic), le Professeur Willard V.O. Quine (un des plus grands philosophes américains du XXe siècle) prend comme exemple le terme triadique « Gxyz » qui pourra signifier « x donne y à z ». Quine présente aussi le terme triadique « Hxyzw » qui pourra signifier « x paye y à z pour w ». Et Quine n’a aucunement l’intention (et pour cause !) de ramener un prédicat triadique ou tétradique à des prédicats dyadiques.
Pour en revenir au MCD, Y. Tabourier traite longuement des ternaires avec l’exemple (bien connu des cercles merisiens) des personnes qui garent des voitures dans des bâtiments, en notant qu’il est des cas où la décomposition est impossible.
Envoyé par
hegros
Prendre en compte uniquement la partie maximum pour les cardinalités
Que nenni ! Une cardinalité minimale 0 exprime que la participation d’une entité à une association est facultative alors qu’une cardinalité minimale 1 exprime que la participation d’une entité à une association est obligatoire. Ne pas en tenir compte serait comme confondre la quantification existentielle et la quantification universelle (dire que « Tous les hommes sont mortels » ou « Quelques hommes sont mortels », c’est équivalent). D’un point de vue conceptuel ça serait affaiblir, dénaturer les règles de gestion correspondantes. Tiens, voilà une règle d’or :
le MCD ne doit pas engendrer une dénaturation des règles de gestion des données.
Envoyé par
hegros
-Respectez les formes normales
Certainement. Toutefois, ce travail de vérification doit être poursuivi au niveau du MLD, car certaines dépendances fonctionnelles et clés candidates (identifiants candidats au niveau conceptuel) ne sont pas directement dérivables du MCD, elles sont inaccessibles parce que cachées par définition au sein des associations-types. A cette occasion, je rappelle que la deuxième forme normale, la troisième forme normale et la forme normale de Boyce-Codd mettent exclusivement en jeu dépendances fonctionnelles et clés candidates (voire surclés, mais je ne voudrais pas sortir du périmètre).
Envoyé par
hegros
Par rapport au lien entre la conception et l'implémentation il y a un risque de prendre en considération trop tôt la technique dans le modèle. Je préférerais dans ce cas avoir 2 modèles bien distincts car ces considérations pour moi interviennent plus tard dans le MPD ou MLD
Tout dépend du sens que vous donnez au mot « technique ». S’il s’agit de l’auto-incrémentation des clés, des index, du partitionnement et autres éléments du niveau physique, vous avez parfaitement raison. Pour le reste, il faudrait que vous apportiez des précisions.
Cela dit, si votre MCD comporte mille entités-types, il doit être urbanisé en domaines, sous-domaines, sous-sous-domaines, de telle sorte que chaque vue correspondante tienne sur une page au format A3. A ce niveau, pour que l’utilisateur arrive à suive, il est préférable ne pas montrer les attributs (y compris les identifiants). Pour le reste : identification relative, agrégation, composition, héritage, et toutes ces sortes de raffinements, l’utilisateur non informaticien comprend vite ces techniques fort utiles, qui facilitent en fait la lecture des MCD et des diagrammes de classes UML. Quant à gérer deux MCD, tout dépend de leur taille et du temps dont vous disposez pour les réaliser (et les maintenir).
Envoyé par
hegros
Modèle conceptuel qui prends en considération la technique pour l'optimisation
Qu’entendez-vous par optimisation ?
Envoyé par
hegros
Pourquoi ? Tout simplement parce que vous ne savez pas qui va le lire. Un modèle qui prends en compte la technique va forcément être plus difficilement lisible par un fonctionnel et un modèle l'ignorant risque de ne pas être pertinent pour un technicien. Tandis que le modèle épuré de la technique fonctionnel et technicien y trouve leur compte aussi ils peuvent plus facilement communiquer
Je suis désolé, mais lors des séances de validation fonctionnelle d’un MCD, doivent être présents le chef de projet et/ou le concepteur (qui connaissent tous deux parfaitement le dossier), ainsi que l’équipe fonctionnelle de la Maîtrise d’Oeuvre qui, je le répète, comprend en général très vite le dossier et ce qui a été modélisé (sauf si le MCD ressemble à une toile d’araignée ou à un chef-d’œuvre d’art contemporain). A défaut, en l’absence de séances de relecture en commun, je ne donne pas cher du projet.
Quant aux techniciens (les équipes de développement et les DBA qui leurs sont affectés), ils comprennent aussi très vite, et là encore le chef de projet et/ou le concepteur sont dans l’obligation de leur faire faire une visite guidée et approfondie du MCD.
Tiens, voilà une règle d’or : Le MCD doit être crédible et clair, au point que la MOE et les équipes de développement décident d’afficher au mur les vues qui les concernent, plutôt que de s’en servir comme de ballons de basket, la poubelle jouant le rôle de panier.
Partager