README.adoc 6.84 KB
Newer Older
Gerson Sunyé's avatar
Gerson Sunyé committed
1
2
3
4
5
6
7
8
= SCE Bank

SCE Bank est un logiciel de gestion de clients et comptes d'une banque.
Dans le cadre de ce projet, vous allez contribuer au développement de ce logiciel.

== Préambule

Si vous utilisez les machines des salles de TPs dans le cadre de ce projet, vous devez utiliser le Java JDK *java-8-oracle*.
Gilles ARDOUREL's avatar
Gilles ARDOUREL committed
9
Vous pouvez changer le JDK utilisé dans un projet dans le menu "Project structure" > "Project" > "Project SDK".
Gerson Sunyé's avatar
Gerson Sunyé committed
10
11
12

== Communication

Gilles ARDOUREL's avatar
Gilles ARDOUREL committed
13
Avant de commencer le projet, connectez-vous au serveur https://mattermost.univ-nantes.fr[Mattermost] de l'Université,
Gerson Sunyé's avatar
Gerson Sunyé committed
14
15
16
17
en utilisant votre compte GitLab.

Ensuite, rejoignez l'équipe "Génie Logiciel", puis le canal "CEL" (Construction et Évolution de Logiciels).

18
**Utilisez ce canal comme SEUL et UNIQUE moyen de communication avec les encadrants, pour toute question concernant le projet.**
Gerson Sunyé's avatar
Gerson Sunyé committed
19
20
21
22
23
24
25
26


== Organisation

Ce projet sera réalisé par groupe de 3 étudiants.
Vous allez suivre le processus de maintenance vu en cours.
Pour rappel:

27
Commencez par préparer l'environnement de votre projet :
Gerson Sunyé's avatar
Gerson Sunyé committed
28
29
30
31
32
33
34
35
36
37
38

. Avant toutes choses, un membre du groupe doit créer un *"Fork"* du projet sur le serveur.
Pour ce faire, cliquez sur l'icône "Fork" (ou "Créer une divergence" en français) de la page du projet pour accéder au lien suivant: https://gitlab.univ-nantes.fr/naomod/sce/projet-2019/forks/new

. Ajouter tous les autres membres du groupe à votre fork.

. Créez des étiquettes pour organiser les tickets du projet: _bug_, _improvement_, _smell_, _performance_, _test_, etc.

. Chaque membre du groupe doit cloner *votre fork du projet* (et non pas celui d'origine).
Toutes vos modifications devront être poussées sur votre _fork_ et toutes les issues (ou "tickets" en français) ouvertes le seront sur votre version du projet.

39
. *Il ne doit y avoir qu'un seul "fork" par groupe d'étudiants.* Il sera utilisé comme espace de rendu des fichiers liés au projet.
Gerson Sunyé's avatar
Gerson Sunyé committed
40
41
42

== Diagramme de classes niveau conception

Gerson Sunyé's avatar
Gerson Sunyé committed
43
image::class-diagram.png[align=center]
Gerson Sunyé's avatar
Gerson Sunyé committed
44
45
46
47
48
49
50
51
52


== Travail à réaliser

Le travail à réaliser est réparti en différentes "issues" (ou tickets), répertoriées dans le fichier
https://gitlab.univ-nantes.fr/naomod/sce/projet-2019/blob/master/ISSUES.md[`ISSUES.md`].
*Le but du projet est de résoudre tous ces tickets.*
Pour ce faire, *vous devrez suivre le protocole de travail suivant*, suivant la méthodologie Test-Driven Development (TDD).

53
Pour chaque ticket du fichier https://gitlab.univ-nantes.fr/naomod/sce/projet-2019/blob/master/ISSUES.md[`ISSUES.md`] :
Gerson Sunyé's avatar
Gerson Sunyé committed
54
55
56
57
58
59
60
61
62
63
64
65

. Ouvrez un ticket dans votre projet Gitlab (sur l'interface en ligne de Gitlab, section _Tickets_).
Vous y détaillerez les points suivants:

.. Un bref résumé du problème lié au ticket.
.. Quels sont les tests à mettre en oeuvre pour vérifier que le ticket a bien été résolu ?
.. Comment la solution au ticket doit être mise en oeuvre ?

. *Associez un membre du groupe* à la résolution du ticket, via l'interface de GitLab.
Cette personne, et uniquement celle-ci, sera chargée de résoudre le ticket.

. Créez les tests unitaires qui permettront de vérifier d'abord qu'il s'agit bien d'un problème et ensuite de la résolution du ticket.
66
Pour le nommage de vos tests, vous pouvez vous référer à la ressource suivante : https://dzone.com/articles/7-popular-unit-test-naming.
Gerson Sunyé's avatar
Gerson Sunyé committed
67
68

. Implémentez le code qui résout le ticket.
69
Les tests écrits précédemment devront valider votre implémentation. _Faites attention à la régression !_ :
Gerson Sunyé's avatar
Gerson Sunyé committed
70
71
toute modification ne doit pas "casser" du code qui marchait auparavant (les autres tests unitaires doivent passer).

72
73
. Si jamais vous devez changer d'approche au niveau des tests, de l'implémentation, etc.
*Ajoutez un commentaire sur le ticket Gitlab* pour documenter tout changement.
Gerson Sunyé's avatar
Gerson Sunyé committed
74
75
76
77
78
79
80
*N'éditez pas le texte du ticket original*, afin de garder un historique de votre travail.

. Effectuez un (ou plusieurs) commit(s) pour pousser vos modifications sur le dépôt,
en référençant le numéro du ticket et en indiquant votre progression dans sa résolution.
Nous vous invitons à lire le billet suivant à ce sujet: https://chris.beams.io/posts/git-commit/.

. Enfin, quand le ticket est résolu, marquez-le comme "résolu" dans l'interface de Gitlab.
81
Vous pouvez aussi fermer les tickets automatiquement à l'intérieur d'un message de commit :
Gerson Sunyé's avatar
Gerson Sunyé committed
82
83
84
85
https://docs.gitlab.com/ee/user/project/issues/automatic_issue_closing.html[Automatic issue closing]

Le code du projet est là pour vous fournir une base de code.
Vous êtes libre de _modifier l'implémentation comme vous l'entendez_,
86
voire même de modifier le modèle de classes UML en lui-même !
Gerson Sunyé's avatar
Gerson Sunyé committed
87
88
*Mais attention, vous devrez motiver tous vos changements dans vos différents tickets/commits !!!*

89
== Évaluation
Gerson Sunyé's avatar
Gerson Sunyé committed
90

Gilles ARDOUREL's avatar
Gilles ARDOUREL committed
91
* Le travail à rendre se composera de votre *fork en ligne Gitlab*, sur lequel vous aurez poussé toutes vos modifications.
Gerson Sunyé's avatar
Gerson Sunyé committed
92
93
94
95
96
Cela inclut également tous les messages de commits et tickets ouverts.

* Ajoutez un fichier "`RENDU.md`" à la racine du projet, afin de décrire les spécificités de votre projet
(choix techniques, parties non traitées, extensions non demandées, etc.).

97
* Pour être évalué, *tout étudiant doit participer activement au projet*, en réalisant des "commits",
Gerson Sunyé's avatar
Gerson Sunyé committed
98
99
100
101
102
103
104
105
106
107
108
109
en ajoutant des lignes de code, en ouvrant des tickets sur le serveur GitLab, etc.

* L'évaluation portera sur les critères suivants :

* Respect du protocole de développement donné dans l'énoncé (ouverture du ticket -> écriture des tests -> développement -> commits -> fermeture du ticket).

** Qualité des tickets ouverts sur votre projet Gitlab: description du problème, des tests requis et de la solution mise en oeuvre.
** Qualité du code produit.
** Qualité et pertinence des tests unitaires mis en place.
** Approche choisie pour résoudre chaque ticket.
** Qualité des messages de commits.

110
*Ne sacrifiez pas la qualité à la quantité !* Il vaut mieux rendre un projet bien réalisé avec des
Gerson Sunyé's avatar
Gerson Sunyé committed
111
112
113
114
115
116
117
118
119
tickets non résolus qu'un projet avec tous les tickets mal résolus.

== Détectez les erreurs de code avec IntelliJ et Sonarlint

L'éditeur IntelliJ propose un plugin appelé https://www.sonarlint.org/[Sonarlint], capable de détecter les _code smells_ dans vos projets.
Nous vous recommandons de l'installer et de l'utiliser dans le cadre de ce projet.

Pour l'installer, vous avez deux options:

120
121
. Allez dans le menu "Préférences" de IntelliJ -> Section "Plugins", cherchez "Sonarlint" puis cliquez sur "Installer".
. Installez le manuellement : https://plugins.jetbrains.com/plugin/7973-sonarlint
Gerson Sunyé's avatar
Gerson Sunyé committed
122
123
124
125
126

== Dépendances Maven

Le projet de démarrage est configuré comme un projet Maven standard.
Vous êtes libres d'ajouter de nouvelles extensions lors du développement du projet.
127
Par défaut, les dépendances suivantes sont configurées :
Gerson Sunyé's avatar
Gerson Sunyé committed
128
129
130
131

* JUnit (https://junit.org/junit5/) pour gérer les tests.

* Apache Commons Lang (https://commons.apache.org/proper/commons-lang/) qui fournit une extension de la librairie Java standard.