Correction projet acmol
Correction projet Catane
Contributeurs
- Aboubacar sidiki CAMARA
- Islam MASSAT
- Izzedine issa AHMAT
- Skander JMAIEL
Evaluation
- B : L'analyse du domaine explique correctement le domaine, mais manque de précision. Elle montre que les participant maîtrisent l'analyse du domaine.
- A: La spécification des exigences fonctionnelles sont suffisantes pour qu’un développeur mette en oeuvre l’application "Jeu Catane". Elle montre que les participant maîtrisent l'ingénierie des exigences.
- D : La spécification des composants ne spécifient pas les composants. Les participants n'ont pas compris l'intérêt de cette activité.
- D : Il n'y a pas de conception détaillée. Les participants ne maîtrisent pas cette activité.
- E : Il n'y a pas de code
Bilan
- C- le travail initial était très bien, c'est dommage de ne pas avoir avancé un peu plus
Commentaires
- Fichier
CONTRIBUTORS.md
absent - Le site web (catan-website) n'est pas accessible
Analyse du domaine
-
Les cas d'utilisation [+] Respect du canevas de Cockburn [+] 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 utilisent des valeurs et non de types
Conception détaillée
[-] La conception propose une réponse claire aux différentes exigences non-fonctionnelles [-] Les patrons de conception et leurs applications sont décrits clairement [-] Chaque composant est décrit par un diagramme de classes. [-] Les opérations des composants sont décrites par des pré- et post-conditions OCL, des diagrammes d'activités, ou des diagrammes d'interaction [-] Le diagramme de classes utilise des concepts d'implémentation, comme des interfaces, des classes actives, etc. [-] Le diagramme de classes ne confond pas attributs et rôles [-] Les attributs sont correctement spécifiés
Construction
[-] Le code source Java est organisé en modules/artefacts [-] Le code source TypeScript est organisé en modules/artefacts [-] Le code contient au moins deux bouchons pour tester les composants serveur et client de façon isolée [-] Le code est cohérent avec la conception [-] Le code source est lisible [-] Les commentaires sont corrects [-] Les classes Java sont vérifiées par des tests unitaires [-] Les classes TypeScript sont vérifiées par des tests unitaires