CSC 4102 – Introduction au génie logiciel pour applications orientées objet

Séances 9 — TP : Qualité du modèle et patrons de conception

(Re-)Positionnement dans le dépôt `Git` de `GitLab`

Voici la procédure que nous proposons (dans tous les cas « par défaut »). « En cas de panique », veuillez vous reporter à celle qui suit celle-ci.

Procédure « repositionnement »
- on repart d'un dépôt mis à jour et on continue dans la branche develop
  - cd ~/CSC4102
    cd csc4102-projet
    git fetch # prendre connaissance des nouveautés
    git branch # quelle est la branche courante ?
    si pas déjà dans la branche develop alors « git checkout develop » # se positionner dans la branche
    git pull origin develop # accepter les modifications de la branche
    si conflit et besoin d'une fusion, « git mergetool --tool=meld » puis « git commit »

« En cas de panique », veuillez suivre la procédure qui suit :

Procédure « nouveau clonage »
- on clone à nouveau le dépôt et on continue dans la branche develop :
  - cd ~/CSC4102
    mv csc4102-projet csc4102-projet_old # garder une copie au cas où du contenu n'ait pas été poussé
    git clone URL_DE_VOTRE_PROJET
    cd csc4102-projet
    git checkout develop # positionnement dans la branche develop

En fin d'énoncé de ce TP, nous proposons une procédure pour la tâche duale consistant à clore une phase de travail en validant et poussant les modifications sur le dépôt Git de GitLab.

Évaluation de la qualité du modèle

amélioration de la qualité du modèle de l'application, notamment, vérification de la cohérence entre les diagrammes du modèle ainsi qu'avec le code.

Nous ne vous demandons pas de reprendre la modélisation de votre solution pour par exemple améliorer la cohésion fonctionnelle (comme expliquée dans la section 2.3 des diapositives du cours). Nous nous limitons aux questions de cohérence.

Vérifiez la cohérence entre les diagrammes du modèle, et plus particulièrement entre le diagramme de classes et les diagrammes de séquence : par exemple, vérifiez que les messages utilisent des associations qui existent et qui sont navigables dans le sens traversé.

Vérifiez la cohérence entre les diagrammes du modèle et le code, et plus spécialement entre les diagrammes de classes et de séquence, et le code.

Patrons de conception

application du patron de conception « » () à l'étude de cas,

dans ce qui suit, nous dessinons une vue haut niveau, qui se veut cependant tendre vers la complétude des tâches à effectuer pour l'insertion du patron de conception .

Nous ne nous attendons pas à ce que la modélisation et la programmation soient terminées à la fin de la séance 9. En effet, ce sont les dernières tâches que nous vous demandons et vous avez jusqu'à la fin de la séance 10 pour les réaliser.

Étudiez un exemple JAVA (avec la bibliothèque Flow) du patron de conception () :

dans le projet csc4102-exemples, dans le répertoire du code des exemples, dans le paquetage seance9.patrondeconception.publiersouscrire,
après compilation du code, exécutez la classe Main,
et parcourez l'exemple avec les classes Main, Consommateur, et Publication.

Le patron de conception est utilisé dans plusieurs cas d'utilisation, dont (« »). En ce qui concerne le cas d'utilisation (« »), à la fin du processus d'évaluation, la présidente du comité de programme notifie les auteurs des décisions. On remarquera que l'on peut aussi notifier : (1) l'évaluatrice lorsque la présidente du comité de programme l'ajoute lui demande d'évaluer une communication, c'est-à-dire pour le cas d'utilisation (« »)), (2) la présidente du comité de programme lorsqu'une nouvelle évaluation est ajoutée à une communication, c'est-à-dire pour le cas d'utilisation (« »)).

Nous vous conseillons de lire l'énoncé jusqu'à la fin de la section avant de réaliser l'ajout du patron de conception.

Pour insérer le patron de conception pour la notification des décisions :

soit vous commencez par la modélisation :
- modifiez le diagramme de cas d'utilisation pour la notification des décisions : d'une part le cas d'utilisation (« ») notifie l'acteur auteur, et d'autre part, un nouvel argument est ajouté au cas d'utilisation « ajouter un auteur » pour donner le consommateur de notifications à utiliser lors des notifications ;
- modifiez le diagramme de classes pour insérer le patron de conception : un nouvel attribut pour le consommateur dans la classe Utilisateur, un attribut de type SubmissionPublisher dans la classe Présidente pour envoyer les notifications, etc. ;
- (optionnel) réalisez le diagramme de séquence du cas d'utilisation (« ») ;
soit vous commencez par la programmation :
- dans la classe qui représente un auteur, nous proposons d'ajouter un « producteur » (classe SubmissionPublisher) pour les notifications des décisions ;
- dans la classe Utilisateur, nous proposons d'ajouter un « consommateur » (votre classe de consommation) ;
- lors de la création d'un objet représentant un auteur, nous proposons de lier le consommateur au producteur (appel de la méthode SubmissionPublisher::subscribe) ;
- concernant le type des « publications » envoyées, nous proposons, dans un premier temps, qu'elles contiennent des chaînes de caractères donnant les informations sur le message à modérer : par exemple, avec le libellé de la communication concaténé avec le libellé de la décision ;
- dans la programmation du cas d'utilisation (« »), un appel à SubmissionPublisher::submit est effectué pour tous les auteurs d'une communication. Cet appel donne lieu à terme à un appel à ConsommateurNotification::onNext dans tous les consommateurs des auteurs précédemment enregistrés. Dans notre étude de cas, nous proposons que onNext affiche le contenu de la décision.
- les « consommateurs » sont à l'extérieur du logiciel, c'est-à-dire qu'ils sont créés à l'extérieur et passés en argument des cas d'utilisation pour être enregistrés à l'intérieur du système : le consommateur d'un auteur est passé en argument du cas d'utilisation « ajouter un auteur » et est gardé en mémoire dans l'objet représentant l'auteur dans le système. Par ailleurs, les notifications sont asynchrones, c'est-à-dire que l'on ne maîtrise pas l'instant d'appel de la méthode ConsommateurNotification::onNext. Donc, dans les méthodes de test, après l'appel de la méthode du cas d'utilisation (« »), il faut attendre un peu (par exemple avec Thread.sleep(100)) pour laisser le temps à la machine virtuelle de faire apparaître dans la console les publications reçues affichées par onNext ;
- enfin, pour que le logiciel soit complet, gérez les autres notifications indiquées dans le cahier des charges.

Continuation du développement de l'application

dans cette section, nous présentons les éléments pour la seconde partie du module. Vous êtes en autonomie et devez lisser votre charge de travail sur les dernières séances. En termes de priorité, les remarques faites lors des suivis sont prioritaires.

Vous devez compléter votre logiciel pour qu'il possède toutes les fonctionnalités présentées dans le cahier des charges (cf. la section « Complétude du logiciel » du cahier des charges). Hormis la notification avec le patron de conception Publier/Souscrire, tout le logiciel peut être développé : pour la partie notification, si vous n'avez pas inséré le patron de conception Publier/Souscrire, utilisez un affichage à la console pour indiquer qu'un acteur est notifié.

Nous conseillons de commencer l'étude de ces éléments une fois les cas d'utilisation (« »), (« »), et (« ») programmés et testés sans le mécanisme des notifications.

Comme vous avez gagné en autonomie, nous vous laissons organiser votre travail en présentiel et en hors présentiel tout au long des dernières séances. Bien sûr, n'hésitez pas à discuter de vos tâches et de votre solution avec vos responsables de groupe.

Lors des travaux à venir, des modifications peuvent impacter la modélisation existante : diagramme de cas d'utilisation, pré-/post-conditions, tables de décision des tests de validation, diagramme de classes, diagrammes de séquence, etc.

Pour les nouveaux cas d'utilisation, nous vous laissons décider ce que vous modélisez, la seule obligation étant de fournir les nouveaux élements suivants :

précondition et postcondition de (« ») ;
tables de décision des tests de validation de (« ») ;
programmation du cas d'utilisation (« ») ;
programmation des tests de validation du cas d'utilisation (« »).

Mise à disposition du travail effectué dans le dépôt `Git` de `GitLab`

Systématiquement, avant de terminer une séance de travail, que ce soit en salle TP ou chez vous, mettez à jour votre dépôt local (au cas où vous ayez travaillé en parallèle), validez et poussez votre travail :

git fetch # charger les modifications non encore connues localement
git pull origin develop # mettre à jour votre branche develop
et si conflit et besoin d'une fusion, git mergetool --tool=meld
git status # connaître l'état de votre arborescence
selon les besoins, pour préparer la zone de transit pour la validation du prochain instantané, git add, git mv, git checkout --, etc.
git commit -m "je dis ce que contient le nouvel instantané" # valider les modifications de la zone de transit
git push origin develop # pousser pour mettre à disposition
connectez-vous à GitLab et vérifiez que votre travail a été poussé.

À LA FIN DU TP DE LA SÉANCE

Avant de quitter le TP, veuillez s'il vous plaît remplir dans la page Partage de votre groupe le tableau d'avancement de votre binôme-projet :

C'est aussi le moment de parcourir la grille d'auto-évaluation de la séance.