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

Séance 3 — TP : Conception préliminaire

Pour réaliser le projet, vous avez besoin de connaître la méthodologie présentée en cours. En outre, vous pouvez vous inspirer des exemples du cours ainsi que des deux études de cas complètes fournies dans le projet GitLab csc4102-exemples. Si ce n'est pas déjà fait, clonez le projet GitLab (cd ~/CSC4102/; git clone git@gitlabens.imtbs-tsp.eu:enseignants.csc4102/csc4102-exemples.git; cd csc4102-exemples) et prenez connaissance du fichier readme.md. Ou, mettez à jour le dépôt que vous avez cloné (les exemples évoluent [même si c'est peu]) : cd ~/CSC4102/csc4102-exemples; git fetch; git pull origin main.

quelques retours en arrière sur la spécification et la préparation des tests sont possibles à cause d'oublis ou de mauvaises compréhensions du système. Nous vous conseillons de noter les modifications/adaptations au fur et à mesure, mais d'attendre le hors présentiel pour les faire. Concentrez-vous prioritairement sur les nouveaux éléments à mettre en pratique pendant le TP en présentiel.

bien que les questions (ainsi que la présentation) figurent dans un certain ordre, revenez sur tous les diagrammes pour les compléter ou les corriger. Il s'agit de l'élaboration d'une solution, qui passe nécessairement par une compréhension du problème tant d'un point de vue statique que d'un point de vue dynamique ;
n'hésitez pas à compléter vos diagrammes de tout commentaire facilitant la compréhension ou permettant d'attirer l'attention sur des points qui resteraient obscurs et à approfondir ;
gardez à l'esprit que vous insérez les images des diagrammes dans le fichier readme.md. Par exemple, ne faites pas des diagrammes qui deviennent trop difficiles à lire.

(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.

Aspects statiques

trouver les classes dites « métier »,
dessiner le diagramme de classes de la conception préliminaire.

Pour cette étape, aidez-vous de la méthodologie présentée dans la diapositive « 2.8 Éléments de méthodologie » du cours.

Liste des classes et diagramme de classes

Une nouvelle lecture du cahier des charges (uniquement la section 2 et l'annexe~A) doit vous permettre de créer une liste de classes et de noter de manière informelle leurs attributs ainsi que leurs associations. Parcourez aussi les diagrammes de cas d'utilisation avec les préconditions et postconditions que vous avez construits lors de la séance 2, car les concepts métier y figurant sont sans doute des classes métier.

Un critère de validité d'un attribut est qu'il doit être simple (type/valeur) : par exemple, date, nombre et texte. Dans le cas contraire, soit en faire une classe soit simplifier la conception en laissant la question pour plus tard (ou pour une question à poser dans le fichier de suivi Suivi/readme.md). Par ailleurs, pour ceux qui voudraient mettre des références en attribut, les classes doivent être reliées avec des associations et non avec des attributs (dans le diagramme de classes, on ne montre pas les attributs qui réalisent les associations) : ce point sera détaillé dans la séance 4 lors de la conception détaillée, qui redira de ne pas mettre ces attributs dans un diagramme de classes.

Concernant les opérations, ce n'est pas encore le moment de les trouver (toute opération devra êre testée, et par conséquent, ajouter des opérations inutiles peu coûter cher en développement). C'est principalement la partie dynamique qui donnera les opérations. En résumé, il n'est pas nécessaire de surcharger le diagramme de classes avec des opérations et les opérations existent uniquement lorsque l'on en a besoin (pas a priori).

Complétez le diagramme de classes fourni dans une première version du modèle. Ce diagramme est sujet à raffinements dans les prochaines séances.

Aspects dynamiques

dessiner au moins 2 des 3 diagrammes de séquence ( ·· ··) pour les cas d'utilisation ·· ··

Diagrammes de séquence

Le diagramme de classes décrit l'intérieur du système avec les classes et les relations entre les classes. Nous sommes prêts pour décrire la réalisation des cas d'utilisation avec ces classes et ces relations. Tout cas d'utilisation peut donner lieu à la construction d'un diagramme de séquence (ou plusieurs si le cas d'utilisation est trop complexe pour « tenir » dans un seul diagramme [on utilise alors des fragments « ref »]).

Pour cette étape, aidez-vous de la méthodologie présentée dans la diapositive « 4.6 Éléments de méthodologie » du cours.

avant de dessiner un diagramme de séquence, ébauchez au brouillon l'algorithme correspondant en langage naturel. C'est important pour vérifier la logique avant de se lancer dans le dessin. (Vous pouvez laisser l'ébauche dans le document readme.md.)

Pour au moins deux des cas d'utilisation, dont (« »), (« ») et (« »), construisez un diagramme de séquence, que vous nommerez de ·· ·· dans le fichier readme.md.

nous ne dessinons pas tous les diagrammes de séquence, soit parce qu'ils seraient relativement « triviaux », soit par manque de temps. Dans la suite du projet, lorsqu'il y a discussion sur un cas d'utilisation, dessinez le diagramme de séquence ou faites-en au moins une esquisse ; rappelez-vous le conseil de Martin Fowler : « The primary value of a diagram is communication ».

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.