|
Publicité ' | |||||||||||||||||||||||
|
|
#1 | |
|
Invité de passage
![]() Étudiant Inscription : août 2012 Messages : 16 ![]() |
Mesdames, messieurs, bonjour à toutes et tous.
Ayant déjà fait un poste assez détaillé concernant le sujet pour la conception d'un diagramme MCD, voici l’URL vers le poste en question : http://www.developpez.net/forums/d12...ulletin-notes/ Je réalise en plus de l'analyse Merise, une analyse UML et j'ai quelques questions sur l'utilisation des extends et des includes dans un cas d'utilisation. Voici l'énoncé du problème (Dans le cadre de la gestion d'un bulletin de note pour une plateforme de travail collaboratif) : Il existe 4 acteurs : - Le directeur de l'établissement scolaire - L'enseignant titulaire d'une classe - L'enseignant qui dispense un ou plusieurs cours - L'élève qui est évalué. Citation:
j'ai donc réalisé 3 versions du schéma : - Un pour lequel il n'y a aucun extends ou include - Un pour lequel j'ai mis des extends correspondant au fait que le cas d'utilisation n'existe que si le précédent existe - Un pour lequel il y a 2 cas d'utilisation pour la consultation du bulletin Pourriez-vous me dire ce que vous en pensez ? lequel parait le mieux et s'il est correcte ? Un grand merci d'avance. ![]() Leptitjej |
|
|
|
00
|
|
|
#2 |
|
Membre émérite
![]() ![]() Philippe BASTIANIArchitecte technique Inscription : juin 2005 Messages : 398 ![]() |
Bonjour,
Relis tes schémas... tu verras que tes extensions ne traduisent pas ta pensée... include = est nécessaire à l'exécution de l'UC extend = étend/enrichie le comportement de l'UC Ensuite, 2 UCs peuvent être dépendant sans pour autant y avoir un relation d'inclusion ou d'extension entre les deux ! Cdlt, Philippe |
|
|
00
|
|
|
#3 |
|
Invité de passage
![]() Étudiant Inscription : août 2012 Messages : 16 ![]() |
Bonjour, tout d'abord merci de répondre à mon poste ( surtout en période de fêtes)
Après relecture de la théorie, il semblerait que ce soit plutôt des "include" qui correspondent à mon idée. Cependant, la notion m'est tout de même floue. Ce que j’essaie de faire comprendre, c'est l'ordre chronologique dans lequel chaque UC sera utilisé. Cela à mon avis n'a pas besoin d'être exprimé dans un diagramme des UC. Si je suis mon raisonnement, il n'y aura donc aucune relation entre les UC.Ou alors je dois créer un UC plus général qui inclura un UC spécifique ? |
|
|
00
|
|
|
#4 |
|
Membre émérite
![]() ![]() Philippe BASTIANIArchitecte technique Inscription : juin 2005 Messages : 398 ![]() |
Tu as une approche chronologique/algorithmique, et ce n'est pas ce qui t'est demandé... La phrase importante de ton enoncé est "le bulletin sera donc actualisé à chaque période d'évaluation"... et, au final tu n'as besoin que d'un ou 2 UCs pour exprimer la vie du bulletin et tes différents acteurs vont intervenir au cours de l'exécution ! Et, d'un UC pour la simple visualisation. La chronologie tu pourras l'exprimer dans la description de ton UC...
Ici, tu adoptes une vision centrée sur le bulletin... mais, tu peux aussi élargir ton système car après tout si ton bulletin à une vie c'est surrement qu'au cours de l'année des évenements interviennent sur la vie scolaire... A toi, d'avoir/d'exprimer ta propre visoin du système! a+ Philippe |
|
|
00
|
|
|
#5 |
|
Invité de passage
![]() Étudiant Inscription : août 2012 Messages : 16 ![]() |
Ok donc si je ne m’intéresse aux UC par période d'évaluation alors en effet le diagramme est sensiblement plus léger.
Mais ma question alors : Quid des actions qui ne sont effectuées qu'une seule fois (ou rarement) ? - La création d'une structure de bulletin : Il y aura une interaction entre le directeur et le système (Claroline). Ce dernier spécifie un type de bulletin selon différents paramètres. Le type en question est enregistré dans le système pour être par la suite "instancié" lorsqu'une année scolaire commence et que ce type est utilisé pour une/plusieurs classes de l'établissement scolaire Dois-je l'omettre dans le diagramme mais le spécifier dans la description du UC "Insérer note" par exemple ? Ayant eu droit à très peu de cas pratique sur l'UML je dois avouer que c'est assez galère |
|
|
00
|
|
|
#6 |
|
Invité de passage
![]() Étudiant Inscription : août 2012 Messages : 16 ![]() |
Voici une nouvelle version sur laquelle j'ai travaillé
Qu'en pensez-vous par rapport aux précédentes ? Merci
|
|
|
00
|
|
|
#7 |
|
Membre émérite
![]() ![]() Philippe BASTIANIArchitecte technique Inscription : juin 2005 Messages : 398 ![]() |
D'un point de vue graphique tu as mis des généralisations/specialisations et non pas des extensions... est-ce ton idée ?
Mais soit... partons sur des extends : dans ton schéma tu exprimes: 'gerer note bulletin' peut être complété par 'insérer note', (idem pour 'modifier' ou supprimer')... il n'y a pas quelque chose qui cloche dans cette/ces assertions ? Celà veut dire quoi ? C'est quoi le comportement de gérer sans les 3 options ? Même remarque pour ton autre UC... Partons sur des spécialisations : 'créer', 'modifier', 'supprimer' sont des spécialisations de 'gérer'... pourquoi pas ! mais est-ce utile ? que t'apporte l'UC 'gerer' ? Au passage tu as perdu la validation... ils ne vont jamais avoir de diplome tes étudiants Bonne réflexion, Philippe |
|
|
00
|
|
|
#8 |
|
Invité de passage
![]() Étudiant Inscription : août 2012 Messages : 16 ![]() |
En effet, il semble qu'utiliser des UC "généraux" n'ait pas de sens après votre commentaire. Il n'y à rien à faire, il m'est difficile de savoir quelles actions doivent être considérées comme UC.
Voici une version assez simple selon moi, comprenant la création du bulletin (sa structure), ainsi que la gestion des notes et la consultation de celles-ci En espérant que cela soit mieux. Je dois commencer à avancer sur le projet donc il ne faut pas que je perdre trop de temps |
|
|
00
|
|
|
#9 |
|
Invité régulier
![]() Inscription : mai 2007 Messages : 31 ![]() |
Bonsoir,
un cas d'utilisation est une fonctionnalités attendu par un acteur du système. Ici dans ton exercice, le dernier schéma que tu donnes est plus satisfaisant que ce que tu donnais au début. De toute façon, le "cahier des charges" est light. Il mériterait beaucoup de précisions (c'est ce qui rend ce diagramme si attrayant je trouve). Cela va donc se traduire par des UC simples. Ta dernière version est donc simples mais elle colle plutôt à ce qu'il faut. Cela mériterait malgré tout des précisions. Kalkul |
|
|
00
|
|
|
#10 | ||
|
Invité de passage
![]() Étudiant Inscription : août 2012 Messages : 16 ![]() |
Bonsoir,
j'ai réfléchi aux actions effectuées par les acteurs dans l'ordre chronologique et voici dans un premier temps ce que j'ai pu en retirer (pour les scénarii de chaque cas d'utilisation) : Citation:
Cela signifie qu'il y a donc 4 cas d'utilisation et 3 acteurs : Citation:
|
||
|
|
00
|
Copyright © 2000-2013 - www.developpez.com