Correction projet acmol
Correction projet ACMOL
Contributeurs
- Mathis EMERIAU
- Tristan RAME
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.
- C : La spécification des exigences est incomplète, elle ne permet pas à un développeur de mettre en oeuvre l'application. Elle montre que les participant ne maîtrisent que partiellement cette activité
- C : Les composants sont spécifiés partiellement, la spécification a besoin d'améliorations. Les participants maîtrisent partiellement cette activité
- B : La conception permet à un développeur/mainteneur de comprendre, à haut niveau, le code. Les participants maîtrisent partiellement cette activité
- E : Il n'y a pas de code
Bilan
- C : Travail irrégulier et incomplet, alternant des parties très bien faites et d'autres moins.
Commentaires
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