Corrige du be6?

Corrigé du BE6–7
Équipe enseignante
Revision : 1510
CSC 4002
Télécom SudParis
Octobre 2015
Corrigé du BE6–7
1
Corrigé-type
1.1
Analyse du texte
Les classes et — attributs — obtenus après analyse du texte sont les suivants :
• Équipage — — la classe équipage sert à regrouper l’ensemble des membres d’équipage (pilote, copilote
et PNC) qui participent à un vol (à une date donnée) ;
• Avion — — un avion appartient à une catégorie donnée, il participe à plusieurs vols ;
• Pilote — — un membre d’équipage qui a pour métier pilote ;
• Copilote — — un membre d’équipage qui a pour métier copilote ;
• PNC — — un membre d’équipage qui a pour métier PNC ;
• MembreÉquipage — nom, prénom — ;
• CatégorieAvion — nom, nbPNCmin, nbPNCmax — un membre d’équipage ne peut voler que sur deux
catégories d’avion. Plusieurs avions peuvent appartenir à la même catégorie, d’où la nécessité de créer
une classe CatégorieAvion ;
• Vol — numéro, site, destination, date — un vol est une classe entre un avion et un ensemble de membres
d’équipage. Un vol se déroule à une date donnée.
Remarque : Nous faisons la distinction entre les classes Pilote et Copilote car ce sont des métiers différents
dans les équipages et nous souhaitons éviter qu’un équipage ne comprenne que des pilotes ou que des copilotes.
Erreurs fréquemment observées :
• confondre acteur du cas d’utilisation avec classe du système (administrateur et manager se retrouvent
par erreur en classes) ;
• oublier de mettre la catégorie d’avion comme classe du système. En effet, comment alors préciser qu’un
membre d’équipage peut voler sur deux catégories d’avion ?
• oublier de mettre l’avion comme classe du système. En effet, comment vérifier qu’une instance d’avion
n’est pas affectée sur deux vols simultanément ?
Variantes possibles :
• la classe Équipage peut être omise. Le diagramme de classes est à modifier en conséquence ;
• une classe Aéroport peut être ajoutée avec les associations a pour origine et a pour destination. Le
diagramme de classes est à modifier en conséquence.
Barème :
• sur 2 points :
–
–
–
–
1.2
0.5
0.5
0.5
0.5
classe Vol,
3 attributs de la classe Vol,
classe Avion,
classe CatégorieAvion.
Diagramme de cas d’utilisation
La figure suivante présente les acteurs et les cas d’utilisation du système.
Télécom SudParis — Équipe enseignante — Octobre 2015 — CSC 4002
2
Corrigé du BE6–7
ajouter un membre d’équipage
supprimer un membre d’équipage
créer un vol
Administrateur
du système
supprimer un vol
créer une catégorie d’avion
supprimer une catégorie d’avion
créer un avion
Manager
supprimer un avion
affecter un membre d’équipage à un vol
retirer un membre d’équipage d’un vol
afficher les données d’un vol
afficher mes vols
Membre d’équipage
Erreurs fréquemment observées :
• ne pas respecter les notations du diagramme de cas d’utilisation,
• oublier un acteur,
• ne pas détailler les entités à créer et à supprimer.
Variantes possibles :
• introduire une généralisation spécialisation entre acteurs (même si au niveau métier cela n’a pas de
sens).
Barème :
• sur 3 points :
–
–
–
–
0.5 respect des notations UML (il faut les 4 : bonhomme, trait, système et oval),
0.5 trouver 3 acteurs (0 si seulement deux acteurs),
0.5 affecter les cas d’utilisation aux bons acteurs,
0.5 cas d’utilisation pour « ajout et suppression d’entités dans le système » (pas bon si on ne peut
pas créer d’avion ou de vol, pas bon si entité non détaillée),
– 0.5 cas d’utilisation « affecter un membre d’équipage à un vol »,
– 0.5 cas d’utilisation « visualiser mes vols ».
1.3
Diagramme de classes
Les figures suivantes présentent les diagrammes de classes proposés, en version simple (sans utilisation des
concepts avancés des classes) et complète (utilisant les concepts avancés du diagramme de classes).
Télécom SudParis — Équipe enseignante — Octobre 2015 — CSC 4002
3
Corrigé du BE6–7
TableauNavigants
Avion
1
*possède
*
*
1
CatégorieAvion
est assuré avec
0..2
peut voler sur
*
*
Vol
*
MembreÉquipage
*
*
*
1
Équipage
est assuré par
*
Pilote
PNC
0..1
0..1
Copilote
*
*
a pour co−pilote
a pour PNC
0..*
a pour pilote
TableauNavigants
Avion
1
*possède
*
1
0
1
0
1
0
1
0
*
1
CatégorieAvion
est assuré avec
peut voler sur
0..2
*
*
Vol
*
MembreÉquipage
*
*
*
1
Équipage
est assuré par
*
Pilote
0..1
PNC
0..*
Copilote
0..1
*
*
a pour co−pilote
a pour PNC
a pour pilote
Télécom SudParis — Équipe enseignante — Octobre 2015 — CSC 4002
4
Corrigé du BE6–7
Erreurs fréquemment observées :
• B747 et A320 ne peuvent pas être des classes. En effet, il faudrait alors changer le modèle UML à
chaque fois qu’une nouvelle catégorie d’avion sort sur le marché ;
• appeler Équipage la classe MembreÉquipage. C’est une erreur de français, mais qui peut porter à conséquence : on oubliera alors la multiplicité « * » ;
• Administrateur et Manager ne sont pas des classes, ce sont des acteurs extérieurs au système ;
• oublier d’avoir une classe d’accès aux différents éléments du système (patron de conception Façade, qui
est représenté par la classe TableauNavigants sur le corrigé).
Barème :
• sur 5 points :
–
–
–
–
–
–
–
0.5 nom des associations (3 minimum),
1.0 multiplicité (2 oublis tolérés),
1.0 généralisation spécialisation (présence d’une généralisation spécialisation et notation correcte),
0.5 agrégation,
0.5 point d’entrée au système avec le patron « Façade »,
0.5 association « Avion — CatégorieAvion »,
0.5 association « MembreÉquipage — CatégorieAvion » (ou vers « Avion » pour ceux qui ont
mélangé « CatégorieAvion » et « Avion ») avec multiplicité « 2 »,
– 0.5 association « Avion — Vol ».
Variantes possibles :
• pas de classe Équipage, mais trois associations depuis la classe Vol vers les membres d’équipage.
1.4
Diagramme de machine à états
La figure suivante présente le diagramme de machine à états de la classe Vol.
[durée archive>1an]
entry:destructeur()
PeutVoler
ajout:
ajouterMembre()
[nbPNC>=nbmin
&& pilote != null
&& copilote != null]
te
bu
l
vo
qu
é
id
lé
nu
n
la
vo
Archivé
vol qui débute
suppression:
supprimerMembre()
[tailleÉquipage=nbmax]
EnDestruction
|| copilote == null]
Équipage
[pilote = null || copilote = null]
ajout:
ajouterMembre()
suppression:
supprimerMembre()
vol annulé
entry:
constructeur()
[nbPNC<nbmin
|| pilote == null
[tailleÉquipage<nbmax]
ÉquipageEn
Construction
EnCréation
Équipage
AuComplet
suppression:
supprimerMembre()
entry:archiver()
vol annulé
Erreurs fréquemment observées :
• avoir un état qui ne peut jamais aller vers l’état final,
Télécom SudParis — Équipe enseignante — Octobre 2015 — CSC 4002
5
Corrigé du BE6–7
•
•
•
•
se tromper de classe,
ne pas faire apparaître d’état Archivé,
ne pas faire apparaître les actions (qui découlent pourtant du diagramme de cas d’utilisation),
ajout possible de PNC mais sans retrait possible.
Barème :
• sur 3 points :
– 0.5 états initial et final,
– 1 flèches de passage d’un état à un autre cohérentes permettant d’aller de l’état initial à l’état
final,
– 0.5 événements de passage d’un état à un autre,
– 0.5 état Archivé,
– 0.5 ajout et suppression de membres d’équipage.
1.5
Conception des classes
Dans le diagramme de classes avancé, voici les attributs correspondant aux associations de la classe Vol :
− avion : @Avion
− équipage : @Équipage
Erreurs fréquemment observées :
• pas fait,
• non conforme au diagramme de classes,
• collection pour traduire une multiplicité « * » qui n’existe pas.
Variantes possibles :
− avion : @Avion
− équipage : collection @MembreÉquipage
Barème :
• sur 3 points :
–
–
–
–
1.6
0.5 visibilité privé,
0.5 « @ » pour référence sur,
1 attribut d’association vers Avion,
1 attribut d’association vers Équipage (ou 3 associations si pas de classe Équipage)
Diagramme de communications ou de séquence
La figure suivante présente le diagramme de communications associé au cas d’utilisation « affecter un PNC
à un vol ».
Télécom SudParis — Équipe enseignante — Octobre 2015 — CSC 4002
6
Corrigé du BE6–7
3:pv=peutVolerSur(ca):booléen[!complet]
pnc:MembreEquipage
affecterPNCVol(pnc,vol)
:TableauNavigants
:Avion
1.1.1:max=getNBMaxPNC():int
1.1:max=getNBMaxPNC():int
2.1:ca=getCatégorieAvion()
:CatégorieAvion
1:complet=équipageAuComplet():booléen
2:ca=getCatégorieAvion():CatégorieAvion[!complet]
4:addPNC(pnc)[!complet && pv]
5:auComplet=équipageAuComplet()[!complet && pv]
ca:CatégorieAvion
vol:Vol
1.2:nb=getNBPNC():int
4.1:addPNC(pnc)
:Équipage
Erreurs fréquemment observées :
• sur les diagrammes de communications : erreur dans la numérotation des messages,
• sur les diagrammes de séquence : erreur dans l’ordre temporel des messages,
• oubli de classes participant à la collaboration.
Variantes possibles :
• présenter le diagramme de séquences,
• pas de classe Équipage, directement la classe PNC.
Barème :
• sur 4 points :
– 0.5 notation UML des objets participants (« : » et soulignés),
– 0.5 présence des objets nécessaires au fonctionnement de la séquence ou des communications (un
oubli toléré),
– 0.5 ordre des messages (diagramme de séquence) ou numéro de séquence (diagramme de communications),
– 1.0 interactions pour connaître la taille max équipage et taille actuelle (au moins 3 interactions),
– 0.5 interactions pour vérifier que le PNC peut voler sur la catégorie d’avion,
– 0.5 interaction pour ajouter le PNC à l’équipage,
– 0.5 paramètres sur les appels d’opérations.
Télécom SudParis — Équipe enseignante — Octobre 2015 — CSC 4002
7