Ingénérie logicielle dirigée par les modèles

Ingénérie logicielle dirigée par les modèles Destercq Lionel & Dubuc Xavier 17 décembre 2009 Table des matières 1 Introduction 1 2 Diagrammes de classes 1 2.1 Principal.............................................. 2 2.2 GSM................................................ 5 3 Diagrammes de cas d utilisation 6 3.1 Principal.............................................. 6 3.2 GSM................................................ 7 4 Diagrammes de séquence 8 4.1 InsCard.............................................. 8 4.2 performtransaction........................................ 9 4.3 performwithdraw......................................... 10 4.4 performsaving.......................................... 11 4.5 performdeposit.......................................... 12 4.6 performrecap........................................... 13 4.7 performconsultation....................................... 14 4.8 Le module SMS.......................................... 15 4.9 Le serveur téléphonique..................................... 16 4.10 Le module WAP......................................... 17 5 Diagrammes d états 18 5.1 Diagramme d état de l écran................................... 18 5.2 Diagramme d état du lecteur de carte............................. 19 5.3 Diagramme d état du module SMS............................... 19 1 Introduction Nous avons, dans le cadre du cours d ingénierie logicielle dirigée par les modèles, développé un modèle de conception pour un ATM doté d un module permettant d accéder à des opérations bancaires via l envoi de SMS, la connexion à un site WAP ou par téléphone. Nous présentons dans ce rapport les différents diagrammes que nous avons construit afin de modéliser cet ATM et ce, avec une brève explication ainsi qu une justification des choix lorsque ceci est nécessaire. 2 Diagrammes de classes Nous avons décidé de séparer le tronc commun du projet de notre partie personnelle afin d éclaircir les diagrammes de classes. Nous avons également pris la décision de ne pas afficher les «getters/setters» dans le seul but que le diagramme soit affichable dans un pdf. Voici ces 2 diagrammes : 1

2.1 Principal 2

Explications : Nous avons une classe «centrale» ATM surlaquelle sont greffées, par compositions, quelques autres classes représentant les différents modules de l ATM, chacuns étant modélisés avec les fonctionnalités qui lui sont dédiées dans l énoncé. Parmi ces classes nous comptons : Ecran : l écran, il permet d afficher des informations et de faire un choix parmi les options offertes par l ATM en cliquant sur un de ses 6 boutons. Cette classe est donc définie par ses 6 boutons et son espace servant à afficher des données. ClavierNumerique : Simple classe qui permet d entrer des données via le clavier de l ordinateur, ces données ne devront être exclusivement que des chiffres. Cette classe est définie par l espace servant à permettre à l utilisateur d entrer des données. Imprimante : l imprimante, qui permet d imprimer des informations ; elle est définie par son niveau d encre ; si son niveau est à 0 elle ne peut imprimer. ConteneurBillet : le conteneur de billet, il est caractérisé par ce qu il contient, c est-à-dire des Billet s (classe représentant un billet). DistributeurBillet : le distributeur de billet qui permet de prendre de l argent dans le ConteneurBillet et le donner à l Utilisateur connecté à l ATM. AvaleurBillet : l inverse du DistributeurBillet LecteurCartes : le lecteur de cartes, l Utilisateur y entre sa carte et celui-ci lit les informations qui y sont stockées. Ce lecteur est caractérisé par son état ainsi que par la carte qu il est entrain de lire. L ATM appartient à une Banque qui représente en fait le bâtiment où une Agence a élu domicile (une Agence peut donc posséder plusieurs Banque s). Une Agence est caractérisée par son nom et son identifiant auprès du ReseauBancaire mais également par le plafond de retrait maximum par jour qu elle a fixé ainsi que le seuil minimal qu un compte peut atteindre. Quant à l Agence, elle appartient à un ReseauBancaire, cette association est rendue par une composition marquant ainsi l appartenance avec force, si le ReseauBancaire n existe plus, les Agence s non plus (si c était le cas, on aurait des ennuis lorsqu un client d une autre Agence se connecte et demande des opérations sur son compte. De plus, chaque Agence possède une BaseDonnees qui elle, contient tous les comptes des gens qui sont «affiliés» dans l Agence à qui elle appartient. La classe Compte symbolise un compte en banque, elle est symbolisée par son numéro de compte, sa balance ainsi que le fait que ce soit un compte d épargne ou pas. Chaque Compte correspond à une Carte (la Carte permettant l accès au Compte lors de la connexion à l ATM) et appartient à un Utilisateur, classe représentant un quelconque utilisateur de l ATM, caractérisé par l Agence à laquelle il appartient. Cette classe hérite de la classe Personne représentant une personne physique quelconque, et possède une sous-classe, Client qui elle, représente un Utilisateur de l ATM qui est client de l Agence à laquelle l ATM appartient, client qui possède un numéro identifiant auprès de son Agence. La classe Personne (définie par un nom de famille et un prénom) possède 2 sous-classes autres que Utilisateur : Employe, symbolisant l employé travaillant dans la banque (relation symbolisée par une association entre Employe et Banque défini par son numéro identifiant d employé. Technicien, symbolisant le technicien s occupant des problèmes techniques survenant dans une banque (relation symbolisée par une association entre Technicien et Banque) ; il est défini par son numéro identifiant de technicien. Quant aux opérations, chaque classe composant l ATM a des opérations spécifiques (comme printdata(s : String) de l Imprimante) simples et basiques en plus des «getters/setters», nous ne les détaillerons pas. Par contre, la classe ATM possède toute une floppée d opérations qui correspondent aux opérations possibles dans un ATM. Cela permet d utiliser une seule classe qui va utiliser les ressources qui lui sont connectées pour effectuer toutes les opérations nécessaires à une transaction bancaire. Leur fonctionnement détaillé respectif est représenté (pour la plupart) dans les diagrammes de séquences, nous les explicitions ici brièvement : stopsession() : Arrêter la session, éjecter la carte, afficher un message disant au revoir,... withdraw(amout : int) : Retire autant d argent qu amount, si c est possible. L ATM connaîtra le compte à décréditer via le LecteurCartes. swallowcard() : Avaler la carte. ejectcard() : Ejecter la carte (via le LecteurCartes). handleinsertedcard() : Demander le code PIN à l utilisateur, le vérifier,... consultsaving() : Consulter le solde d un compte d épargne. consultbalance() : Consulter le solde d un compte à vue. transfertfrom(c : Compte) : Transférer de l argent d un Compte à celui correspondant à la Carte 3

présente dans le LecteurCartes. transfertto(c : Compte) : Transférer de l argent vers le Compte c à à partir de celui correspondant à la Carte présente dans le LecteurCartes. deposit() : Lancer le processus d entrée d argent dans l ATM, elle «réveille» donc l AvaleurBillet qui va permettre à l utilisateur d entrer de l argent et une fois que c est terminé l ATM reprend la main et effectue les actions de dépôts. printreceive() : Demande à l Imprimante d imprimer le reçu (lors d un dépot ou autre opérations le nécessitant). printbalance() : Demande à l Imprimante d imprimer la balance du compte de l Utilisateur. printrecap() : Demande à l Imprimante d imprimer le récapitulatif des opérations effectuées. createatmpanel() : Crée le panneau d affichage de l ATM (regroupant ses différents éléments). showwelcomemessage() : Affiche un message de bienvenue à l Ecran. showthanksmessage() : Affiche un message de remerciement à l Ecran. showproblemmessage() : Affiche un message concernant un probleme à l Ecran. addoperation() : Ajoute une opération de dépot d argent (ou d autres le nécessitant) à la liste des opérations en attente d être vérifiées et validées par un employé). La plupart des autres classes sont également peu intéressantes au niveau des opérations, mis à part le Technicien et l Employe qui ont des méthodes spécifiques pour leur permettre d entretenir l ATM. Pour les 2 classes, ils passent par la classe Banque dans laquelle ils travaillent tous 2 pour atteindre l ATM (et par l ATM pour atteindre ses éléments). En ce qui concerne l Employe : verifydepot() : Verifier si un dépôt est correct, il lit ces dépôts dans la liste des opérations demandant vérification de l ATM. addaccount(client : Client, account : Compte) : Ajouter un nouveau compte. consultmoneyinab() : Consulter l argent total qu à avaler l AvaleurBillet. getatmstate() : Vérifier l état de l ATM. consultmoneyincb() : Consulter l argent restant dans le ConteneurBillet. addmoneyincb(billets : Billet[]) : Ajouter de l argent dans le ConteneurBillet. Et le Technicien : addink(level : int)) : Ajouter level d encre dans l imprimante (ou changer une cartouche). setatmstate(state : String) : Modifier l état de l ATM. 4

2.2 GSM 5

Explications : Première remarque, c est que nous avons décidé de séparer la notion d utilisateur de l ATM de la notion d utilisateur d un GSM pour accéder à l ATM ; c est pourquoi nous avons une classe UtilisateurGSM qui est simplement définie par son numéro de téléphone. Un GSM sera identifié par un numéro de série et un numéro de téléphone ; il sera utilisé pour envoyer/recevoir des SMS, naviguer sur le WAP et téléphoner. Selon le moyen utilisé, un module spécial de l ATM communiquera avec le GSM : ModuleSMS : s occupera du SMS reçu (treatmsg) et permettra également de modifier le numéro de GSM utilisé ainsi que de recharger le GSM correspondant. (Nous avons abstrait très fortement le traitement du SMS pour la simple raison que nous n avons pas encore décidé quel SMS correspondrait à quel action) ServeurTelephonique : s occupera des appels venant de GSM, il proposera un menu et traitera ensuite la demande de l utilisateur. SiteAgence : Traitera les demandes venant du WAP. Les 2 classes Agence et ATM sont les mêmes que dans l autre diagramme. 3 Diagrammes de cas d utilisation 3.1 Principal Explications : C est assez parlant et ça ressemble beaucoup à ce que l on a fait en cours ; nous allons donc développer ce qui a nécéssité un choix et qui est pertinent d étendre : L attente d un nouveau client est géré par le cas d utilisation Afficher message bienvenue, grâce à l extends point qui lui est attribué. La vérification de la possibilité du retrait est assez abstraite ici, c est un choix afin d éviter une 6

surcharge du diagramme. Nous avons fait un héritage entre Travail d impression et les 3 cas demandant une impression afin d avoir un seul extend points signalant le manque d encre. Le reste est assez clair et compréhensible (selon nous). 3.2 GSM Explications : On a donc le Client qui peut accéder à des Services qui sont soit l envoi d un SMS, soit naviguer sur le WAP soit téléphoner. Nous avons que le Phone Banking hérite du WAP car il permet de faire les mêmes choses, demande également une identification mais il permet également d effectuer des virements et de les gérer. Nous avons la même relation entre SMS et WAP car le WAP permet de faire les mêmes choses que SMS mais avec d autres options supplémentaires et il recquiert une identification. 7

4 Diagrammes de séquence Nous avons réalisé les diagrammes de séquence représentant un client utilisant l ATM. Le premier diagramme est InsCard qui commence donc lorsqu un client insère sa carte dans le lecteur.nous avons choisi un niveau d abstraction relativement élevé. Nous n utilisons en effet pas toujours de variables pour exprimer certaines choses comme par exemple la boucle exprimant que l ATM reste en fonction etc. 4.1 InsCard Dans ce diagramme donc, le lecteur lit la carte, demande un code PIN et le redemande juque 3 fois si l utilisateur se trompe. S il se trompe 3 fois, la carte est simplement avalée et c est terminé. 8

Sinon l utilisateur peut effectuer une transaction (voir le diagramme performtransaction), une fois ses transactions terminées, la session est terminée et la carte est ejectée. 4.2 performtransaction Ce diagramme est assez simple puisqu il ne contient que des références vers d autres diagrammes selon les différents choix disponibles à l utilisateur. L utilisateur a le choix de faire autant de transactions qu il veut tant qu il n a pas appuyé sur quit. (en réalité après un certain timeout, la carte est avalée voir diagramme d état.) Les diagrammes suivant représentent les différentes options disponibles à l utilisateur. 9

4.3 performwithdraw Diagramme symbolisant le retrait d un utilisateur. L ATM se charge de récupérer diverses informations nécessaires au retrait tels que le montant disponible, le montant maximum possible pour un retrait dans la journée courante, le montant minimum possible pour ce compte etc. Il vérifie également si le montant demandé est disponible dans le conteneur de billets de l ATM. Si tout cela est ok, alors le retrait a lieu et la somme est retirée du compte de l utilisateur. 10

4.4 performsaving Ce diagramme représente l accès et éventuellement un transfert du compte courant vers le compte épargne. L ATM se charge alors de récupérer tous les comptes épargnes liés à la carte et les afficher à l écran. On demande alors ce que désire l utilisateur (une consultation simple ou un transfert). Si il choisit de consulter son compte, alors on imprime juste son solde à l écran. Si par contre il choisit un transfert, alors l utilisateur doit entrer le montant qu il désire transferer. On considère que transfertto() se charge de faire toutes les vérifications nécessaires. 11

4.5 performdeposit Ce diagramme représente la séquence relative à un dépot. L ATM attend donc l entrée de billets. Tant que l utilisateur n a pas validé son dépot, l ATM attend que l utilisateur entre encore de l argent. Lors de l introduction de billet, l ATM vérifie l authenticité des billets. Si billet inséré n est pas faux alors l ATM l avale, sinon, il y a refus du billet. Un reçu est imprimé lorsque l utilisateur a validé son dépot. On ajoute le dépot à la liste des transactions du client afin qu un employé de la banque les valide. 12

4.6 performrecap Il s agit ici, tout simplement, de récupérer l historique de l ATM et de l imprimer. 13

4.7 performconsultation Ce diagramme symbolise la consultation du solde du compte courant. Comme pour performwithdraw, l ATM se charge de récupérer les informations nécessaires pour afficher le solde du compte. On demandera à l utilisateur s il souhaite ou non un ticket où son solde est inscrit. 14

4.8 Le module SMS Ce diagramme représente un envoi de SMS au module de l ATM en charge des messages. Une fois le message reçu, le module se charge de traiter le message et d agir en conséquence selon qu il s agisse d une demande de consultation de solde, de devise ou encore d une recharge du compte GSM. 15

4.9 Le serveur téléphonique Ici, l utilisateur doit envoyer ses identifiants. Le serveur se charge alors de vérifier si les identifiants sont corrects. Si c est le cas, alors on propose un menu au client. Le client envoie alors son choix au serveur qui traite sa demande. Tant que l utilisateur n a pas décidé de terminer la communication, le serveur reste à son écoute. 16

4.10 Le module WAP Ce module réagit exactement comme le serveur téléphonique, mis à part qu il intéragit avec l utilisateur via une interface graphique et non pas par la voix. Il s agira donc d un menu textuel qui sera présenté à l utilisateur. Note : Sur ces deux derniers diagrammes, la mise en place d une réponse à une demande est totalement implicite, les méthodes treatrequest() du module WAP et treatdemand() du serveur réalise en effet tout ce qui est vérifications. 17

5 Diagrammes d états Nous ne présenterons ici que les diagrammes d états concernant l écran, le lecteur de carte et le module SMS/WAP/PhoneBanking, les états de l ATM étant assez restreint (ON, OFF et entrain de servir un client). 5.1 Diagramme d état de l écran Screen state représente le diagramme d état de l écran de l ATM en fonction de ce que ce dernier doit afficher. Lorsque l ATM est en standby alors il attend qu une carte soit insérée l écran invite donc les utilisateurs a insérer leur carte. Ensuite si l utilisateur a entré un mauvais pin, l écran l avertit ainsi que lorsqu il a raté 3 fois son PIN, alors on lui affiche que sa carte a été avalée. Sinon, un message d acceuil s affiche. Ensuite on affiche le menu principal et selon le choix que l utilisateur fait, l écran affiche le menu correspondant. Lorsque l utilisateur quitte sa session, un message de remerciement est affiché et l écran revient en standby. 18

5.2 Diagramme d état du lecteur de carte cardreader state symbolise les différents états possibles pour le lecteur de cartes. Ainsi, soit il sera inutilisé, soit il sera occupé. S il est occupé, il commence par lire la carte si le code PIN est correct, alors il attend que l utilisateur ait terminé ses transactions. Sinon le pin est mauvais 3 fois et l appareil avale la carte. S il y a 5 minutes d inactivité la carte est également avalée et enfin, si la carte n est pas lisible alors elle est directement ejectée. 5.3 Diagramme d état du module SMS Dans ce diagramme, le module SMS commence dans un état d attente de SMS. Si un SMS lui parvient, alors, il entre dans un état où il traite ce SMS en fonction de la demande de l utilisateur. Une fois la demande traitée, le résultat est envoyé à l utilisateur, le module est donc dans un état où il envoie des données. Une fois ces données envoyées, le module peut retourner dans son état initial qui est l attente de messages. Les modules pour le WAP et le PhoneBanking présentent une activité similaire, il n y aura donc pas de diagramme à leur consacrer. 19