Correction projet acmol
Projet Catane
Contributeurs
- Julien Brochard
- Cyprien Garnier
- Hugo Chabane
- Merja Pyrhonen
Évaluation
- C : L'analyse du domaine explique partiellement le domaine et manque de précision. Elle montre ques les participants maîtrisent partiellement l'activité
- B: La spécification des exigences nécessitent encore quelques améliorations pour permettre à un développeur de mettre en oeuvre l'application "Jeu Catane". Elle montre que les participant maîtrisent l'ingénierie des exigences.
- C : Les composants sont spécifiés partiellement, la spécification a besoin d'améliorations. Les participants maîtrisent partiellement cette activité
- C : La conception ne prend pas en considération la spécification des composants. Les participants n'ont pas compris la relation entre la spécification d'un composant et sa conception détaillée. Les participants maîtrisent partiellement cette activité
- B Le code est plutôt avancé, mais a encore besoin d'améliorations pour marcher correctement. Les participants maîtrisent le passage de la conception au code.
Bilan
- B- : bon travail, mais certaines parties méritaient d'être plus soignées.
Commentaires
- Pensez à ajouter un fichier
CONTRIBUTORS.md
à votre projet - Des commits faits par "salade"
- Évitez d'utiliser des conditions dans le scénario nominal des cas d'utilisation
- L'objectif des diagrammes de séquence de la spécification des composants est de valider les interfaces des composants. Si vous n'utilisez pas ces dernières, vous ne pouvez pas les valider.
- Le sujet du projet demande clairement l'utilisation de TypeScript
Analyse du domaine
-
Les cas d'utilisation [-] Clairs, bien décrits [+] La relation entre les cas d'utilisation et les actions est claire [-] Le sujet des actions est décrit clairement [+] Les actions sont illustrée par plusieurs instantanées et/ou par un diagramme d'activités
Les instantanés représentent bien des objets avant et après une action [+] les cas d'utilisation ne font pas référence à des concepts informatiques (du domaine de la solution) -
Diagramme de classes du domaine [-] Le diagramme montre clairement la structure du jeu Catane (emplacements, intersections, cartes, joueurs, etc.) [+] Les classes possèdent des attributs [-] les attributs sont typés [-] Les attributs ont des cardinalités [-] Les rôles des associations sont nommés [+] Les rôles ont des cardinalités [+] Les cardinalités sont précises [+] Le diagramme n'utilise pas des concepts d'implémentation, comme Interfaces [] Le diagramme utilise correctement les types UML et non des types Java (
List, void, double
, etc.) [] Il n'y a pas de confusion entre rôle et attribut [+] Il n'y a pas de confusion entre Association et Spécialisation [+] Les classes n'ont pas des opérations inutiles, commegetXXX()
etsetXXX()
[] Utilisation correcte de la syntaxe UML (str : String
) plutôt que celle de Java (String str
) -
Autres [] Dictionnaire de données du domaine plutôt complet
Spécification des exigences
[+] Les exigences fonctionnelles sont claires [+] Chaque exigence fonctionnelle est décrite par un cas d'utilisation [+] Le scénario nominal de chaque Cas d'utilisation est écrit correctement [+] Les variantes et extensions sont utilisées correctement [-] Les Cas d'utilisation sont illustrés par des diagrammes [+] Les notes d'aide à l'écriture ont bien été retirées du document final
Spécification des composants
[-] Les composants sont présentés par un diagramme global [-] Les responsabilités de chaque composant sont clairement décrites [+] Les interfaces des composants sont bien spécifiées [+] Les opérations des interfaces sont bien spécifiées [-] Les opérations sont spécifiés avec des pré- et des post-conditions en OCL ou en texte [-] Les interfaces spécifiées sont validées par au moins un diagramme d'interaction [-] Les interfaces spécifiées sont validées par plusieurs diagrammes d'interaction [-] Les diagrammes d'interaction sont cohérents avec l'interface des composants
[Please keep reading the next comment − original message was too long and cut in several parts]