L'étude porte sur une gestion de comptes bancaires. Nous avons démarré le premier jour à 14H.
"Une banque souhaite informatiser la gestion de ses comptes, le client doit pouvoir créditer et débiter son compte".
Le plan de l'étude est découpé en trois itérations : une it d'élaboration, deux de construction.
En fait, cette itération permet aussi de modéliser les différents cas d'utilisation car c'est la première (et a priori dernière) de l'élaboration.
Nous avons dans un premier temps obtenu une liste d'acteurs candidats:
Contexte du système
Cas d'utilisation
L'expression de besoins se termine pour cette itération en fin d'après midi, avec une présentation de l'analyse objet UP. Une explication des boundary, control, entity qui deviennent plutot:
A ce sujet,la classification de Rumbaugh pour OMT me semble plus pertinente que B/C/E. Nous terminons sur une première esquisse d'un diag de collaboration ainsi que du diag de classe associé. Demain, plusieurs scénarios, donc plusieurs diags (dont un ou deux avec le modeleur) et puis surtout organisation du modèle en paquetages d'analyse.
Thierry
L'étude est pilotée par les cas d'utilisation, plus exactement des scénarios jugés pertinents de ces cas:
Cela permet d'obtenir le "pilier" structurel du modèle que l'on organise en deux paquetages: ApplisGC (a priori une appli par use case) et "Métier Banque" qui contient deux classes:
A ce niveau les classes sont définies par leurs responsabilités.
Les choix techniques pour ce prototype sont: Java, IHM de type ligne de commande (nous sommes dans une formation :-) Un diag de déploiement est créé pour montrer ce qu'est ce type de diag dans UML. Nous démarrons ensuite la conception "détaillée" du proto en reprenant 1 scénario que l'on juge nécessaire et suffisant: "Ouverture - Création d'un compte cas normal". Il est modélisé par un diag de collaboration qui montre les objets de conception: "in" "out" "ouverture" en tant qu'objet applicatif, "compte" qui est le compte nouvellement créé et "collection" qui est de type "arrayList" de la bib. util de Java.
Un diag structurel qui montre les sous-systèmes de conception est alors créé.
La programmation reprend le scénario étudié en conception.
Sources Java de la première itération
Sources C++ de la première itération
Il est interessant de constater les différences entre conception et implémentation. Comme sur un projet, le développeur avance dans le système à l'occasion de l'implémentation. Autrement dit, de même que l'nalyse précise les besoins, la conception précise ou raffine la conception, de même l'implémentation va plus loin que la conception car le développeur a gagné en compréhension du système. Reste à savoir si tout ce qui est développé est effectivement demandé - ou sera validé - par le client. ThierryCros
Nous choisissons de tester la création du compte ("Durand", "Toulouse", 200); la création est vérifiée en intérrogeant le compte: son solde est bien de 200 EUR.
Pour info, le test est directement codé dans la classe et est invoqué en lieu et place du code "normal" de main(). Cela ne remplace pas, bien entendu, une programmation de tests unitaires type "jUnit" de XP mais c'est quand même une technique qui permet:
Sachant que ce n'est pas une solution viable: par définition le code ne peut pas contenir le test car supprimer le test en fin de dev. revient à modifier le code et donc à... le re-tester...
Modifications de specs:
Ajout d'une connexion à appli GC avec un mot de passe
Ajout d'une fonctionnalité "patrimoine" qui consiste à détecter un solde > 10.000 EUR pour envoyer une documentation sur les produits d'épargne.
Par ailleurs, l'architecture et l'analyse de l'itération précédente (élaboration) ont modifié le périmètre du système. En terme d'organisation du modèle, les use cases "Mouvement" et "Consultation" sont considérés comme pouvant être regroupés dans un nouveau cas: "Gestion" du compte.
D'où le nouveau diagramme de contexte:
Ce diagramme de contexte visualise uniquement les cas principaux (valeur ajoutée pour un acteur). Un nouveau diagramme qui visualise les relations entre paquets d'interactions est nécessaire:
Nous nous concentrons sur la gestion "Patrimoine" qui est la nouveauté de cette itération. Afin de tester une autre technique, complémentaire ou alternative à l'UML, nous organisons une "CRC cards session".
...