Discussion :

[karimot]

Bonjour tout le monde j'ai un exercice ( Realiser le MCD et le MLD) sans corrigé et je voudrais quelqu'un qui me donne juste les fautes que j'ai commis .... ( avec une correction )

... l’ex c'est un gros texte j'ai essayé de tirer l'entité et cardinatlité afin d'avoir le MCD

Entité :

Architecte : matricule architecte , nom , prénom , fonction , date embauche

Dessinateur : matricule dessinateur , nom , prénom , fonction , date embauche

Personnel administratif : matricule , nom , prénom , fonction , date embauche

Client ou maître d'ouvrage : référence , Nom , Adresse , Numéro de téléphone

Projet : Numéro de référence , Date de dépôt , date de remise prévisionnelle , un type ( maison , immeuble ..) , Adresse , une superficie total et bâtie ,
type de travaux envisager ( construction ou emménagement) , Rémunération
Cardinalité :
Une seul Architecte peuvent intervenir dans la realisation du projet
Plusieurs dessinteurs peuvent intervenir dans la realisation du projet
le personnel administration du cabinet intervient dans le projet au niveau de la constitution du dossier auprés les autorités sous les directives de l'architecte autorités sous les directives de l'architecte consideré comme chef des projet
A la remise du projet la date de fin effective de sa realisation est enregistré

les dernieres phrases en gras .... j'ai pas compris .....
Voilà mon travail et merci de le corriger avec des explications merci pour vos efforts .....
Corrigé.pdf dans le cas ou vous voulez pas telecharger le pdf voilà en directe l'image .... de ma proposition

Merci de m'aider et bonne journnée
Voilà l'exercice en detail ... sous forme image

J'ai fait des grands efforts pour poster tou ca esperant que vous aller m'aider ....
Ps : je voudrais une methode ou un logiciel qui facilite l'ecriture de ce modele ... au lieu de taper sur word

[fsmrel]

Bonsoir karimot,


1) Dans votre MCD vous avez défini un type d’entité CABINET : cela n’aurait de sens que si l’énoncé était le suivant :

« Vous êtes appelé à concevoir un système de gestion ayant pour objet la réalisation de projets architecturaux par des cabinets d’architecture... »

Auquel cas il faudrait savoir à quel cabinet appartient tel architecte, tel dessinateur, tel projet, etc., il faudrait donc identifier ces cabinets pour les distinguer les uns des autres. Comme en réalité il n’y a qu’un cabinet, il n’y a pas d’ambiguïté : on ne modélise pas de type d’entité CABINET (le cabinet lui-même représente le micro-monde, l’univers à modéliser, on l’appelle donc « univers du discours »).


2) Vous aurez remarqué que les architectes et les autres collaborateurs ont les mêmes propriétés : matricule, nom, prénom, etc. :



Au fond, tous ces profils de collaborateurs se ressemblent singulièrement : on peut utiliser le mécanisme de la généralisation pour factoriser leurs propriétés communes. Conceptuellement, on représente ainsi les choses (j’utilise ici l’AGL PowerAMC) :



La généralisation est symbolisée par une demi-lune et le « X » qui y est inscrit symbolise l’exclusion des rôles (on ne peut pas être à la fois architecte et dessinateur, etc.)

Cette fois-ci, les types d’entité ARCHITECTE, DESSINATEUR et ADMINISTRATIF sont comme des coquilles vides : en réalité, les attributs ne sont pas perdus, ils sont hérités du nouveau type d’entité COLLABORATEUR, lequel joue le rôle de surtype, les trois autres jouant pas contraste le rôle de sous-type. Quoi qu’il en soit, il est quand même plus simple de gérer les collaborateurs en une fois plutôt qu’en tripler la gestion. Mais si un type de collaborateur a des propriétés que n’ont pas les autres (par exemple une prime spéciale qui ne concerne que les architectes, la marque de compas des dessinateurs), les sous-types sont là pour héberger ces propriétés spécifiques :




3) Concernant la fonction des collaborateurs : du fait des sous-types, on sait déjà si un collaborateur est un architecte, un dessinateur ou un administratif, auquel cas si précision plus fine il faut apporter, cela ne vaut que pour les administratifs :




4) Cas des clients :

Étant donné que le type d’entité CABINET a été désintégré, il en va de même pour la relation ENREGISTRER connectant CABINET et CLIENT.


5) Cas des projets :

A votre avis, comment arrivez-vous avec votre MCD à savoir pour quel client est réalisé tel projet ? Il est évidemment nécessaire d’établir la connexion entre CLIENT et PROJET :



Notez la cardinalité 1,1 portée par la patte connectant PROJET et COMMANDER : cela veut dire qu'un projet participe une seule fois à l’association COMMANDER (sous-entendu un projet est commandé par un et un seul client). En revanche, la patte connectant CLIENT et COMMANDER est porteuse d’une cardinalité 0,N : un client peut participer un nombre quelconque de fois à l’association COMMANDER (un client peut passer commande de plusieurs projets).

Par ailleurs, une fois terminé le projet, on enregistre la date de fin de réalisation qui n’est pas connue à l’avance puisque le cabinet n’a pas de boule de cristal. On peut donc avoir des projets en cours et des projets terminés, et pour les distinguer, tout comme on a généralisé les types de collaborateurs, on peut spécialiser les projets pour mettre en évidence ceux qui sont achevés :



Par ailleurs, dès que vous lisez « type de » dans l’énoncé qui vous a été remis, il est bon de prévoir un type d’entité ad-hoc : Type de travaux envisagés, type de bâtiment :




6) Direction de projet :

Ce sont les architectes qui dirigent les projets et cela doit être mis en évidence, c’est ce que vous avez fait, mais en plaçant les cardinalités à l’envers. Faisons comme Dagobert :




En complétant le puzzle :




Remarques

a) Quand vous aurez digéré tout ça, il faudra que vous vous intéressiez aux identifiants alternatifs. En effet, il y a plus de 25 ans, l’excellentissime Yves Tabourier à écrit ceci (De l’autre côté de MERISE, page 80), et c’est une règle d’or :

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

Par exemple, l’attribut ProjetReference utilisé pour identifier le type d’entité PROJET est vraisemblablement significatif, porteur d’information (défini par un utilisateur non au fait de la modélisation) et devrait être ravalé au rang d’identifiant alternatif (continuant donc à garantir l’unicité des codes des projets), au bénéfice d'un attribut artificiel, sans signification (et caché à l’utilisateur), appelons-le ProjetId, utilisé fondamentalement pour identifier les projets et servir de référence dans le cadre des relations avec les autres types d’entités du modèle.

b) Par ailleurs, n’hésitez à vous plonger dans la lecture de l’ouvrage de Michel Diviné Parlez-vous Merise ?, gratuit et téléchargeable (merci Michel !)


Posez vos questions sur ce qui continue à vous échapper. On pourra aussi voir le MLD si vous le souhaitez.


Bon courage...

[karimot]

Bonjour ... !! voilà la suite et j'ai des problèmes sous forme des commentaires merci de répondre ... et je suis désolé je suis un débutant ....

et vous n'etes pas obliger de me repondre dans le coté logiciel ce que je voudrais juste le modele car on fai pas ca sur l'ordinateur mais sur papier
Merci Merci !!

[fsmrel]

Bonsoir karimot,


Avez-vous utilisé PowerAMC ? PowerDesigner ? Un autre outil ? Quelle version ? Prenez l’habitude de préciser le contexte dans lequel vous travaillez.


A propos des fonctions des administratifs

Je répète ce que j’ai déjà écrit... Concernant la fonction des collaborateurs : du fait des sous-types, on sait déjà si un collaborateur est un architecte, un dessinateur ou un administratif, auquel cas si précision plus fine il faut apporter, cela ne vaut que pour les administratifs.

Dans le cas des administratifs, on peut en effet être amené à savoir si une personne est secrétaire, assistant, comptable, etc.

Si vous estimez que ce degré de finesse est inutile, ne modélisez pas le type d’entité-type FONCTION.


Citation :

Il est possible de procéder ainsi, mais c’est très lourd. C’est comme si en arithmétique vous vous passiez de la multiplication et au lieu d’écrire :

2 X 10

Vous écriviez :

2 + 2 + 2 + 2 + 2 + 2 + 2 + 2 + 2 + 2.

Citation :


Le trait sont vous parlez est le délimiteur de pages. Dans le cas PowerAMC, voyez le guide en ligne Préférences d'affichage générales, où il est écrit qu’il suffit de décocher la case correspondante.


Citation :


Avec ma version antique de l'outil, je passe par Outils > Préférence d’affichage > Référence : je décoche ce que je ne veux pas afficher (rôle, nom de contrainte, etc.) Vous devez avoir l’équivalent.


La notation que vous utilisez pour ce qui ressemble à un MLD est bizarre et de toute façon tout est faux en ce qui concerne les identifiants : commencez par proposer un MCD, on verra ensuite le MLD, ou de préférence le MPD généré directement du MCD.