* Il n'y a pas de cardinalité `many` en UML, utilisez `[*]`
* Si vous avez une association entre 2 classes, il est inutile d'ajouter des attributs pour les associer
* D'ailleurs, limitez les attributs aux types de base (datatypes, énumérations, etc.). N'utilisez pas les classes pour typer les attributs.
* `//` n'est pas un commentaire en UML.
* Le type `Map` n'existe pas en UML. Si vous souhaitez représenter un tableau associatif en UML, utilisez les associations qualifiées:
----
@startuml
AcountManager [Player] -- "[*] accounts" Account
@enduml
----
== Spécification des composants (v1)
- Les figures n'ont pas de légende.
- Vous semblez avoir trop de composants. Êtes-vous sûrs que c'est justifié ?
- Dans le diagramme, vous ne distinguez pas les interfaces fournies (`--O`) des interfaces requises (`--(`). Référez-vous à la syntaxe d'UML: https://www.uml-diagrams.org/component-diagrams.html
- La syntaxe de la deuxième figure n'est pas valable.
- Les interfaces sont vides, elles ne contiennent pas d'opérations.
- À quelle interface appartient l'opération `initializeGameBoard()` ? Le type de retour, `GameBoardState` n'est pas défini. `GameStartOutcome` non plus.
- `List<Question>` et `List<Category>` sont des types Java, pas UML. Utilisez plutôt `Question [*]` et `Category [*]`. D'ailleurs, les classes `Question` et `Category` n'ont pas été définie
- 1 seule diagramme de séquences, c'est largement insuffisant pour valider les interfaces des composants.
- D'ailleurs, votre diagramme de séquences n'utilise pas de `Messages`, c'est à dire, des appels d'opérations.
== Spécification des composants (v2)
* Section 4
** Les diagrammes de composant ne sont pas adaptés à représenter des flots de données, ce n'est pas leur but
** Vous trouverez la syntaxe des diagrammes de composants ici: https://www.uml-diagrams.org/component-diagrams.html
** et celle des interfaces fournies et requises, ici: https://www.uml-diagrams.org/component.html
* Deuxième Section 1
** Je ne comprends pas ce que vous voulez dire avec l'agrégation entre `BoardLayout` et `Game Board Component`.
** Peut-être:
+
----
@startuml
GameBoard --() BoardLayoutInterface
@enduml
----
+
** Même commentaire pour le diagramme de la section 1.2.1, 3.2.1
* Section 8
** êtes vous sûrs que `Dice` est un composant ?
** même question pour `Movement Component`
* *Interaction*
** Vos diagrammes de séquence sont des *scénarios* ou *diagrammes de séquence système*, qui sont utiles pendant l'analyse du domaine et la spécification des exigences. Ils représentent des interactions de haut niveau entre utilisateur et le système.
** Ici, on souhaite des diagrammes de séquence de conception, qui décrivent les appels d'opération entre composants (à travers leurs interfaces)
** en d'autres termes, plutôt qu'écrire un texte libre comme 'Démarrer la partie', vous devez utiliser un appel d'opération "startGame()"
** Vous DS ne sont pas faux, mais ils ne permettent pas de valider les interfaces des composants.
== Conception détaillée
* La partie conception détaillée est un bon début, mais:
** vous vos concentrez exclusivement sur les aspects statiques et vous négligez les aspects dynamiques
** les interfaces fournies par les composants ont complètement disparu
** comment voulez-vous faire la conception détaillée des composants si vous ignorez les composants que vous avez spécifiés ?
== Statistiques Git
----
Contribution stats (by author) on the current branch:
