CSC 4102 – Introduction au génie logiciel pour applications orientées objet

Des éléments de modélisation et aussi des éléments de programmation sont fournis depuis le début du projet. Les éléments de programmation sont déjà disponibles dans le projet Maven du répertoire src. Commençons par compiler le code avec la commande « mvn clean install ». En plus de l'affichage ci-dessous, vous remarquerez les téléchargements d'archives (fichiers jar) entre autres à partir du dépôt csc4102-util-snapshot.

Observons ce qui s'est passé :

• le module dépend d'un module mis à disposition dans le dépôt Maven du module CSC4102 : csc4102-util-snapshot. Nous pouvons vérifier que cette dépendance est maintenant disponible dans notre dépôt Maven local avec la commande
  « ls -R ~/.m2/repository/eu/telecomsudparis/csc4102/csc4102-util/ » ;
• puis, nous voyons l'appel d'une séquence de greffons (en anglais, plug-ins) :
  • maven-clean-plugin : suppression du répertoire target (tout ce qui a été généré lors du processus de construction de l'exécution précédente) ;
  • maven-resources-plugin : traitement des ressources autres que des classes JAVA. Nous n'en avons pas ; ce pourrait être des fichiers de données, des fichiers de configuration, etc. ;
  • maven-compiler-plugin : compilation des classes JAVA ;
  • maven-resources-plugin : traitement des ressources des tests. Nous n'en avons pas non plus ;
  • maven-compiler-plugin : compilation des classes de test JAVA ;
  • maven-surefire-plugin : exécution des tests ;
• ensuite, l'archive résultat est créée avec le greffon maven-jar-plugin. Cette archive contient les classes compilées de l'application. Nous aurions aussi pu générer l'archive des classes compilées des tests ainsi que les archives des codes source de l'application et des tests ;
• et enfin, nous atteignons la fin de la construction du logiciel avec l'installation des archives dans le dépôt local (répertoire ~/.m2/repository/). La fin est notifiée avec le message « BUILD SUCCESS ». Nous pouvons vérifier l'installation avec la commande
  « ls -R ~/.m2/repository/eu/telecomsudparis/csc4102/*/1.0-SNAPSHOT/ ».

Pour créer le projet, Eclipse demande deux fichiers de configuration : .project et .classpath. Voici la manière de procéder :

• il s'agit d'utiliser le greffon m2e (Maven to Eclipse) de Eclipse : au lieu de créer le projet dans Eclipse comme un projet Java, importez-le comme un projet Maven  (menu File > Import > Maven > Existing Maven Projects > Next puis Browse > ~/CSC4102/csc4102-projet/ et enfin Finish). Dans ce cas, c'est Eclipse qui crée les fichiers de configuration .project et .classpath. Dans la vue « package explorer » de Eclipse, un « M » est ajouté à côté du « J » sur l'icone du projet et les cibles Maven sont disponibles dans le menu contextuel : click droit > Run As.

Vous mettrez des assertions JAVA dans votre code, par exemple avec l'instruction « assert invariant(); » déjà utilisée dans les classes du squelette fourni. Nous proposons d'activer l'utilisation des assertions dans les tests JUnit : menu Window > Preferences > Java > JUnit puis cochez la case « Add '-ea' to VM arguments when creating a new JUnit launch configuration » (l'option « ea » de la machine virtuelle Java signifie « enable assertions »).

Pour exécuter les tests JUnit, sélectionnez tous les tests du module Maven (src/test/java) ou un paquetage (p.ex. .../validation) ou encore une classe de test (p.ex. .../validation/TestXxxx.java) puis le menu contextuel (click droit) Run as > JUnit Test.

Pour vérifier l'activation de l'option, ajoutez l'instruction « assert false; » comme première ligne dans un des tests (dans une classe Test*, dans une méthode annotée @Test) et ré-exécutez les tests de la classe de tests. Votre test modifié est en erreur avec un message du type « java.lang.Exception: [...] java.lang.AssertionError ». Avant de continuer, retirez bien sûr l'instruction « assert false; ».

Lorsque vous poussez de nouveaux instantanés sur le dépôt Git de votre projet GitLab, la commande Maven indiquée dans le fichier .gitlab-ci.yml est exécutée par le service d'intégration continue GitLab CI. Cette commande compile les classes JAVA de votre projet Maven. Au fur et à mesure que nous avançons dans le projet, nous retirons les options de la commande mvn pour compiler les tests, etc.

À partir de cette séance, si vous poussez du code qui ne compile pas, vous recevrez un courriel avec un sujet de la forme « csc4102-projet | Pipeline ... has failed for branche[...] | beginning of SHA1 ».

Nous attendons que vous poussiez du code qui « passe » les vérifications de l'intégration continue, c'est-à-dire qui compile, etc., et donc que nous ne recevions pas de courriel d'alerte « Pipeline ... has failed ».

Afin de faciliter la programmation, la bibliothèque csc4102-util propose des méthodes pour manipuler des dates (jours), des instants (date avec heure, minute, etc.), des intervalles de dates. Dans le code du dépôt csc4102-exemples, parcourez les classes exemples ExempleManipulationsDatesInstants et ExempleManipulationsIntervalleDates dans le paquetage utilisationdelabibliothequeutil.

Pour les classes impliquées dans les premiers cas d'utilisation, programmez une première « version » de la classe avec les premiers attributs que vous avez identifiés et un construteur. Nous proposons que vous étudiiez les autres méthodes de ces classes relativement à la programmation des cas d'utilisation («  »), («  ») et («  »). C'est un conseil donné pour éviter de programmer des choses inutiles : par exemple, c'est une mauvaise idée de programmer sans nécessité des getters et des setters. Si vous n'êtes pas convaincus, discutez-en avec vos responsables de groupe.

Parmi les classes fournies au début du projet, certaines ont des instances dont les références sont mises dans des collections (listes ou dictionnaires) avec les associations ou compositions ayant des multiplicités « * » dans le diagramme de classes. Ces classes doivent redéfinir les méthodes equals et hashCode. Dans le code existant, vous avez un exemple de programmation d'une composition (avec la multiplicité « * ») de la façade du système vers une classe qui redéfinit les méthodes equals et hashCode.

Programmez les premiers cas d'utilisation («  »), («  »), et («  »). Pour ce faire, peut-être devez-vous programmer quelques autres cas d'utilisation, dont les diagrammes de séquence ne sont pas construits. Si un diagramme de séquence n'est pas construit pour un cas d'utilisation, c'est une occasion de faire la différence entre la programmation à partir du diagramme de classes avec un diagramme de séquence, et la programmation à partir du diagramme de classes sans le diagramme de séquence.