Discussion :

[jojo410]

Bonjour,

Novice en conception, serait-il possible de profiter de vos lumières pour me guider dans la conception de mon MCD .

Un organisme est chargé d’organiser des examens pour certifier des experts métiers. Voici une partie des règles de gestion proposées:
- Un examen est composé de questions
- Lors de la création d’un examen, un examen de secours est créé
- Un examen est organisé en deux parties indépendantes en fonction du type de connaissance (I ou II)
- A chaque type de connaissance est associé un certain nombre de thèmes
- Une question est constituée de différentes propriétés: Intitulé, réponses possibles, la position de la réponse, commentaire, l’état de validation (T/F), date de la (in)validation, le (in)validateur, date d’éligibilité d’une question à un examen, l’état d’éligibilité (T/F), la date de dernière utilisation d’une question à un examen, le nombre de fois qu’une question a été utilisée lors d’un examen
- Une question peut avoir une question parent
- Une question est issue d’un texte réglementaire
- Une question appartient à un thème qui lui-même appartient à un sous-thème
- Un opérateur valide une question
- Un opérateur autorise un créateur à créer des questions
- Un candidat participe à un examen
- Lors d’un examen, toutes les réponses du candidat sont stockées. Une bonne réponse donne un point, une mauvaise zéro. Une note globale est calculée mais pas stockée.

Voici ma première ébauche de MCD avec de nombreuses interrogations sur l'utilisation d'une agrégation (EXAMEN-QUESTION-REPONSE), de l'héritage entre les différents utilsiateurs (OPERATEUR, CREATEUR, CANDIDAT), sur le fait que les propriétés NbUtilisation et DateUtilisation soient portées par l'association COMPOSER...

MCDpartI-v1.pdf


Merci d'avance,

jojo

[gototog]

- pourquoi ne pas sortir de l'entite question, une entité reponse en lien relatif?

Question 0.n -----Avoir réponse--------(1,1) Réponse

Une question (id:1) aurai donc un nombre variant de réponse (par exemple ici 4)
dont les id sont donc 1,1; 1,2; 1,3; 1,4 .

Reponse aurai la propriété isTrue (booléen).


Ducoup l'utilisateur est relié a toute les réponse qu'il a effectué, on peut via de simple traitements trouver le nombre de point a la question, ou a l'examen, ou a l'ensemble de tous ces examens, bref, no limit :p

- Un opérateur autorise un créateur à créer des questions

N'est pas représenté.
Peut etre en faisant une association Opérateur 0.n---autoriser---1,1 Utilisateur (sachant que cet utilisateur devient ducoup créateur)


- l'héritage me semble bien

[jojo410]

Bonjour

merci gototog pour tes remarques .

Voici quelques réactions:
- Si j'ai bien compris pour une question donnée j'aurai une réponse donnée associée, et il me faudra comparer lors d'un traitement entre la propriété "checkthéorique" (position attendue de la réponse à la question) et "checkréponse" (position de la réponse du candidat) pour déterminer si le point est True ou False ?

Ma crainte était de ne plus pouvoir faire de statistiques sur les questions d'un examen en fonction de la catégorie (du thème ou du sous-thème) mais j'ai l'impression que ta proposition permet de faire encore cela car à partir d'un candidat je pourrais connaître les réponses répondus, les questions associées aux réponses et avec la table d'association composer récupérer les spécifications des questions (catégorie, thème, sous-thème).
Je vais être ajouter une association "Passer examen" entre candidat et examen pour me simplifier la vie sur certains traitements ?

- concernant l'association "un opérateur autorise un créateur", en fait je pense qu'il faudrait directement la mettre entre operateur 0,n -----autoriser-----1,1 createur, est-ce que cela est possible bien que l'entité opérateur n'a pas de propriétés ?

Merci d'avance,

jojo

[JPhi33]

Bonjour,

- Lors de la création d’un examen, un examen de secours est créé

On distingue deux types d'examens : le normal et le secours. La création du secours semble être obligatoire --> on devrait donc avoir la cardinalité 1,1 des deux côtés de l'association "A pour secours". A la limite, on pourrait concevoir qu'un examen normal n'ait pas de secours (1,1 d'un côté et 0,1 de l'autre) mais il est impossible qu'un examen de secours ne soit pas rattaché à un examen normal (car dans ce cas, il serait secours de rien).

- Une question est constituée de différentes propriétés: Intitulé, réponses possibles, la position de la réponse, commentaire, l’état de validation (T/F), date de la (in)validation, le (in)validateur, date d’éligibilité d’une question à un examen, l’état d’éligibilité (T/F), la date de dernière utilisation d’une question à un examen, le nombre de fois qu’une question a été utilisée lors d’un examen

Je rejoins gototog à propos de l'entité Réponse. Que se passe-t-il si une question a 6 réponses possibles alors que 5 seulement sont prévues ?

[gototog]

Hum, si je peux me permettre, un examen de secours n'a pas d'examen de secours, donc c'est bien du 0.1 de mon point de vue.

jojo, essaye de refaire un modèle avec nos remarques, tu t’apercevras d'anomalies que tu pourras corriger toi même ou venir nous demander conseil!

[jojo410]

Bonjour,

J'ai débuté mon MCD sous powerAMC dont voici un aperçu.

Concernant l'aspect du nombre de réponses possibles à une question: il s'agit d'un QCM donc ce nombre est fixé à 4 ou 5 selon la question, mais jamais au delà.

Concernant l'examen de secours et sur la base de vos derniers commentaires, je dirais qu'un examen "a pour secours" 1,1 examen; et qu'un examen 'est le secours" de 0,1 examen ...par contre au niveau MLD ça fait un truc bizarre.

Via PowerAMC, je ne suis pas arrivé à modéliser mon héritage entre mes entités user, candidat, ... et l'association que j'aimerai mettre entre operateur et createur.

merci pour vos remarques,

jojo

[JPhi33]

Hum, si je peux me permettre, un examen de secours n'a pas d'examen de secours, donc c'est bien du 0.1 de mon point de vue.

Je me permets d'insister. Une occurrence de l'entité Examen est soit un examen "normal" soit un examen de secours.

- Si c'est un examen normal, d'après la règle de gestion, il a obligatoirement un examen de secours ---> cardinalité 1,1
- Si c'est un examen de secours, il est obligatoirement secours d'un examen normal ---> cardinalité 1,1

En conclusion : cardinalité 1,1 des deux côtés. Il ne faut pas se laisser abuser par le nom de l'association "a pour secours" qui est plutôt mal choisi.


Voici une petite astuce pour s'en sortir avec les associations réflexives : il faut modéliser au brouillon un MCD séparant les deux types d'occurrences et tout s'éclaire.

[ Examen_normal ]--1,1--a_secours--( est_lié )--est_secours--1,1--[ Examen_secours ]

"a_secours" (ou "a pour secours") est en réalité le rôle joué par l'occurrence dans l'association réflexive.


Une fois les concepts définis grâce au brouillon, on modélise l'association réflexive normalisée :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
    +--( est_lié )--+
    |               |
a_secours      est_secours
    |               |
   1,1             1,1
    |               |
    +--[ EXAMEN ]---+

[jojo410]

Bonjour,

merci JPhi33 pour cette explication très claire.

Je pense avoir quasiment terminé mon modèle (voir piéce attachée). L'héritage semble fonctionner et l'association "autoriser" entre les deux sous-types OPERATEUR et CREATEUR également.

J'y ai ajouté une relation "certifier" entre EXAMEN et CANDIDAT pour lister facilement quels examens un candidat a passé et ainsi connaître si il l'a réussi et dans ce cas sa note finale.

merci pour vos commentaires,

jojo

[gototog]

Prend en compte nos remarques sur les réponses.

De toute façon, ton utilisateur est lié a ton entité réponse puisque tu les dois enregistrer. Donc autant la construire correctement !

Après il va falloir modifier deux trois choses.
Par exemple, actuellement, ton candidat est bien lié a un examen, très bien, mais il ne peut le passer qu'une fois! la date est en propriété, il fois qu'elle passe en identifiante pour gérer ca.
Pour t'illustrer, actuellement si je passe le concours deux fois ca donnerai

examenFrancais, Gototog: 13/05/10, 08/20, false
examenFrancais, Gototog: 13/05/11, 16/20, true

On s'appercoit très bien que pour la futur base de donnée, les deux passages différents ont le meme identifiant.

Par contre, ceci est plus juste:
examenFrancais, Gototog, 13/05/10: 08/20, false
examenFrancais, Gototog, 13/05/11: 16/20, true

Les identifiants sont bien différents.


De la meme manière, sortir la date de l'association Composer pour la passer en identifiant. (association qu'on pourra modifier une fois que les autres modifs auront été faite )



Dernière chose, par convention, l'héritage ne se note pas comme tu l'as fait. la mère a un seul trait, arrivant sur ta balise X. de cette balise doit sortir tes trois traits arrivant aux filles.
exemple ici http://www.fsmwarden.com/developpez/...ritage_MCD.jpg


Voila, j'espère avoir réussi a m'faire comprendre :p

[jojo410]

Bonjour,

encore merci pour vos réponses et de votre patience.

1) "réponse":
Une remarque concernant la gestion des réponses car je ne comprends pas le besoin de gérer le réponses selon la proposition de gototog.

Dans l'énoncé, il est dit "Une question est constituée de différentes propriétés: Intitulé, réponses possibles, la position de la réponse ...".
Si j'interprète cette phrase, je dirais qu'une question a un intitulé, plusieurs propositions de réponses (de 4 à 5, jamais au delà en fait après vérification) et une seule réponse possible qui est connue (de l'administrateur) par la position "théorique" de la réponse.
=> il n'y aura qu'une seule réponse possible à chaque question, la postion de cette réponse est connue.

Donc, je me demande si il ne vaut pas mieux gérer cela avec une association "répondre":
Question 0,n----REPONDRE----0,n Candidat
l'association REPONDRE serait porteuse des propriétés "PositionReponseCandidat" et de "Point (1 ou 0 selon l'adéquation avec la position théorique)".


et ainsi obtenir le résultat suivant dans la table d'association:
idQ(pi,fi); idC(pi, fi); PositionReponseCandidat; Point
premiérequestion; toto; 2; 0
deuxièmequestion; toto; 3; 1
...

Je peux alors pour un candidat connaître toutes ses réponses aux questions appartenant à un examen et faire des statistiques plus ou moins avancées en jouant sur la catégorie, le thème, les sous-thèmes, etc. des questions.


2) Ok pour l'ajout de la date en identifiant (j'ai pas fait gaffe aux conséquences de la cardinalité 0,n !).

3) pour l'héritage OK, je change cela.

4) pour passer la "dateUtilisation" de COMPOSER en identifiant, je ne vois pas très bien.
Je pensais en fait passer cette propriété dans l'entité Question afin de connaître, en prenant une question au hasard, la dernière date d'utilisation de la question.
Cette "dateUtilisation" serait par exemple modifiée lorsqu'une question est utilisée dans un examen (en imaginant une propriété "dateexamen" par exemple dans l'entité Examen ...).

merci pour vos commentaires,

Le nouveau MCD suivra dans les prochaines heures.

jojo

[gototog]

Reponse
reponse, estjuste ,
(Question1, 1) , false
(Question1, 2) , true
(Question1, 3) , false
(Question1, 4) , false

Le candidat répond a une question: (association répondre)

candidat,Reponse, date
John, (Question1, 4 ), 2008/04/05
John,( Question2, 1 ), 2008/04/05
John,( Question1, 3 ), 2011/04/05
John,( Question2, 1 ), 2011/04/05
Paul, (Question1, 4 ), 2011/04/05

J'ai mi la date si un candidat peut répondre a la même question a deux date différente par un plus grand des hasards.

Si tu veux vraiment laisser les reponse1_reponse2 etc... dans ton entité question, mettre l'association répondre que tu a proposé est pertinent.

Est ce que tu aurai fait une entité a 40 propriétés si il fallait mémoriser 40 réponses possibles a la question?


Pour le 4)
Composer me titille un peu
Acutellement:
Composer:
Examen-Categorie-questionDate, NbUtilisation

Donc:
Examen1-Francais-question1, 2010/05/08, 150
Examen1-Francais-question2, 2010/05/08, 150
Examen1-Francais-question3, 2010/05/08, 150
Examen1-Francais-question4, 2010/05/08, 150
Examen1-Francais-question5, 2010/05/08, 150

Examen1-Francais-question1, 2005/05/08, 150 a le meme identifiant que le premier?
A moins que chaque examen soit unique ?

[jojo410]

Bonjour,

merci gototog de rester actif sur le sujet.

Point 1) Réponse
Merci pour ton explication c'est plus clair pour moi.
Effectivement, si il avait eu 40 réponses possible je les aurais sorties de l'entité question pour les gérer comme tu le proposes (via une entité dédiée).

Point 4) Composer
Humm, depuis le début, je m'interroge sur l'emplacement de ces deux propriétés en me demandant si elles ne seraient pas mieux dans l'entité Question. Cela serait alors peut être plus facile d'accéder à ces propriétés en questionnant directement la future table Question en SQL. Je pense que l'on se moque ici de savoir dans quel examen exactement la question a été la dernière fois utilisée.
Oui l'examen est unique.

Merci,

jojo

[gototog]

Effectivement, si il avait eu 40 réponses possible je les aurais sorties de l'entité question pour les gérer comme tu le proposes (via une entité dédiée).

Gardes toujours en tête les soucis de fiabilité et d'évolutivité de ton modèle



Pour la date, il te faut cette info dans la table examen.
Par traitement, tu pourras chercher tous les examens des questions et choisir le plus ancien ou le plus récent.

Pour le nombre d'utilisation de la question, met le plutôt dans l'entité question. toutes les questions d'un exam seront utilisé le même nombre de fois, pas besoin de le mettre dans l'association composer. c'est une donnée qui dépend de rien d'autre, qui leur est propre.

Après je peux me tromper, je suis qu'un étudiant en Licence pro , mais j'ai toujours adoré l'analyse x)