Diagramme de séquences version 1

Ce scénario montre une bonne répartition des responsabilités. Les classes qui créent les différents objets sont celles qui leurs sont liés par une relation d'association

Avantages :

pas de relation de dépendance supplémentaire
très peu de circulation d'objet dans les paramètres des méthodes
le couplage entre classes est réduit aux associations

Inconvénients.

le point de passage pour la création d'un participant est le Catalogue, ce qui peut apparaître formel.

Diagramme de séquences version 2.

Avantages

moins de messages envoyé
c'est l'organisme qui crée le participant

Inconvénients.

couplage plus fort entre classes, ajout de dépendances
passages d'objet dans les méthodes
la méthode getSession doit devenir publique

Voici ce que donnerait le daigramme de classe :

Correction

Question 1 :

Commentaires :

- les rôles des classes dans les associations correspondent aux noms des attributs des classes réalisant les associations

- le losange noir indique une composition entre la classe Formation et la classe Session. En effet une formation est « composée » de sessions et la suppression d’une formation entraînera la disparition de ses sessions

- la contrainte {ordonné} sur l’association indique que les choix sont triés par ordre de préférence

- la non-présence de flèche dans une association indique que la navigabilité n’est pas restreinte. Ceci est justifié par la présence dans la classe Participant de l’attribut laSession et dans la classe Session par la présence de l’attribut lesParticipants.

Question 2 :

Procédure Participant::init(unNom, unPrénom : chaîne, uneAncienneté : entier, desChoix : Collection de Session)

Variables :

index : entier

Début

nomßunNom

prénomß unPrénom

mesChoix ß desChoix

laSession ß mesChoix.donnerObjet(1) // valorisation par défaut

FinProcédure

Remarque : l’opérateur d’affectation n’étant pas fourni explicitement par la classe Collection, on a procédé à une affectation élément par élément

Procédure Participant ::getChoixSession( index : entier ) : Session

retourne lesChoix.donnerObjet(index)

FinFonction

procédure Session ::ajouteParticipant (unParticipant : Participant)

lesParticipants.ajoute(unParticipant)

finProcédure

fonction Session ::estPleine() : booléen

retourne lesParticipants.cardinal() = nbMax

finFonction

procédure Formation ::affecteParticipants()

variables :

numChoix, i , nbInscrits: entier

sessionRetenue : Session

unInscrit : Participant

début

lesInscrits.trier(« ancienneté »,’d’) // on trie sur l’ancienneté afin de satisfaire les demandes selon ce //critère

nbInscrits ß lesInscrits.cardinal()

pour iß1 jqa nbInscrits

unInscritßlesInscrits.donnerObjet(i)

numChoixß1

sessionRetenue ß unInscrit.getChoixSession(numChoix)

tant sessionRetenue.estPleine()

numChoix ++

sessionRetenue ß unInscrit.getChoixSession(numChoix)

fin tant que

unInscrit.setLaSession(sessionRetenue) // réalise le lien entre le participant et sa session //définitive, attribut Partcipant :: laSession

sessionRetenue.ajouteParticipant(unInscrit) // ajoute le nouvel inscrit à la collection Session :: //lesParticipants

fin pour

fin procédure

Remarque : dans tous les cas, la priorité d’affectation revient à l’ancienneté, il suffit donc de satisfaire les participants par ordre d’ancienneté en vérifiant si la session de son premier choix n’est pas pleine, et de parcourir éventuellement les choix suivants