Correction projet acmol
Projet Catane
Contributeurs
- Rodrigue Meunier
- Nathan Deshayes
- Bilal Molli
- Erwan Boisteau-Desdevises
Évaluation
- 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.
- 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.
- 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é.
- B : La conception permet à un développeur/mainteneur de comprendre, à haut niveau, le code. Les participants maîtrisent cette activité
- C : Le code est un squelette initial de l'application, mais reste cohérent avec la conception détaillée. Les participants maîtrisent partiellement le passage de la conception au code.
Bilan
- B: Très bon travail, qui montre que le groupe a compris globalement les différentes activités du développement
Commentaires
- AD - Figure 1. Diagramme d’activités: Mise en place d’une partie -> Vous ne connaissez pas les boucles ?
- SE - Faites un effort pour rendre le document lisible
- SC - Pourquoi toutes les interfaces s'appellent "DataAccess" ?
- CD - Les diagrammes ne s'affichent pas correctement
Analyse du domaine
-
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
)- 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)
- 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
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
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