Skip to content

Latest commit

 

History

History
94 lines (65 loc) · 4.33 KB

RAPPORT-iteration-i.md

File metadata and controls

94 lines (65 loc) · 4.33 KB

Rapport Itération numéro i

Identification des membres de l'équipe

Veuillez éditer ce fichier afin de fournir les informations nécessaires à votre évaluation.

Assurez-vous d'utiliser toujours le même compte GitHub pour accéder à ce projet.

Membre 1

  • Entrer votre nom
  • Entrer votre courriel
  • Entrer votre code Moodle obtenu à partir de Signets
  • Entrer l'identifiant de votre compte GitHub

Membre 2

  • Entrer votre nom
  • Entrer votre courriel
  • Entrer votre code Moodle obtenu à partir de Signets
  • Entrer l'identifiant de votre compte GitHub

Membre 3

  • Entrer votre nom
  • Entrer votre courriel
  • Entrer votre code Moodle obtenu à partir de Signets
  • Entrer l'identifiant de votre compte GitHub

Membre 4

  • Entrer votre nom
  • Entrer votre courriel
  • Entrer votre code Moodle obtenu à partir de Signets
  • Entrer l'identifiant de votre compte GitHub

Membre 5

  • Entrer votre nom
  • Entrer votre courriel
  • Entrer votre code Moodle obtenu à partir de Signets
  • Entrer l'identifiant de votre compte GitHub

Exigences

Liste des exigences et personnes responsables de celles-ci.

Exigence Responsable
CU01 Yvan

Modèle du domaine (MDD)

Le MDD est cumulatif : vous devez y ajouter des éléments à chaque itération (ou corriger les erreurs), selon la portée (et votre meilleure compréhension du problème) visée par votre solution. Utilisez une légende dans le MDD pour indiquer la couleur de chaque itération afin de faire ressortir les changements (ce n'est pas toujours possible pour les associations et les attributs). Voir les stéréotypes personnalisés : https://plantuml.com/fr/class-diagram et comment faire une légende avec couleurs en PlantUML.

Diagramme de séquence système (DSS)

Un seul DSS sera choisi et corrigé par l'auxiliaire d'enseignement

Contrats

Si vous avez choisi un cas d'utilisation nécessitant un contrat, il faut le mettre dans cette section. Note: même s'il y a plusieurs contrats, un seul contrat sera choisi et corrigé par l'auxiliaire d'enseignement

Réalisation de cas d'utilisation (RDCU)

Chaque cas d'utilisation nécessite une RDCU. Note: une seule RDCU sera choisie et corrigée par l'auxiliaire d'enseignement

Diagramme de classe logicielle (DCL)

Facultatif, mais fortement suggéré Ce diagramme vous aidera à planifier l'ordre d'implémentation des classes. Très utile lorsqu'on utilise TDD.

Vérification finale

  • Vous avez un seul MDD
    • Vous avez mis un verbe à chaque association
    • Chaque association a une multiplicité
  • Vous avez un DSS par cas d'utilisation
    • Chaque DSS a un titre
    • Chaque opération synchrone a un retour d'opération
    • L'utilisation d'une boucle (LOOP) est justifiée par les exigences
  • Vous avez autant de contrats que d'opérations système (pour les cas d'utilisation nécessitant des contrats)
    • Les postconditions des contrats sont écrites au passé
  • Vous avez autant de RDCU que d'opérations système
    • Chaque décision de conception (affectation de responsabilité) est identifiée et surtout justifiée (par un GRASP ou autre heuristique)
    • Votre code source (implémentation) est cohérent avec la RDCU (ce n'est pas juste un diagramme)
  • Vous avez un seul diagramme de classes
  • Vous avez remis la version PDF de ce document dans votre répertoire
  • Vous avez regardé cette petite présentation pour l'architecture en couche et avez appliqué ces concepts