* Le Diagramme 1 confond les diagrammes de déploiement et de composants.
* Les types `boolean`, `int` et `void` n'existent pas en UML
== Spécification des composants
* La spécifications des composants, interfaces et des signatures des opérations semble correcte.
* Il n'y a que deux interactions : c'est peu.
* Les interactions montrent des échanges de messages qui ne correspondent à aucune des opérations spécifiées: elles ne sont d'aucune utilité pour valider les interfaces
== Conception détaillée
* La conception est très extensive, mais mélange l'analyse et la conception.
* Par exemple, les interactions entre les classes doivent être des appels d'opérations.
* Les diagrammes d'activités aussi ressemblent plus à des algorithmes génériques, niveau analyse, qu'à la conception d'une opération.
* La plupart des diagrammes de séquence n'aident pas à l'implémentation.
* Par exemple, supposez qu'un développeur souhaite implémenter l'opération `CardInterface::isCorrectAnswer(questionID: String, userAnswer: String)`.
** La Figure 43 illustre un appel de cette opération. Sur ce diagramme, c'est `GestionnaireDeReponses` qui l'implémente et non pas `CradInterface`.
** L'instance de `GestionnaireDeReponses` envoie le message `Get Correct Answer (questionId)` au composant `Question Database`, qui n'est pas spécifié
** L'instance de `GestionnaireDeReponses` retourne vrai si la réponse est correcte et faux sinon.
** L'apport de ce diagramme par rapport à la signature de l'opération n'est pas du tout évident.
** Quel est le type de la carte ? D'où vient `cardId` ? Comment l'instance de `GestionnaireDeReponses` détermine si la réponse est ou non correcte ?
== Stats Git
----
Contribution stats (by author) on the current branch: