Embed Size (px)
Citation preview
Application web et mobile de
Mobile Banking
Attijari Bank
Elaboré par
Yasmine TORKHANI Cyrine TAHARI
FilièreLicence Fondamentale en Informatique de Gestion
Encadré par
Encadrant pédagogique Encadrants professionnels M. Mohamed Hedi AMLOUK
M. Hosni Kricha
Année Universitaire
2014 – 2015
Ministère de l’Enseignement Supérieur
Et de la Recherche Scientifique Université de Tunis
Institut Supérieur de Gestion
Mme. Nadia YACOUBI
Dédicaces
Je dédie ce modeste travail et ma profonde gratitude :À mon père et ma mère
Pour l’amour, l’affection et la bienveillance dont ils m’entouraient ; pour les efforts et les sacrifices qu’ils ont dû faire.
Pour leurs patiences et leurs encouragements..."Je vous dois ce que je suis aujourd’hui et ce que je serai demain et je ferai
toujours de mon mieux pour rester votre fierté et ne jamais vous décevoir.."
Qu’ils trouvent dans ce travail un humble témoignage de ma gratitude et de ma reconnaissance.
À ma grande famille qui a cru en moi, à mes cousins et cousines…À tous mes amis qui m’ont soutenu tout au long de mon parcours
À tous mes professeurs pendant mon parcours de l’école vers l’université.À toute personne qui a gravé ma vie par un mot qui m’a orienté vers le
bon chemin…
Cyrine TAHARI
Dédicaces
Je dédie ce modeste travail et ma profonde gratitude :À mon père et ma mère
Autant de phrases aussi expressives soient-elles ne sauraient montrer le degré d’amour et d’affection que j’éprouve pour eux.
Merci pour tout l'amour et la confiance et pour votre énorme support pendant la rédaction de mon projet.
A mon frère YoussefPour sa patience, son amour et ses encouragements.
A ma sœur HaifaSans ses conseils et son amour je serai perdue
A NilouPour ses encouragements continus et sa confiance énorme en moi.
A tous les membres de ma famille, petits et grands, veuillez trouver dans ce modeste travail l'expression de mon affectation.
A tous mes amis et mes collègues qui m’ont soutenu.
Yasmine TORKHANI
Remerciements
Nous tenons, tout d’abord, à remercier Dieu le tout puissant et miséricordieux, qui nous a
donné la force et la patience d’accomplir ce modeste travail.
Au terme de notre projet de fin d’études, qu’il nous soit permis d’exprimer nos
sentiments de gratitude aux différentes personnes qui nous ont encadrés et soutenues tout
au long de notre travail rendant ainsi possible l’accomplissement du présent projet.
Nous tenons tout particulièrement à exprimer notre profonde gratitude et respect à
Monsieur Mohamed El Hedi AMLOUK, de nous avoir offert l’opportunité d’effectuer notre
stage au sein d'Attijari Bank.
Notre profonde gratitude s’adresse également à Monsieur Hosni KRICHA qui, en
dépit de ses multiples occupations et sollicitations, nous a été d'une aide judicieuse.
Notre profonde gratitude s’adresse tout particulièrement à Madame Nadia YACOUBI,
qui a accepté de diriger, de lire et d’apporter des correctifs à ce travail sans oublier ses
conseils et suggestions éclairées.
Nos remerciements s’adressent aussi à toutes l'équipe du département informatique
d'Attijari Bank qui nous a accompagné et aidé d’une manière et d’une autre à la réalisation
du présent travail.
Table des matièresIntroduction générale.....................................................................................................................................1
Chapitre 1 Cadre du projet.............................................................................................................................3
1.1. Introduction......................................................................................................................................3
1.2 Présentation de l’organisme d’accueil.............................................................................................3
1.3 Analyse de l’existant.........................................................................................................................3
1.4 Solutions envisagées..........................................................................................................................4
1.5 Travail à faire....................................................................................................................................4
1.6 Méthodologie et formalisme adoptés...............................................................................................6
1.6.1. Scrum........................................................................................................................................6
1.7 Conclusion.......................................................................................................................................10
Chapitre 2 Sprint 0.......................................................................................................................................11
2.1. Introduction....................................................................................................................................11
2.2. Capture des besoins........................................................................................................................11
2.2.1 Identification des acteurs.......................................................................................................11
2.2.2 Description des acteurs..........................................................................................................12
2.3. Les besoins fonctionnels.................................................................................................................12
2.4. Les besoins non fonctionnels..........................................................................................................13
2.5. Backlog du produit.........................................................................................................................14
2.6. Planification des Releases...............................................................................................................22
2.7. Identification de l’équipe Scrum...................................................................................................23
2.8. Diagramme de cas d’utilisation initial..........................................................................................23
2.9. Technologies et outils de développement......................................................................................24
2.9.1 Présentation du système d’exploitation mobile Android....................................................24
2.9.2 Architecture de l’application Front Office...........................................................................25
2.9.3 Framework et développement de l’application Back Office...............................................26
2.10. Environnement technique du travail.............................................................................................28
2.10.1 Outil de conception.................................................................................................................29
2.10.2 Outils de développement........................................................................................................29
2.10.3 Langages de programmation.................................................................................................30
2.10.4 Langage de modélisation :.....................................................................................................31
2.11. Conclusion.......................................................................................................................................31
Chapitre 3Développement de l'application Front Office............................................................................32
3.1. Introduction.........................................................................................................................................32
3.2. Sprint 1 : Authentification..................................................................................................................32
3.2.1 Sprint planning ou planification du sprint..................................................................................32
3.2.2 Spécification fonctionnelle.............................................................................................................33
3.2.2.1 Diagramme de Cas d'utilisation............................................................................................33
3.2.2.2 Description textuelle...............................................................................................................33
3.2.3 Conception.......................................................................................................................................34
3.2.4 Test...................................................................................................................................................38
3.2.5 Sprint planning ou planification du sprint...................................................................................40
3.2.6Spécification fonctionnelle.............................................................................................................41
3.2.6.1 Diagramme de Cas d'utilisation............................................................................................41
3.2.6.2 Description textuelle...............................................................................................................42
3.2.7Conception.......................................................................................................................................44
3.2.8 Test...................................................................................................................................................52
3.3. Sprint 3: Accès aux services publics..................................................................................................54
3.3.1 Sprint planning ou planification du sprint...................................................................................55
3.3.2 Spécification fonctionnelle.............................................................................................................56
3.3.2.1 Diagramme de Cas d'utilisation............................................................................................56
3.3.2.2 Description textuelle...............................................................................................................57
3.3.3 Conception.......................................................................................................................................59
3.3.4Test...................................................................................................................................................68
3.4. Conclusion.......................................................................................................................................71
Chapitre 4 Développement de l'application Backoffice..............................................................................72
4.1. Introduction.........................................................................................................................................72
4.2. Sprint 1 : Administration...................................................................................................................72
4.2.1 Sprint planning ou planification du sprint...................................................................................72
4.2.2 Spécification fonctionnelle.............................................................................................................73
4.2.2.1 Diagramme de Cas d'utilisation............................................................................................74
4.2.2.2 Description textuelle...............................................................................................................75
4.2.3 Conception.......................................................................................................................................75
4.3. Sprint 2: Gestion des demandes transactionnelles (Cartes, Chéquiers, Virements)......................80
4.3.1 Sprint planning ou planification du sprint...................................................................................80
4.3.2 Spécification fonctionnelle.............................................................................................................82
4.3.2.1 Diagramme de Cas d'utilisation............................................................................................82
4.3.2.2 Description textuelle...............................................................................................................84
4.3.3 Conception.......................................................................................................................................85
4.3.4 Test...................................................................................................................................................88
4.4. Sprint 3: Gestion des contacts............................................................................................................89
4.4.1 Sprint planning ou planification du sprint...................................................................................89
4.4.2 Spécification fonctionnelle.............................................................................................................90
4.4.2.1 Diagramme de Cas d'utilisation............................................................................................90
4.4.2.2 Description textuelle...............................................................................................................90
4.4.3 Conception.......................................................................................................................................91
4.4.4 Test...................................................................................................................................................95
4.5. Conclusion.......................................................................................................................................96
Chapitre 5 Codage et déploiement...............................................................................................................97
5.1. Introduction.........................................................................................................................................97
5.2. Codage..................................................................................................................................................97
5.2.1 Diagramme de composants............................................................................................................97
5.2.1.1 Diagrammes de composants de M1.......................................................................................97
5.2.1.2 Diagrammes de composants de M2.......................................................................................98
5.2.2 Diagramme de classes global de l’application..............................................................................99
5.2.3 Schéma de la base de données......................................................................................................100
5.3. Déploiement.......................................................................................................................................111
5.3.1 Diagramme de déploiement de M1..............................................................................................111
5.3.2 Diagramme de déploiement de M2..............................................................................................112
5.4. Conclusion..........................................................................................................................................112
Conclusion et perspective...........................................................................................................................113
Annexe A....................................................................................................................................................114
Neto graphie...............................................................................................................................................115
Liste des figures
FIGURE 1 : LE DÉROULEMENT D’UNE ITÉRATION [1]...............................................................................8FIGURE 2 : DÉROULEMENT D’UN SPRINT [2].............................................................................................10FIGURE 3 : HÉRITAGE ENTRE LES ACTEURS.............................................................................................11FIGURE 4 : SCHÉMA DE RELEASES..............................................................................................................22FIGURE 5: DIAGRAMME DE CAS D’UTILISATION GLOBAL DE L’APPLICATION...............................23FIGURE 6 : ETUDE COMPARATIVE DES SYSTÈMES D’EXPLOITATION MOBILE SUR LE MARCHÉ
[3]................................................................................................................................................................24FIGURE 7:ARCHITECTURE GÉNÉRALE DE L’APPLICATION MOBILE [4].............................................25FIGURE 8: ARCHITECTURE GÉNÉRALE D'APPLICATION WEB [5].........................................................26FIGURE 9: DIAGRAMME DE CAS D’UTILISATION GLOBAL SPRINT 1...................................................33FIGURE 10 : DIAGRAMME DE CLASSES DU CAS D’UTILISATION «S’AUTHENTIFIER».....................35FIGURE 11: DIAGRAMME DE SÉQUENCES DU CAS D’UTILISATION «S'AUTHENTIFIER»...............36FIGURE 12 DIAGRAMME DE CLASSES DU CAS D’UTILISATION «MODIFIER MOT DE PASSE»......37FIGURE 13 DIAGRAMME DE SÉQUENCES DU CAS D’UTILISATION «MODIFIER MOT DE PASSE». 38FIGURE 14 : INTERFACE PRINCIPALE DE L’APPLICATION MOBILE.....................................................39FIGURE 15: INTERFACE D’AUTHENTIFICATION.......................................................................................39FIGURE 16: INTERFACE DE MODIFICATION DU MOT DE PASSE...........................................................39FIGURE 17: DIAGRAMME DE CAS D’UTILISATION GLOBAL SPRINT 2.................................................42FIGURE 18: DIAGRAMME DE CLASSES DU CAS D’UTILISATION «CONSULTER L’EXTRAIT DE
COMPTE»...................................................................................................................................................45FIGURE 19: DIAGRAMME DE SÉQUENCES DU CAS D’UTILISATION «CONSULTER L’EXTRAIT DU
COMPTE»...................................................................................................................................................46FIGURE 20: DIAGRAMME DE CLASSE DU CAS D'UTILISATION «DEMANDER UNE CARTE
BANCAIRE»...............................................................................................................................................47FIGURE 21: DIAGRAMME DE SÉQUENCES DU CAS D’UTILISATION «DEMANDER UNE CARTE
BANCAIRE»...............................................................................................................................................48FIGURE 22: DIAGRAMME DE CLASSES DU CAS D'UTILISATION «OPPOSER UNE CARTE
BANCAIRE»...............................................................................................................................................49FIGURE 23: DIAGRAMME DE SÉQUENCES DU CAS D’UTILISATION «OPPOSER UNE CARTE
BANCAIRE»...............................................................................................................................................50FIGURE 24: DIAGRAMME DE CLASSES DU CAS D'UTILISATION «CONSULTER LA BOITE DE
RÉCEPTION».............................................................................................................................................51FIGURE 25: DIAGRAMME DE SÉQUENCES DU CAS D’UTILISATION «CONSULTER LA BOITE DE
RÉCEPTION».............................................................................................................................................52FIGURE 26 : INTERFACE DU MENU PRINCIPAL.........................................................................................53FIGURE 27 : INTERFACE DE CONSULTATION DES COMPTES BANCAIRES.........................................53FIGURE 28 : INTERFACE DE CONSULTATION DE L’EXTRAIT BANCAIRE...........................................53FIGURE 29 INTERFACE DE DEMANDE D’UNE CARTE..............................................................................54FIGURE 30: DIAGRAMME DE CAS D’UTILISATION GLOBAL SPRINT3..................................................57FIGURE 31: DIAGRAMME DE CLASSES DU CAS D’UTILISATION «SUIVRE LES COURS DE
DEVISE».....................................................................................................................................................60FIGURE 32: DIAGRAMME DE SÉQUENCES DU CAS D’UTILISATION «SUIVRE LES COURS DE
DEVISE».....................................................................................................................................................60
FIGURE 33: DIAGRAMME DE CLASSES DU CAS D’UTILISATION «CONTACTER LA BANQUE»......61FIGURE 34: DIAGRAMME DE SÉQUENCES DU CAS D’UTILISATION «CONTACTER LA BANQUE»
PARTIE1.....................................................................................................................................................63FIGURE 35 : DIAGRAMME DE SÉQUENCES DU CAS D’UTILISATION «CONTACTER LA BANQUE»
PARTIE2.....................................................................................................................................................64FIGURE 36: DIAGRAMME DE CLASSES DU CAS D’UTILISATION «CONSULTER LE SYSTÈME DE
GÉOLOCALISATION»..............................................................................................................................65FIGURE 37: DIAGRAMME DE SÉQUENCES DU CAS D’UTILISATION «CONSULTER LE SYSTÈME DE
GÉOLOCALISATION ».............................................................................................................................66FIGURE 38 : DIAGRAMME DE CLASSES DU CAS D'UTILISATION «CONSULTER LA LISTER DES
POINTS DE CONTACT»............................................................................................................................67FIGURE 39: DIAGRAMME DE SÉQUENCES DU CAS D’UTILISATION «CONSULTER LA LISTER DES
POINTS DE CONTACT»............................................................................................................................68FIGURE 40 : INTERFACE DU MENU PUBLIC...............................................................................................69FIGURE 41 : INTERFACE DE SUIVI DES COURS DE DEVISE....................................................................69FIGURE 42: INTERFACE DE CONSULTATION DE LA LISTE DES RÉGIONS...........................................70FIGURE 43: INTERFACE DE CONSULTATION DE LA LISTE DES AGENCES.........................................70FIGURE 44 : INTERFACE D’ENVOI D’UN POUR UN ABONNÉ..................................................................70FIGURE 45: INTERFACE D’APPEL.................................................................................................................70FIGURE 46 : DIAGRAMME DE CAS D’UTILISATION GLOBAL DU SPRINT 1.........................................74FIGURE 47 : DIAGRAMME DE CAS D’UTILISATION «GÉRER LES AGENCES».....................................74FIGURE 48 : DIAGRAMME DE CLASSES DU CAS D’UTILISATION «GÉRER LES AGENCES».............76FIGURE 49 : DIAGRAMME DE SÉQUENCES DU CAS D’UTILISATION «GÉRER LES AGENCES»......77FIGURE 50 : INTERFACE PRINCIPALE DE LA GESTION DES AGENCES................................................78FIGURE 51 : INTERFACE DE L’OPÉRATION DE SUPPRESSION D’UNE AGENCE.................................79FIGURE 52 : INTERFACE DE L’OPÉRATION D’AJOUT D’UNE AGENCE.................................................79FIGURE 53 : INTERFACE DEL’OPÉRATION DE MODIFICATION DES COORDONNÉES D’UNE
AGENCE.....................................................................................................................................................80FIGURE 54 : DIAGRAMME DE CAS D’UTILISATION GLOBALE SPRINT2..............................................83FIGURE 55 : DIAGRAMME DE CAS D’UTILISATION «GÉRER LES DEMANDE DE CARTES».............83FIGURE 56 : DIAGRAMME DE CLASSES DU CAS D’UTILISATION «GÉRER LES DEMANDES DE
CARTE»......................................................................................................................................................86FIGURE 57: CAS D'UTILISATION GÉNÉRÉ «GÉRER LES DEMANDES D'OBTENTION ».....................87FIGURE 58 : INTERFACE DE LA GESTION DES DEMANDES D’OBTENTION.........................................88FIGURE 59 : CONSULTATION DES DEMANDES DE CARTES...................................................................88FIGURE 60 : DIAGRAMME DE CAS D’UTILISATION GLOBAL SPRINT3.................................................90FIGURE 61 : DIAGRAMME DE CLASSE DU CAS D’UTILISATION «GESTION DES CONTACTS»........92FIGURE 62 DIAGRAMME DE SÉQUENCES DU CAS D’UTILISATION «GÉRER LES MESSAGES»......94FIGURE 63 : INTERFACE DE LA GESTION DE LA LISTE DES RENDEZ-VOUS......................................95FIGURE 64 : INTERFACE DE LA GESTION DES RENDEZ-VOUS..............................................................95FIGURE 65 : DIGRAMME DE COMPOSANTS DU MODULE M1................................................................98FIGURE 66 : DIAGRAMME DE COMPOSANTS DU MODULE M2..............................................................98FIGURE 67 : DIAGRAMME DE CLASSE GLOBAL DE L’APPLICATION...................................................99FIGURE 68 : DIAGRAMME DE DÉPLOIEMENT DE M1.............................................................................112FIGURE 69 : DIAGRAMME DE DÉPLOIEMENT DE M2.............................................................................112
Liste des tableaux
TABLEAU 1 : DESCRIPTION DÉTAILLÉE DES ACTEURS..........................................................................12TABLEAU 2: PRODUCT BACKLOG................................................................................................................16TABLEAU 3: IDENTIFICATION DE L’ÉQUIPE SCRUM...............................................................................23TABLEAU 4: DESCRIPTION DES MACHINES DE DÉVELOPPEMENT......................................................28TABLEAU 5: SPRINT 1 BACKLOG.................................................................................................................33TABLEAU 6: DESCRIPTION TEXTUELLE DE CAS D’UTILISATION «S’AUTHENTIFIER»....................34TABLEAU 7 :SPRINT2 BACKLOG..................................................................................................................40TABLEAU 8 : DESCRIPTION TEXTUELLE DU CAS D’UTILISATION «CONSULTER L’EXTRAIT DU
COMPTE»...................................................................................................................................................42TABLEAU 9: DESCRIPTION TEXTUELLE DU CAS D’UTILISATION «DEMANDER UNE CARTE
BANCAIRE»...............................................................................................................................................43TABLEAU 10: DESCRIPTION TEXTUELLE DU CAS D’UTILISATION «CONSULTER LA BOITE
RÉCEPTION».............................................................................................................................................44TABLEAU 11 : SPRINT3 BACKLOG................................................................................................................55TABLEAU 12 : DESCRIPTION DU CAS D’UTILISATION «ACCÉDER AUX SERVICES PUBLIC
D’ATTIJARI BANK»..................................................................................................................................57TABLEAU 13: DESCRIPTION DU CAS D’UTILISATION «CONTACTER LA BANQUE».........................58TABLEAU 14 : SPRINT1 BACKLOG................................................................................................................73TABLEAU 15 : DESCRIPTION TEXTUELLE DU CAS D’UTILISATION «GÉRER LES AGENCES»........75TABLEAU 16 : SPRINT2 BACKLOG................................................................................................................81TABLEAU 17 : DESCRIPTION TEXTUELLE DU CAS D’UTILISATION «GÉRER LES DEMANDE
D'OBTENTION».........................................................................................................................................84TABLEAU 18 : SPRINT3 BACKLOG................................................................................................................89TABLEAU 19 : DESCRIPTION TEXTUELLE DU CAS D’UTILISATION «GÉRER LES DEMANDES DE
RENDEZ-VOUS»........................................................................................................................................91TABLEAU 20 : DESCRIPTION TEXTUELLE DU CAS D'UTILISATION «GÉRER LES MESSAGES»......91TABLEAU 21 TABLE « ABONNE »...............................................................................................................100TABLEAU 22 : TABLE « REGION »...............................................................................................................100TABLEAU 23: TABLE « CLIENT »................................................................................................................101TABLEAU 24 : TABLE « COMPTE »..............................................................................................................101TABLEAU 25 : TABLE « AGENT »................................................................................................................102TABLEAU 26 : TABLE «PARAMETRE»........................................................................................................102TABLEAU 27 : TABLE «AGENCE»................................................................................................................103TABLEAU 28 : TABLE «DAB»"......................................................................................................................103TABLEAU 29 : TABLE «DDE_CARTE».........................................................................................................104TABLEAU 30 : TABLE «MOUVEMENT»......................................................................................................104TABLEAU 31 : TABLE «DDE_CHEQ»...........................................................................................................105TABLEAU 32 : TABLE « DE_OP_CARTE»...................................................................................................105TABLEAU 33 : TABLE «DDE_OP_CHEQ»....................................................................................................106TABLEAU 34 : TABLE «CHEQUIER»............................................................................................................106TABLEAU 35 : TABLE «DDE_VIR»...............................................................................................................107TABLEAU 36 TABLE «MESSAGE»...............................................................................................................108TABLEAU 37 : TABLE «CHEQUE»................................................................................................................109
TABLEAU 38 : TABLE «TYPCARTE»...........................................................................................................109TABLEAU 39 : TABLE «RENDEZVOUS».....................................................................................................110TABLEAU 40 : TABLE «CARTE»...................................................................................................................111
Introduction générale
1
Le marché des téléphones intelligents ou « Smartphone » est un marché en plein essor avec
plus d’un milliard de téléphones vendu dans le monde en 2014.
Ces téléphones mobiles dotés d’une intelligence équivalente à celle d’un ordinateur ne sont
plus seulement un moyen de communication, mais aussi un outil pour faciliter la vie de tous
les jours. Les utilisateurs ne peuvent plus s’en passer, il y en a même qui les considèrent
comme leurs meilleurs amis, car ils représentent pour eux une source d’information de tout ce
qui se passe autour d’eux, un moyen de divertissement, mais aussi un outil de travail.
Afin d'élargir les canaux de communication avec les clients, les banques n'ont pas fait figure
d'exception à cette émergence et ont investi dans le domaine de Smartphone en inventant le
concept de Mobile Banking.
En effet, le mobile Banking signifie l'ensemble des services bancaires tels que la consultation
de soldes, des extraits bancaires, les demandes d'opposition ou d'obtention sur cartes ou sur
chéquiers ... qui sont accessibles par un terminal mobile.
Dans ce contexte, notre projet de fin d’études a pour but de concevoir et développer une
application de mobile banking comprenant deux parties:
Une application mobile pour les utilisateurs de M-banking qui constitue le front office.
Une application web pour l'administration, dédiés aux employés de la banque qui
constitue le Back office.
Notre travail s’intitulant « Conception et développement d’une application web et mobile de
Mobile Banking » est composé de cinq chapitres :
Dans le premier chapitre, nous présenterons le cadre de notre projet.
Le deuxième chapitre présentera notre sprint 0 ou encore la phase de préparation où nous
détaillerons les technologies que nous allons manipulé tout au long de notre projet.
Le troisième chapitre portera sur le les étapes de développement du front office et le
quatrième chapitre sur les étapes de développement du back office.
Et notre dernier chapitre, sera dédié à la partie déploiement et codage de notre application où
nous allons détaillé l'architecture des deux applications et le schéma de la base de données.
Nous finirons par une conclusion générale ainsi que la proposition de quelques perspectives.
2
Chapitre 1 Cadre du projet
1. Introduction
Pour la gestion des opérations financières, l’échange d'information avec la banque, le
téléphone mobile (ou la tablette utilisée en mobilité comme un Smartphone) est un média plus
pratique, plus immédiat et plus simple. Nous vivons à une époque où la technologie mobile
est omniprésente. Le téléphone mobile occupe une place centrale dans cette évolution
technologique rendant possible l’accès aux réseaux n’importe où et n’importe quand.
Ainsi, étant donnée le nombre croissant de téléphones portables en usage, il est intéressant
d’en faire un canal principal pour matérialiser ce qui constitue l’ossature d’une relation fidèle
à sa banque : gérer ses comptes, accéder aux services bancaires essentiels où, quand et comme
l’on veut.
3
2 Présentation de l’organisme d’accueil
Attijari Bank Tunisie est une banque tunisienne détenant le réseau d’agences le plus important
en Tunisie et classée troisième banque privée en terme de dépôt et d’engagement. Elle est
fortement présente sur l’ensemble des segments de marchés particuliers, professionnels et
entreprises. En vue de se positionner sur le marché tunisien en tant qu’acteur de référence,
Attijari Bank a conçu un plan de développement stratégique visant la réalisation d’objectifs
ambitieux à l'horizon 2015.
A travers la mise en place de son projet de développement, elle a contribué d’une façon active
à la performance du système bancaire tunisien et à la croissance du pays notamment grâce à
l’appui de ses partenaires. Outre son implication dans le développement économique du pays,
son projet s’inscrit dans une logique de coopération économique entre les pays du Maghreb.
3 Analyse de l’existant
L’analyse de l’existant consiste à présenter les services diversifiés d’Attijari Bank tel que, la
consultation de solde, la prise de rendez-vous, le suivi de la bourse .... En effet, ces services
offerts par Attijari Bank peuvent se faire de deux manières à savoir : Le mode classique et le
mode à distance.
Pour le premier mode, Attijari Bank met à la disposition de ses clients des agences pour servir
leurs besoins. Les guichets de l’agence émettrice proposent des services qui conviennent aux
besoins de ces clients.
Concernant le second mode, Attijari Bank met à la disposition de ses clients un service de
consultation et virement bancaire via internet. En effet, le client doit passer par le site web
d’Attijari Bank1 et choisir le service désiré ayant des paramètres d’authentification fournis
préalablement par son agence. Dans le but d’interagir d’avantage avec les clients et d’en
attirer des nouveaux, Attijari Bank décide de développer des services bancaires pour mobile.
4 Solutions envisagées
Depuis le milieu des années 2000, les plus grandes banques mondiales commencent à investir
dans le Mobile Banking appelé aussi M-Banking. Rappelons que le «M-Banking désigne une
spécificité du Mobile Business adaptée au métier de la Banque. Il s’agit du traitement des
services bancaires à travers le mobile» [1]
1 Site Officiel : http://www.attijaribank.com.tn/Fr/
4
Attijari Bank nous a confié la tâche de concevoir et de développer une application web et
mobile. C’est dans ce contexte que vient s’inscrire notre projet de fin d’études.Il s’agit en fait
d’une application Android M-Banking permettant à sa clientèle de bénéficier des services
bancaires qu’elle offre sur un terminal mobile (Smartphone, tablette..) d’où vient le concept
de l'informatique ubiquitaire.
«Les systèmes dits ubiquitaires supportent la mobilité de l'utilisateur. Le principal intérêt de
ces systèmes est de s’adapter à l'environnement de l'homme (géo localisation, disponibilité
des réseaux de communication, identification de l'utilisateur ...). En d'autre termes, c'est le
système qui s'adapte à l'Homme, et pour y arriver le système se doit d'être présent partout et
en temps réel.» [2] D'où le nom du guichet virtuel dans le secteur bancaire permettant
d’assurer ces trois principes :
A ny Time : continuité de service, au besoin du client.
A ny Where : à la maison, au travail, à l'extérieur, en Tunisie, à l'étranger.
A ny Acces : multi canaux.
5 Travail à faire
Le travail à faire est de concevoir et développer une application de M-Banking que nous
avons nommée «Attijari Mobile Banking». Il s’agit d’une application divisée en deux
modules : un premier dédié au Front Office et un second pour le Back Office.
M1 : Front Office
Une application Android qui sera installée sur un terminal mobile développé en langage de
programmation JAVA dédiée à la fois aux clients d’Attijari Bank et aux clients potentiels. En
effet, l’application mobile permet aux clients d'Attijari Bank de:
Accéder à des relevés bancaires électroniques
Demander et/ou opposer un chéquier.
Demander et/ou opposer une carte bancaire.
Effectuer des virements simples intra-bancaires.
Consulter la boite de notifications.
En plus, notre application s'adresse aux clients des autres banques qui seront traités comme
des clients potentiels. On leur offre un ensemble de fonctionnalités qui pourront servir dans
leur vie quotidienne mais aussi bien pour les tenir au courant des actualités de la banque et
5
leur aider à trouver des agences ou des DAB d'Attijari Bank en cas de besoin. Nos solutions
permettent à tous les utilisateurs de l'application de :
Trouver et lister les agences et les DAB.
Suivre les actualités de la banque.
Suivre le marché de la bourse.
Suivre les cours des devises.
Simuler des crédits et des placements.
Contacter la banque soit par message, par téléphone ou en demandant un rendez-vous auprès de notre service clientèle.
M2 : Back Office
Pour cela, nous avons prévu une plateforme web J2EE pour l’administration de l’application
mobile. En effet, le Back Office désigne l'ensemble des parties du système
d’information auxquelles l'utilisateur final n'a pas accès. C'est la partie, que les employés
d'Attijari Bank doivent assurer le bon fonctionnement de l'application mobile.
La mise à jour de la base de données et de l'application mobile, l'approbation des demandes
clients, le contrôle d'identité et la communication avec les clients, sont les principales
fonctionnalités de cette application web.
6 Méthodologie et formalisme adoptés
Dans le cadre de ce projet, nous nous sommes intéressées à l’adoption d’une approche Agile.
«Une méthode agile est une approche itérative et incrémentale, qui est menée dans un esprit
collaboratif, avec juste ce qu’il faut de formalisme. Elle génère un produit de haute qualité
tout en prenant en compte l’évolution des besoins des clients.» [3]
Ce sont des méthodologies essentiellement dédiées à la gestion de projets informatiques. Elles
reposent sur des cycles de développement itératifs et adaptatifs en fonction des besoins
évolutifs du client. Elles permettent notamment d'impliquer l'ensemble des collaborateurs
ainsi que le client dans le développement du projet.
Ces méthodes permettent généralement de mieux répondre aux attentes du client en un temps
limité (en partie grâce à son implication) tout en faisant monter les collaborateurs en
compétences.
On citera comme méthodes de développement Agile :
• Scrum
6
• Extreme Programming
• Adaptive Software Development (ASD)
• Dynamic System Development Method (DSDM)
Nous nous sommes intéressées à la méthode Scrum.
6.1. Scrum« La méthode SCRUM définit un cadre de travail permettant la réalisation de projets
complexes. Initialement prévu pour le développement de projets type « Software », cette
méthode peut être appliquée à tout type de projet, du plus simple au plus innovant, et ce de
manière très simple.»[4] Cette méthodologie permet de s’adapter rapidement aux
changements d’un client à fréquence régulière. Chaque fin d'itération, l'équipe et le client
réévaluent les spécifications du logiciel.
Pourquoi Scrum ?
Avant, le client ne voyait pas l’évolution du travail et n’était pratiquement pas impliqué
pendant l’exécution de son projet. En effet il ne pouvait pas commencer à faire des tests avant
que tout soit presque fini. Par contre en Scrum, le client est plus impliqué dans le processus
car un projet contient plusieurs livrables qu'il doit approuver. A chaque livrable les
fonctionnalités sont en amélioration continue et le client voit régulièrement l'évolution des
travaux et si quelque chose ne lui convient pas, il est plus facile de l'ajuster pour satisfaire ses
besoins. Donc Scrum vise essentiellement à optimiser la prévisibilité d'un projet et à mieux
contrôler les risques.
Les intervenants dans Scrum
La méthode Scrum définit trois rôles pour un projet:
o Le Product Owner
Il s'agit du représentant officiel du client au sein d'un projet Scrum. Il définit les
besoins du produit et rédige les spécifications. Il est également chargé de définir et
prioriser les users stories pour chaque sprint.
o Le Scrum Master
Il s'agit d'une personne chargée de veiller à la mise en application de la méthode et au
respect de ses objectifs. Il ne s'agit pas d'un chef de projet, mais d'une personne chargée
7
de lever les obstacles éventuels qui empêcherait l'avancement de l'équipe et du projet
pendant les différents sprints.
o Team Members
Ce sont les personnes chargées de la réalisation du sprint et d'un produit utilisable en
fin de sprint. Il peut s'agir de développeurs, architectes, personnes chargées de faire des
tests fonctionnels…
Sprint
Scrum s'appuie sur le découpage des projets en itérations encore nommées «Sprints».Un
Sprint est une période durant laquelle une fonctionnalité (ou incrément du projet) est réalisée.
Il peut avoir une durée qui varie généralement entre deux semaines et un mois. Cette courte
durée permet de livrer rapidement au propriétaire du produit un incrément de logiciel
comportant le plus de valeur d’affaire. Le logiciel livré a de la valeur pour le propriétaire du
produit puisque les fonctionnalités développées sont celles qui ont la plus haute priorité, celles
se trouvant en tête du carnet de produit. Un autre avantage de la courte durée des itérations est
de permettre au propriétaire du produit de modifier les priorités des fonctionnalités
demandées au fur et à mesure de l’avancement du projet de développement. En effet, s'il
désire ajouter des fonctionnalités, celles-ci seront potentiellement prises en compte lors de la
prochaine itération. À la fin de chaque sprint, les membres de l’équipe obtiennent un produit
partiel potentiellement livrable et le feedback récolté permet d’ajuster le backlog pour le
sprint suivant.En soi, Scrum ne suggère que trois jalons2: la planification d'itération (sprint
planning), la mêlée quotidienne (daily Scrum) et la revue d'itération (sprint review). Durant
ces derniers, il y a production de trois artéfacts « de gestion » : le carnet de produit priorisé
(product backlog), le carnet d'itération.
La figure 1 schématise le cycle de vie d’un projet Scrum
2Un jalon (ou, en anglais milestone), dans le cadre de la gestion de projet, est la fin d'une étape, la fin d'un travail.
8
Figure 1 : Le déroulement d’une itération [1]
Les artéfacts de Scrum
o Product Backlog (Carnet de produits)
Scrum débute avec un produit backlog, qui est une liste des requis priorisés partagé et
détenu par le Product Owner, «User Stories» ou «Uses Cases».Le propriétaire du produit
est responsable de prioriser les fonctionnalités. Ces derniers servent à articuler et à
finaliser ce que le client désire obtenir. Des nouvelles fonctionnalités peuvent être
ajoutées ou retirées à tout moment du carnet de produit. Cette flexibilité offerte au
propriétaire du produit est un grand avantage de Scrum.
o Sprint Backlog (Carnet d'itération)
A chaque sprint, on choisit une partie des fonctionnalités du backlog de produit pour les
réaliser.
La réalisation de ces fonctionnalités doit permettre d'atteindre un objectif de sprint
défini au début de celui-ci. Chaque fonctionnalité est alors découpée en tâches qui
pourront être réalisées par différents membres de l'équipe.
o Burn Down Chart (Graphique d’avancement)
Le graphique d'avancement d'itération permet aux équipes de voir leur avancement par
rapport au travail engagé dans l'itération en cours. L’axe vertical présente la quantité
de travail à faire et l’axe horizontal les jours de travail.
Les activités d'un sprint
9
o Planification d'itération «Sprint Planning»
Lors de cette réunion, l’équipe discute des objectifs du sprint et décide de ce qui sera
accompli pendant cette période. À la fin de la réunion, l’équipe s’engage à livrer une ou
plusieurs fonctionnalités.
o Mêlée quotidienne «Daily Scrum Meeting»
La mêlée quotidienne est une rencontre de courte durée où l'équipe fait un compte rendu
de son avancement vers l’atteinte de l’objectif de l’itération. Chaque membre de l'équipe
répond à trois questions :
• Qu'as-tu accompli depuis la dernière mêlée?
• Que vas-tu accomplir jusqu'à la prochaine mêlée?
• Est-ce que des éléments te bloquent dans ton avancement?
Et si on doit obtenir des informations de la part du client, c’est le product owner qui doit
s’assurer de le contacter pour obtenir les réponses.
o Revue d'itération «Sprint Review»
La revue d'itération se fait à la fin du cycle de développement de l'itération et permet au
propriétaire du produit de prendre connaissance des fonctionnalités qui ont été
développées durant l'itération. À la revue d'itération, le propriétaire évalue si le produit
qui lui est présenté correspond bien à l’engagement de livraison pris par l’équipe lors de
la séance de planification de l’itération. Après la revue d'itération, une nouvelle itération
débute et relance ainsi le cycle de planification, développement et revue.
La figure 2 explique le déroulement d'un Sprint
Figure 2 : Déroulement d’un sprint [2]
10
7 Conclusion
Dans ce premier chapitre, nous avons commencé par présenter notre organisme d'accueil
Attijari Bank. Ensuite, nous avons décrit le contexte du projet et la solution proposée qui
constituera le sujet de notre projet. Enfin, après avoir choisi Scrum comme méthodologie de
gestion de projet, nous nous dirigerons naturellement vers le Sprint 0.
11
Chapitre 2 Sprint 0
1. Introduction
Le principe de base de Scrum est de se focaliser de façon itérative sur un ensemble de
fonctionnalités à réaliser dans chaque sprint. Dans ce chapitre, la première phase de Scrum
qui est le Sprint 0 sera présentée. Il s’agit en fait d’une phase de planification et architecture
qui ne se termine pas nécessairement par une livraison. Les travaux réalisés dans cette période
conduits à construire une bonne vision du produit, identifier les rôles des utilisateurs, dégager
les fonctionnalités principales, préparer l’environnement de développement et déterminer un
plan de Release afin de produire le Product Backlog initial ainsi qu'une première planification
des sprints.
2. Capture des besoins
Nous procéderons par l’identification des acteurs puis la description des histoires utilisateurs
de la future application.
2.1 Identification des acteurs
Les deux acteurs principaux de l'application Attijari Mobile Banking sont :
Client d'Attijari Bank
Client potentiel d'Attijari Bank
En tenant compte des fonctionnalités offertes en commun pour les deux acteurs, il existe un
autre plus général «Utilisateur M-Banking» avec lequel ils constituent une relation d’héritage.
La figure 3 illustre la relation d'héritage entre les acteurs:
12Figure 3 : Héritage entre les acteurs
2.2 Description des acteursLe tableau 1 définit les acteurs de l'application Attijari Mobile Banking ainsi que leurs rôles.
Acteur Définition Rôle
Client d'Attijari Bank Tout client de la banque possédant le pack « Mobile Banking » afin de pouvoir utiliser l'application Attijari Mobile Banking
-Il s’authentifie afin qu’il puisse accéder à son espace client où il bénéficiera d’un ensemble de fonctionnalités (consultation compte, demande carte ou chéquier, virements ...).Il a également l’accès à un espace public qui regroupe un ensemble de services (trouver agence ou distributeur, convertisseur de devise, bourse..).
Client potentiel d'Attijari Bank
Toute personne utilisant l'application M-Banking d’Attijari Bank, qui n'est pas encore client, et qui pourra le devenir.
-Il a accès à un espace public de l’application où il pourra bénéficier d'un ensemble de fonctionnalités tel que la recherche d'une agence ou d'un DAB, le suivi des actualités de la banque et de la bourse...
Administrateur M-Banking d'Attijari Bank
Il s’agit de la personne qui possède toute les permissions sur lesystème.
Il est responsable de la gestion des abonnés M-Banking, la gestion des agences, des DAB, des régions et des demandes clients (demandes d’opposition ou d’obtention de carte ou de chéquier, demandes de virements…).
3. Les besoins fonctionnels
«Les besoins fonctionnels expriment une action que doit effectuer le système en réponse à
une demande (sorties qui sont produites pour un ensemble donné d’entrées)». [7]
Dans ce qui suit, nous décrivons les besoins fonctionnels de notre application appelés dans
Scrum «User stories»:
13
Tableau 1 : Description détaillée des acteurs
S’authentifier : Pour bénéficier des fonctionnalités offertes de l’application, le client
d'Attijari Bank doit s'authentifier en saisissant son code client et son mot de passe.
Accéder aux services public d’Attijari Bank : L’utilisateur M-Banking aura accès à
un espace public où un ensemble de fonctionnalités seront offertes tel que le suivi de
la bourse, des cours de devise, des actualités de la banque (Offre, Evénements,
Ouverture de nouvelles agences...), consultation des simulateurs et recherche des
agences et des DAB.
Accéder aux services clients d’Attijari Bank : C'est un espace dédié seulement aux
clients M-Banking qui leur permet d'effectuer des transactions bancaires tel que la
consultation de l'extrait bancaire, demande et/ou opposition sur un chéquier ou sur une
carte bancaire
Gérer le backoffice de l'application Mobile : L'administrateur de l'application doit
gérer la partie Backoffice. Il aura la possibilité de mettre à jour les données (ajouter une
nouvelle agence, supprimer une agence, actualiser les cours de devise ...), confirmer ou
décliner les demandes clients (demande d'obtention ou opposition sur carte, demande de
rendez-vous ...).
4. Les besoins non fonctionnels
«Il s’agit des besoins qui caractérisent le système. Ce sont des besoins en matière de
performance, de type de matériel ou le type de conception. Ces besoins peuvent concerner les
contraintes d’implémentation (langage de programmation, type SGBD.) ». [7]
Les besoins non fonctionnels de notre système, appelés dans Scrum «Technical Stories», se
décrivent comme suit :
Contraintes ergonomiques
o La navigation entre les interfaces de notre future application mobile doit être légère et
fluide.
o Les interfaces de notre future application web doivent être simples et homogènes.
o L’utilisateur M-Banking doit être guidé lors de la saisie de certaines informations, afin
de respecter les formats des champs de notre base de données.
14
Contraintes techniques
o Vu que notre application mobile manipule des données confidentielles, tous les accès
des clients doivent être protégés par un login, un mot de passe et un IMEI3 récupéré
lors de l’ajout d’un nouvel abonné. Ce code permet d’assurer la sécurité en donnant
accès aux abonnées de manipuler l’application uniquement par leurs propres
téléphones.
o Toutes les applications web au sein d'Attijari Bank nécessitent une authentification par
certificat qui sera établit en mettant en place le Framework Spring Security.Pour notre
cas, on a dû suivre le protocole interne et intégrer ce Framework d’authentification et
de contrôle d’accès.
o Les mots de passes des abonnés doivent êtres cryptés au niveau de la base de données
afin de garder sécurisé l’accès à l’application «Attijari Mobile Banking».
o Les requêtes doivent être optimisées afin d’assurer un temps de réponse minimal.
5. Backlog du produit
Le Backlog produit est utilisé pour planifier la release et aussi à chaque sprint, lors de la
réunion de planification du sprint pour décider du sous-ensemble qui sera réalisé. Ses
éléments sont classés par ordre de priorité ce qui permet de définir l’ordre de réalisation.
Pour chaque user story on identifie le rang, l’estimation, l'importance et la description.
Rang: Pour les user stories ayant la même priorité, un rang est assigné pour indiquer l'ordre
dans lequel l'équipe doit les implémenter.
Estimation: Sert à estimer l’effort nécessaire à une équipe pour implémenter une
fonctionnalité. Elle prend en compte l’effort pour le développement.
Importance :C'est un nombre qu'attribue le product owner à l'histoire : plus l'importance est
grande, plus l'histoire devra être traitée en priorité.
Priorité: Le product Owner classe les user story par ordre de priorité dans le Backlog produit
en travaillant avec le client pour savoir ce qui est important pour lui.
3International Mobile Equipment Identity, numéro qui permet d'identifier de manière unique chacun des terminaux de téléphonie mobile.
15
Description : Elle permet de décrire les user stories. Généralement, pour rendre ce nom
explicite, une bonne façon de procéder est d'utiliser le Template suivant : «En tant que X, je
veuxY,afinde...».
Le tableau 2 décrit le product backlog de notre apllication.
16
Id Nom Rang Estimation Priorité Description
1 S'authentifier 1 2 20 En tant que client d'Attijari Bank, je veux m'authentifier afin de bénéficier des fonctionnalités de l'application.
2 Modifier mot de passe 2 2 20 En tant que client d'Attijari Bank, je veux changer mon mot de passe afin de mieux maitriser mes paramètres de connexion.
3 Consulter la boite de réception. 3 2 20 En tant que client d'Attijari Bank, je veux consulter ma boite de réception afin de voir si mes demandes sont confirmées ou déclinées.
4 Demander une carte bancaire 4 3 20 En tant que client d'Attijari Bank, je veux demander une nouvelle carte afin de faciliter mes transactions quotidiennes.
17
6 Demander un chéquier 6 3 20 En tant que client d'Attijari Bank, je veux demander un nouveau chéquier afin de faciliter mes transactions quotidiennes.
7 Opposer un chéquier 7 3 20 En tant que client d'Attijari Bank, je veux opposer mon chéquier en cas de perte ou de vol afin de bloquer son utilisation.
8 Demander des virements simples intra-bancaires
8 7 20 En tant que client d'Attijari Bank, je veux transférer de l’argent entre mes comptes domiciliés au sein d’Attijari Bank..
9 Consulter l’extrait du compte 9 5 20 En tant que client d'Attijari Bank, je veux consulter mon extrait de compte afin de voir mes dix dernières transactions effectuées sur ce compte.
10 Suivre les actualités de la banque
10 2 20 En tant qu’utilisateur M-Banking, je veux suivre les actualités d’Attijari Bank afin d'être au courant de ses nouveautés.
11 Suivre les cours de devise 11 2 20 En tant qu’utilisateur M-Banking, je veux suivre les cours de devise afin d’être au courant des changements de devise.
12 Suivre le marché de la bourse 12 2 20 En tant qu’utilisateur M-Banking, je veux suivre le marché de la bourse afin d'être au courant des changements.
13 Prendre un rendez-vous 13 2 20 En tant qu’utilisateur M-Banking je veux prendre un rendez-vous afin de planifier une rencontre avec le chargé clientèle de mon agence
14 Envoyer un message 14 2 20 En tant qu’utilisateur M-Banking je veux envoyer un message la banque afin de communiquer mes réclamations et mes suggestions.
15 Appeler la banque 15 1 20 En tant qu’utilisateur M-Banking je veux appeler la banque afin d’entrer en contact immédiat avec le centre de relation client.
16 Consulter le système de géo localisation des agences
16 9 20 En tant qu’utilisateur M-Banking, je veux consulter le système de géo localisation afin de visualiser sur la carte les agences d’Attijari Bank sur le territoire tunisien.
17 Consulter le système de géo localisation des D AB
17 9 20 En tant qu’utilisateur M-Banking, je veux consulter le système de géo localisation afin de visualiser sur la carteles DAB d’Attijari Bank sur le territoire tunisien.
18 Consulter la liste des points de contacts des agences
18 3 20 En tant qu’utilisateur M-Banking, je veux consulter la liste des DAB afin d'avoir une idée sur leurs adresses.
19 Consulter la liste des points de contacts des DAB
19 3 20 En tant qu’utilisateur M-Banking, je veux consulter la liste des agences ou des DAB afin d'avoir une idée sur leurs adresses.
18
6. Planification des Releases
La réunion de planification des sprints est une étape importante dans SCRUM. Le planning de
travail et l'identification du Backlog des sprints sont les buts de cette réunion. Durant ce meeting,
la durée de chaque sprint est décidée selon la complexité du contexte et la taille de l'équipe.
La planification de Sprint répond aux questions suivantes :
Qu’est-ce qui peut être terminé au cours de ce Sprint ?
Comment sera effectué le travail choisi ?
Et donc, une succession de Releases est le produit de cette réunion pour organiser le travail de
l'équipe. Un Release est une série de Sprints qui se termine quand les incréments successifs
constituent un produit présentant suffisamment de valeurs à ses utilisateurs. Dans notre cas, nous
avons décidé de découper notre projet en deux Releases.
La figure 4 schématise le découpage en Releases.
19
Figure 4 : Schéma de Releases
7. Identification de l’équipe Scrum
Dans le tableau 3, nous définissons, tout d’abord, notre équipe de travail ainsi que le rôle de
chaque équipier selon les rôles définis par Scrum
Rôles Scrum Personnes Affectées
Product Owner M. Mohamed Hedi AMLOUK
Scrum Master M. Hosni KRICHA, Mme. Nadia YACOUBI
Team TAHARI Cyrine, TORKHANI Yasmine
8. Diagramme de cas d’utilisation initial
Maintenant, nous allons présenter les différents besoins fonctionnels de notre application
exprimés précédemment d'une manière informelle en utilisant le digramme de cas d'utilisation
d'UML.
Android connait la plus forte croissance sur le marché des OS mobiles avec son propre marché
d’applications nommé Google Play. Une étude faite en 2014 par ABI Researchpour évaluer la
vente mondiale de Smartphones par système d'exploitation mobile, montre une grande dominance
du système d'exploitation Android.
La figure 6 illustre l’étude montrant la dominance du système d’exploitation d’Android sur le
marché.
20
Tableau 2: Identification de l’équipe Scrum
9.2 Architecture de l’application Front Office
Nous décrivons dans cette partie le fonctionnement de notre application mobile «Attijari Mobile
Banking». Elle est connectée à un serveur de bases de données distant, via Internet, afin de
récupérer les données en utilisant des requêtes SQL, ce qui nécessite alors l’intégration d’un
serveur web entre l’application client et le serveur de bases de données. D’où l’architecture de
notre application mobile est une architecture 3-tiers partagée entre:
Le client Android :Il s’agit du demandeur de ressources et consommateurs des web services.
Le serveur Web : Il permet de gérer la communication entre le client Android et le serveur de
base de données.
Le serveur de base de données : Il permet de fournir les données au serveur web.
Afin de gérer la base de données, nous avons écrit et exécuter des scripts PHP(en utilisant le
protocole HTTP du système Android) et nous avons codé les données dans le format JSON.
La figure 7 schématise l’architecture générale de note application mobile.
21
Figure 6 : Etude Comparative des systèmes d’exploitation mobile sur le marché [3]
9.3 Framework et développement de l’application Back OfficeTout système d'information nécessite la réalisation de trois groupes de fonctions: le stockage des
données, la logique applicative et la présentation. Ces trois parties sont indépendantes les unes
des autres. D'où notre choix de l'architecture 3 tiers pour l'application Web (Figure 8).
L’architecture 3-tiers, est une architecture partagé entre :
Les pc clients (ou administrateurs)
Le serveur Web et le serveur d’application.
Le serveur de base de données.
En effet, cette architecture est un modèle logique d’architecture applicative qui vise à séparer,
très nettement trois couches logicielles au sein d’une même application ou système, à modéliser
et à présenter cette application comme un empilement de trois couches, étages, ou niveaux qui
sont les suivantes :
Couche Présentation (premier niveau)
Elle correspond à la partie de l’application visible et interactive avec les utilisateurs. On parle
d’interface homme machine. La couche présentation relaie les requêtes de l’utilisateur à
destination de la couche métier, et lui présente en retour les informations renvoyées par les
traitements de cette couche. Il s’agit donc d’un assemblage de services métiers et applicatifs
offerts par la couche inférieure.
Couche Métier / Business (second niveau)
Elle correspond à la partie fonctionnelle de l’application, celle qui implémente la «logique», et
qui décrit les opérations que l’application opère sur les données en fonction des requêtes des
utilisateurs effectuées au travers de la couche présentation.
Couche Accès aux données (troisième niveau)
C'est la partie qui gère l’accès aux données du système. Ces données peuvent être propres au
système, ou gérées par un autre système.
La figure 8 schématise l’architecture générale de note application web.
22
Figure 7:Architecture générale de l’application mobile [4]
Parlons maintenant de la mise en place de la plate-forme J2EE : Cette opération se constitue de
deux étapes fondamentales : la mise en place des couches et celle du serveur web.
Mise en place des couches
Nous avons choisi de coder l’application en se basant sur les couches Hibernate, Spring et Spring
Security afin de faciliter l’effort de l’implémentation et de favoriser l’aspect sécurité ainsi que la
bibliothèque de composants PrimeFaces pour JSF2pour les interfaces.
o La couche Spring
Spring est un Framework libre pour construire et définir l’infrastructure d’une application
java2, dont il facilite le développement et les tests.
«SPRING est effectivement un conteneur dit «léger» .Il prend donc en charge la création
d'objets et la mise en relation d'objets par l'intermédiaire d'un fichier de configuration qui
décrit les objets à fabriquer et les relations de dépendances entre ces objets.» [6]
Pour l'authentification on a du intégrer le Framework Spring Security.En effet C’est est un
sous-projet de Spring, il a été lancé en 2003 sous le nom d’Acegi Secuirty. En 2007 il sera
renommé Spring Security. C’est l’un des projets les plus avancés de Spring.
«Spring Security est un cadre qui se concentre sur la fourniture de l'authentification et
l’autorisation aux applications Java. Comme tous les projets de Spring , la puissance réelle de
Spring Security se trouve dans la façon dont facilement il peut être étendu pour répondre aux
besoins personnalisés».[7]
o La couche Hibernate
C’est une couche qui sert à la persistance des objets dans les bases de données relationnelles.
Elle présente un avantage remarquable contre l’accès classique aux données manifestés par
les JDBCs «Java Data Base Connectivity», vue la rapidité de traitement via des appels à des
méthodes objet de haut niveau.
23
Figure 8: Architecture générale d'application web [5]
o La couche Prime faces
Le développement d’interface web avec JSF était limité à cause de peu de composants
graphiques disponibles.A cause de ce manque de composants, de nombreux lancés afin de
créer des bibliothèques de composants JSF plus ou moins spécifiques.
D’où l’apparition de Prime Faces qui est maintenue par «Prime Teknoloji», une entreprise de
logiciels Turque de développement spécialisée dans Agile et Java EE conseil.
«Prime Faces est une bibliothèque open source de composants JSF.Il est basé, côté serveur,
sur l’API standard de JSF 2.Coté client, les scripts de Prime Faces sont basés sur la librairie
la plus populaire de JavaScript jQuery.Prime Faces vise à garder le traitement propre, rapide
et léger».[8]
Mise en place du serveur Web
o Apache Tomcat 7.0.59
«Apache Tomcat est un serveur d’application Java permettant d’exécuter des servlets et des
pages serveurs Java(JSP). Il peut être utilisé ou couplé avec un serveur Web, et porté sur
n’importe quel système sur lequel une machine virtuelle Java est installée».[9] Il est
paramétrable par des fichiers XML et de propriétés, et inclut des outils pour la configuration
et la gestion. Il comporte également un serveur HTTP.
10. Environnement technique du travail
Le tableau 4 détaille la configuration matérielle des machines de développement et de
déploiement utilisées ainsi que les différents logiciels qui y sont installés :
Machines Machine1 Machine2
Propriétaire TORKHANI Yasmine TAHARI Cyrine
Processeur Intel Core i5 Intel Core i5
RAM 8GB 8GB
Système d’exploitation Windows 8.1 Entreprise (x64) Windows 8.1 Entreprise (x64)
Logiciels installés EclipseMyEclipse for SpringRational Rose
EclipseMyEclipse for SpringRational Rose
24
Tableau 3: Description des machines de développement
WampServerApach Tomcat Serverplsqldevloper 7.0.3Oracle 10gScreenPresso
WampServerApach Tomcat Serverplsqldevloper 7.0.3Oracle 10gScreenPresso
10.1 Outil de conception Rational Rose
Rational Rose est un logiciel édité par l'entreprise Rational Machines pour créer et éditer les
différents diagrammes du modèle UML (Unified Modeling Language) d'un logiciel. [10]
10.2 Outils de développementDans cette partie nous allons décrire les outils de développement utilisé pour réaliser ce projet.
Environnement de développement : Eclipse Luna 4.4 (La nouvelle version de l'IDE)
Eclipse est un environnement de développement open source, décliné et organisé en un ensemble
de sous-projets de développements logiciels, de la Fondation Eclipse visant à développer un
environnement de production de logiciels libre qui soit extensible et universel en s’appuyant
principalement sur le langage Java.[11]
Environnement de développement : MyEclipse for Spring 9.0
MyEclipse est un environnement de développement intégré basé sur le très connu Eclipse. Son
intérêt se situe dans la facilitation de la mise en place de différents Framework, tels que Hibernate
ou Spring. [12]
L'ensemble des bibliothèques logicielles : Java Développent Kit (JDK7 64bits)
Le JDK désigne un ensemble de bibliothèques logicielles de base du langage de programma-
tion Java, ainsi que les outils avec lesquels le code Java peut être compilé, transformé en byte
code destiné à la JVM (Java Virtual Machine).[13]
Android Software Development Kit (SDK)
Le SDK est' un ensemble d'outils que met à disposition Google afin de vous permettre de
développer des applications pour Android. [14] Il est disponible pour Windows, MacOs X et
linux et inclut des outils ainsi qu'un émulateur Android pour exécuter des applications.
AndroidDevelopment Tools (ADT)
25
Eclipse a été conçu de manière à pouvoir recevoir des plugins. Le plugin pour les
développements d'applications Android s'appelle ADT Outils de développement Android) et il
peut être téléchargé directement depuis Eclipse. [14]
Android Virtual Device (AVD)
L'Android Virtual Device est un émulateur de terminal sous Android, c'est-à-dire que c'est un
logiciel qui se fait passer pour un appareil sous Android à votre ordinateur. [14]
SGBDR Oracle 10g express
Oracle Database est un système de gestion de base de donnéesrelationnel (SGBDR) fourni
par Oracle Corporation. [15]
WampServer 32 bits
WampServer est une plate-forme de développement Web sous Windows pour des applications
Web dynamiques à l’aide du serveur Apache2, du langage de scripts PHP et d’une base de
données MySQL. Il possède également PHPMyAdmin pour gérer plus facilement vos bases de
données.[16]
10.3 Langages de programmation
Java
Java est un langage de programmation orienté objet, développé par Sun Microsystems permettant
de créer des logiciels compatibles avec des nombreux systèmes d’exploitation et donne aussi la
possibilité de développer des programmes pour téléphones portables. [17]
PHP
PHP (Hypertext Preprocessor) est un langage de programmation informatique essentiellement
utilisé pour produire des pages web dynamiques via un serveur HTTP. [18]
REST
REST (Representational State Transfer) est un style d'architecture réseau pour Web Services qui
met l'accent sur la définition de ressources identifiées par des URI, et utilise les messages du
protocole HTTP pour définir la sémantique de la communication client/serveur: [19]
GET pour le rapatriement d'une ressource,
POST pour une création
REST n'est pas vraiment un standard. Il n'existe donc pas de spécifications de REST. Il faut
26
comprendre le style REST et ensuite concevoir des applications ou des services Web selon ce
style.
Bien que REST ne soit pas un standard, il utilise des standards. En particulier :
URI comme syntaxe universelle pour adresser les ressources
HTTP un protocole sans état (stateless) avec un nombre très limité d'opérations,
Des liens hypermedia dans des documents (X)HTML et XML pour représenter à la fois le
contenu des informations et la transition entre états de l'application,
Les types MIME comme text/xml, text/html, image/jpeg, application/pdf, video/mpeg
pour la représentation des ressources. [20]
JSON
JSON (JavaScript Object Notation) un format d'encodage de données structurées en JavaScript
qui date de 2002. Il permet de représenter de l’information structurée. Il n'est pas rare d'associer
le couple REST/JSON pour des raisons de simplicité. Son avantage est de fournir un support pour
une écriture simple et légère au format texte, relativement compréhensible par les développeurs
JavaScript, mais aussi - et surtout - d'être nativement interprété.
10.4 Langage de modélisation :UML (en anglais Unified Modeling Language ou « langage de modélisation unifié ») est un
langage de modélisation graphique à base de représentations graphiques. Il est apparu dans le
monde du génie logiciel, dans le cadre de la «conception orientée objet». Couramment utilisé
dans les projets logiciels, il peut être appliqué à toutes sortes de systèmes ne se limitant pas au
domaine informatique. [21]
11. Conclusion
Au long de ce chapitre, nous avons présenté le Sprint 0 qui, est en fait une phase de préparation
pendant laquelle on a construit notre backlog du produit en se basant sur les besoins fonctionnels
et non fonctionnels. En plus, nous avons découpé notre projet en des releases qui formeront les
chapitres suivants. Et finalement, nous avons défini les technologies et les environnements de
développement ainsi que l’architecture globale de l’application.
27
Chapitre 3Développement de l'application
Front Office
1. Introduction
Notre premier release sera composé de trois sprints. Tout au long de ce chapitre, nous allons
traiter les histoires utilisateurs de nos sprints pour produire un ensemble d'incréments
potentiellement livrable. Avant de se lancer dans le premier sprint, l'équipe doit définir le but de
ce dernier qui doit être défini en terme métier et non pas terme technique pour qu'il soit
compréhensible par les membres en dehors de l’équipe. Il s’agit de répondre à une question
fondamentale «Pourquoi faisons-nous ce sprint?».
2. Sprint 1 : Authentification
Au début de chaque sprint, on définit un objectif et on lui associe une liste de fonctionnalités qui
constitueront le backlog de sprint. Au cours d'un sprint, l'objectif et la composition de l'équipe ne
peuvent être modifiés.
Ci-dessous la définition de l'objectif et des développeurs de ce sprint.
Objectif : Les clients de l'application «Attijari Mobile Banking» sont capables de s’authentifier avec succès avec la possibilité de changer le mot de passe en cas de besoin.
Développeurs : Team.
2.1 Sprint planning ou planification du sprint
Une fois nous avons défini le but de notre sprint, il est temps de décider quelles histoires de notre
backlog du produit inclure dans le backlog du sprint.
Le tableau 5 résume donc le backlog du premier sprint.
28
Id Nom Description Priorité
1 S’authentifier En tant que client d'Attijari Bank je veux m'authentifier afin de bénéficier des fonctionnalités de l'application.
20
2 Modifier mot de passe En tant que client d'Attijari Bank je veux changer mon mot de passe afin de mieux personnaliser mes paramètres de connexion.
20
Passons maintenant au vif de notre sujet : les activités et le cycle de développement. Dans un
sprint nous pouvons dégager trois étapes principales qui sont la spécification fonctionnelle, la
conception, et le test. Tout au long de ce sprint, nous respectons ces activités pour construire le
plan de notre travail.
2.2 Spécification fonctionnelle
Dans cette partie, nous procéderons par un diagramme de cas d'utilisation du sprint puis une
description textuelle de ses histoires utilisateurs.
2.2.1 Diagramme de Cas d'utilisation
Il s'agit de la première étape du sprint 1. Afin d'accéder aux différentes fonctionnalités offertes
par l'application Mobile Banking d'Attijari Bank, le client doit s'authentifier en saisissant un code
client et un mot de passe généré par la banque lors de son inscription dans le pack Mobile
Banking d’Attijari Bank. Il a également la possibilité de modifier son mot de passe afin de
personnaliser ses paramètres d'authentification.
La figure 9 illustre le diagramme de cas d'utilisation global du premier Sprint.
29
Tableau 4: Sprint 1 Backlog
2.2.2 Description textuelle
Le tableau 6 décrit textuellement le même cas d'utilisation
Cas d’utilisation S’authentifier
Acteur Client d’Attijari Bank
Pré condition : L’utilisateur M-Banking télécharge l’application sur son terminal mobile.
Post condition : L’utilisateur M-Banking est identifié comme étant un client d’Attijari Bank.
Description du scénario principal : -Le client remplit les champs d’authentification et clique sur le bouton «Connexion».
-Le système vérifie les informations saisies par le client et affiche l’interface suivante.
Exception : Si un des champs est invalide, le système affiche un message d’erreur.
Point d'extension:
Modifier mot de passe
-Le client clique sur «Changer mot de passe».
-Le système affiche l’interface appropriée.
- Le client saisit les champs nécessaires et clique sur «Enregistrer».
-Le système vérifie les informations saisies par le client et enregistre les modifications.
30
Figure 9: Diagramme de cas d’utilisation global Sprint 1
Tableau 5: Description textuelle de cas d’utilisation «S’authentifier»
2.3 Conception
La conception est la deuxième étape dans un sprint. Elle se traduit par un diagramme de classes et
un diagramme de séquences.
Le diagramme de classes permet de représenter une vue statique du système
d’information.[23] Il identifie la structure des classes du système, y compris les propriétés
et les méthodes de chaque classe, et les diverses relations qui peuvent exister entre les
classes y sont également représentées.
Le diagramme de séquences permet de représenter une vue dynamique du système
d’information.[23] Il permet de décrire les scénarios de chaque cas d'utilisation en mettant
l'accent sur la chronologie des opérations en interaction avec les objets.
Pour les cas d’utilisation «S’authentifier» et «Modifier mot de passe», nous allons présenter
ces deux diagrammes.
Cas d’utilisation «S’authentifier»
o Diagramme de classes
Le diagramme de classes du cas d’utilisation «S’authentifier» se traduit par les différentes classes
participantes à la réalisation de ce dernier.
La figure 10 illustre le diagramme de classes du cas d'utilisation «S'authentifier».
31
Figure 10 : Diagramme de classes du cas d’utilisation «S’authentifier»
o Diagramme de séquences
A travers ce diagramme, nous décrivons le scénario du même cas d’utilisation. Dans un premier
lieu, l’utilisateur M-Banking remplit le formulaire d’authentification et clique sur le bouton
«Connexion». Ensuite le système vérifie s’il s’agit bien d’un abonné ou non à travers le web
service «Login».
La figure 11 illustre le diagramme de séquences du cas d’utilisation «S'authentifier».
32
Figure 11: Diagramme de séquences du cas d’utilisation «S'authentifier»
Cas d’utilisation «Modifier Mot de passe»
o Diagramme de classes
Le diagramme de classes du cas d’utilisation «Modifier mot de passe» se traduit par les
différentes classes participantes à la réalisation de ce dernier.
La figure 12 illustre le diagramme de classes du cas d’utilisation «Modifier mot de passe».
33
Figure 12 Diagramme de classes du cas d’utilisation «Modifier mot de passe».
o Diagramme de séquences
A travers ce diagramme, nous allons décrire le scénario du cas d’utilisation «Modifier mot de
passe». Dans un premier lieu, le client d’Attijari Bank remplit le formulaire de modification du
mot de passe.Ensuite le système vérifie la saisie et enregistre le nouveau mot de passe à travers le
web service «Update MDP».
La figure 13 illustre le diagramme de séquences du cas d’utilisation «Modifier mot de passe».
34
Figure 13 Diagramme de séquences du cas d’utilisation «Modifier mot de passe».
2.4 Test
L'approche Agile met le test au cœur des projets. Pour Scrum et les méthodes agiles en général, le
test ne se fait pas après la fin de développement. Au contraire, le test est une phase intégrée dès le
début du premier sprint jusqu'à la livraison du produit final.
Pour notre application mobile, les tests ont été effectués sur un smartphone Android (Version
4.2.2) via un câble USB et sur des clients réels de la banque. Donc, pour des raisons de
confidentialité on a du flouter les informations personnelles des clients.
Nous illustrons à ce niveau les captures d’écran réalisés au niveau de ce sprint. Commençons par
l’interface principale au niveau de laquelle l’utilisateur M-Banking choisit l’espace auquel il veut
35
accéder. Dans le cas d’un abonné, il va choisir d’accéder à l’espace client afin de bénéficier des
services bancaires privés tel que la modification de mot de passe. Il doit donc s’authentifier en
saisissant son code client et son mot de passe.
La figure 14 illustre la première interface de l’application mobile.
La figure 15 illustre l’interface d’authentification.
La figure 16 illustre l’interface de modification du mot de passe
Figure 14 : Interface principale de l’application mobile
Figure 15: Interface d’authentification.
Figure 16: Interface de modification du mot de passe
. Sprint 2: Accès aux services clientsAu début de chaque sprint, on définit un objectif et on lui associe une liste de fonctionnalités qui
constitueront le backlog de sprint. Au cours d'un sprint, l'objectif et la composition de l'équipe ne
peuvent être modifiés.
Ci-dessous la définition de l'objectif et des développeurs de ce sprint.
Objectif : Les clients de l'application «Attijari Mobile Banking» sont capables d’effectuer des demandes d'obtention et d’opposition sur carte et/ou chéquier et des demandes de virement. Ils sont aussi capables de consulter leur extrait de compte ainsi que leur boite de réception afin de voir si la banque a répondu à leurs demandes.
36
Développeurs : Team.
2.5 Sprint planning ou planification du sprint
Une fois nous avons défini le but de notre sprint, il est temps de décider quelles histoires de notre
backlog du produit inclure dans le backlog du sprint.
Le tableau 7 résume donc le backlog du deuxième sprint.
Tableau 6 :Sprint2 backlog
Id Nom Priorité Description
1 S'authentifier 20 En tant que client d'Attijari Bank, je veux m'authentifier afin de bénéficier des fonctionnalités de l'application.
2 Modifier mot de passe 20 En tant que client d'Attijari Bank, je veux changer mon mot de passe afin de mieux maitriser mes paramètres de connexion.
3 Consulter la boite de réception.
20 En tant que client d'Attijari Bank, je veux consulter ma boite de réception afin de voir si mes demandes sont confirmées ou déclinées
.
4 Demander une carte bancaire
20 En tant que client d'Attijari Bank, je veux demander une nouvelle carte afin de faciliter mes transactions quotidiennes.
5 Opposer une carte bancaire 20 En tant que client d'Attijari Bank, je veux opposer ma carte bancaire en cas de perte ou de vol afin de
bloquer son utilisation.
6 Demander un chéquier 20 En tant que client d'Attijari Bank, je veux opposer mon chéquier en cas de perte ou de vol afin de bloquer son utilisation.
7 Opposer un chéquier 20 En tant que client d'Attijari Bank, je veux demander un nouveau chéquier afin de
37
faciliter mes transactions quotidiennes.
8 Demander des virements simples intra-bancaires
20 En tant que client d'Attijari Bank, je veux opposer mon chéquier en cas de perte ou de vol afin de bloquer son utilisation.
9 Consulter l’extrait du compte
20 En tant que client d'Attijari Bank, je veux demander des virements afin de manipuler le transfert d’argent entre mes comptes.
10 Consulter la boite de réception
20 En tant que client d'Attijari Bank, je veux consulter mon extrait de compte afin de voir mes dix dernières transactions effectuées sur ce compte.
Passons maintenant au vif de notre sujet : les activités et le cycle de développement. Dans un
sprint nous pouvons dégager trois étapes principales qui sont la spécification fonctionnelle, la
conception, et le test. Tout au long de ce sprint, nous respectons ces activités pour construire le
plan de notre travail.
2.6 Spécification fonctionnelle
Dans cette partie, nous procéderons par un diagramme de cas d'utilisation du Sprint puis une
description textuelle de ses histoires utilisateurs.
2.6.1 Diagramme de Cas d'utilisation
Il s'agit de la première étape de ce sprint. Après authentification, le client d'Attijari Bank se
trouve capable de bénéficier des différents services bancaires offerts par Attijari Bank.
La figure 17 illustre le diagramme de cas d’utilisation global du deuxième Sprint.
38
Figure 17: Diagramme de cas d’utilisation global Sprint 2
2.6.2 Description textuelle
Ci-dessous la description textuelle des différents cas d'utilisation généralisés du cas
d’utilisation«Accéder aux services clients d'Attijari Bank».
Le tableau 8 décrit textuellement le cas d'utilisation «Consulter l’extrait du compte»
Tableau 7 : Description textuelle du cas d’utilisation «Consulter l’extrait du compte»
Cas d’utilisation : Consulter l’extrait du compte
Acteur : Client d'Attijari Bank
Pré condition : L’utilisateur M-Banking est identifié comme étant un client d’Attijari Bank.
Post condition : Le client consulte son extrait du compte avec succès.
Description du scénario principal :
-A travers un sliding menu, le client choisit «Extrait Bancaire».-Le système affiche la liste des comptes du client.-Le client choisit un des comptes.-Le système affiche l’interface des mouvements du compte approprié.
39
Point d'extension:
Effectuer des virements simples intra-bancaires
-A travers un sliding menu, le client choisit «Virements».-Le système affiche l’interface appropriée.-Le client remplit les champs nécessaires et clique sur le bouton «Valider».-Le système vérifie les informations saisies par le client et affiche un message de succès.
A titre d'exemple, nous détaillons le cas d'utilisation «Demander une carte bancaire». Le
scénario pour la demande et l'opposition sur un chéquier et demande virement est identique à
celui de la demande et l'opposition sur une carte.
Tableau 8: Description textuelle du cas d’utilisation «Demander une carte bancaire»
Cas d’utilisation : Demander une carte bancaire
Acteur : Client d'Attijari BankPré condition : L’utilisateur M-Banking est identifié comme étant un client
d’Attijari Bank.Post condition : La demande de la carte bancaire est enregistrée.
Exception : Si un des champs est vide, le système affiche un message d’erreur.
Description du scénario principal :
-A travers un sliding menu, le client choisit «Demande carte».-Le système affiche l'interface appropriée.-Le client remplit les champs nécessaires et clique sur le bouton «Valider».-Le système vérifie les informations saisies par le client, enregistre la demande et affiche un message de succès.
Point d'extension
Opposer une carte bancaire
-A travers un sliding menu, le client choisit «Opposition sur Carte».-Le système affiche l’interface appropriée.-Le client saisit les champs nécessaires et clique sur «Valider».-Le système vérifie les informations saisies par le client, enregistre la demande et affiche un message de succès.
Le tableau 10 décrit textuellement le cas d'utilisation«Consulter la boite de réception»
40
Tableau 9: Description textuelle du cas d’utilisation «Consulter la boite réception»
Cas d’utilisation : Consulter la boite de réception
Acteur : Client d'Attijari Bank
Pré condition : L’utilisateur M-Banking est identifié comme étant un client d’Attijari Bank.
Post condition : Le client d'Attijari Bank consulte sa boite de réception avec succès.
Description du scénario principal :
-A travers un sliding menu, le client choisit «Boite de réception».-Le système affiche l’interface appropriée. -Le client consulte sa boite de réception.
2.7 Conception
La conception est la deuxième étape dans un sprint. Elle se traduit par un diagramme de classes et
un diagramme de séquences.
Le diagramme de classes permet de représenter une vue statique du système
d’information. [23] Il identifie la structure des classes du système, y compris les
propriétés et les méthodes de chaque classes, et les diverses relations qui peuvent exister
entre les classes y sont également représentées.
Le diagramme de séquence permet de représenter une vue dynamique du système
d’information. [23] Il permet de décrire les scénarios de chaque cas d'utilisation en
mettant l'accent sur la chronologie des opérations en interaction avec les objets.
Pour les cas d’utilisation de ce Sprint, nous allons présenter ces deux diagrammes.
Cas d’utilisation «Consulter l’extrait du compte»
o Diagramme de classes
Le diagramme de classes du cas d’utilisation «Consulter l’extrait de compte» se traduit par les
différentes classes participantes à la réalisation de ce dernier.
La figure 18 illustrant le diagramme de classes du cas d’utilisation «Consulter l’extrait de
compte».
41
Figure 18: Diagramme de classes du cas d’utilisation «Consulter l’extrait de compte»
o Diagramme de séquences
A travers ce diagramme, nous allons décrire le scénario du cas d’utilisation «Consulter l’extrait
du compte». Si le client d’Attijari Bank choisit de faire une consultation de l’extrait bancaire, il
doit choisir au début le compte auquel il veut faire cette consultation. Pour cela, deux web
services sont nécessaires : «GetInfosCompte» pour les consultations des comptes que possédé le
client, et «GetMouvement» pour la consultation des mouvements du compte.
La figure 19 illustre le diagramme de séquences du cas d’utilisation «Consulter l’extrait du
compte».
42
Figure 19: Diagramme de séquences du cas d’utilisation «Consulter l’extrait du compte»
Cas d’utilisation «Demander une carte bancaire»
o Diagramme de classes
Le diagramme de classes du cas d’utilisation «Demander une carte bancaire» se traduit par les
différentes classes participantes à la réalisation de ce dernier.
La figure 20 illustre le diagramme de classe du cas d'utilisation «Demander une carte bancaire»
43
Figure 20: Diagramme de classe du cas d'utilisation «Demander une carte bancaire»
o Diagramme de séquences
A travers ce diagramme, nous allons décrire le scénario du cas d’utilisation «Demander une carte
bancaire». Dans un premier lieu, le client d’Attijari Bank remplit le formulaire. Ensuite le
système vérifie la saisie et enregistre la demande à travers le web service «DemandeCarte».
La figure 21 illustre le diagramme de séquences du cas d’utilisation «Demander une carte
bancaire»
44
Figure 21: Diagramme de séquences du cas d’utilisation «Demander une carte bancaire»
«Opposer une carte bancaire»
o Diagramme de classes
Le diagramme de classes du cas d’utilisation «Opposer une carte bancaire» se traduit par les
différentes classes participantes à la réalisation de ce dernier.
La figure 22 illustre le diagramme de classes du cas d'utilisation «Opposer une carte bancaire».
45
Figure 22: Diagramme de classes du cas d'utilisation «Opposer une carte bancaire»
o Diagramme de séquences
A travers ce diagramme, nous allons décrire le scénario du cas d’utilisation «Opposer une carte bancaire». Dans un premier lieu, le client d’Attijari Bank consulte la liste des différentes cartes qu’il possède. Ensuite, il choisit celle qu’il veut opposer, consulte les détails de la carte concernée, puis enregistre la demande d’opposition sur carte.
La figure 23 illustre le diagramme de séquences du cas d’utilisation «Opposer une carte
bancaire ».
46
Figure 23: Diagramme de séquences du cas d’utilisation «Opposer une carte bancaire»
«Consulter la boite de réception»
o Diagramme de classes
Le diagramme de classes du cas d’utilisation «Consulter la boite de réception» se traduit par les
différentes classes participantes à la réalisation de ce dernier.
La figure 24 illustre le diagramme de classes du cas d'utilisation «Consulter la boite de
réception».
47
Figure 24: Diagramme de classes du cas d'utilisation «Consulter la boite de réception»
o Diagramme de séquences
A travers ce diagramme, nous allons décrire le scénario du cas d’utilisation «Consulter la boite de
réception». Le client d’Attijari Bank consulte sa boite de réception afin de suivre l’avancement de
ses demandes (si elles sont en cours, acceptées ou déclinées).
48
La figure 25 illustre le diagramme de séquences du casd’utilisation «Consulter la boite de
réception».
Figure 25: Diagramme de séquences du cas d’utilisation «Consulter la boite de réception»
2.8 Test
L'approche Agile met le test au cœur des projets. Pour Scrum et les méthodes agiles en général, le
test ne se fait pas après la fin de développement. Au contraire, le test est une phase intégrée dès
le début du premier sprint jusqu'à la livraison du produit final.
49
Nous illustrons à ce niveau les captures d’écran réalisés au niveau de ce sprint. Après avoir
s’authentifier, le client d’Attijari Bank se trouve capable de bénéficier des différents services
bancaires offerts par Attijari Bank.
La figure 26 illustre l’interface du menu principal (qui inclut uniquement les services dédiés aux
clients).
L’interface de consultation de l’extrait bancaire se divise en deux:
-La figure 27 illustre l’interfacede consultation des comptes ainsi que le solde de chaque compte.
-La figure 28 illustre l’interface des mouvements du compte approprié.
Figure 26 : Interface du menu principal
Figure 27 : Interface de consultation des comptes
bancaires
Figure 28 : Interface de consultation de l’extrait bancaire
La figure 29 illustre l’interface de demande carte.
50
Figure 29 Interface de demande d’une carte
3. Sprint 3: Accès aux services publics
Au début de chaque sprint, on définit un objectif et on lui associe une liste de fonctionnalités qui
constitueront le backlog de sprint. Au cours d'un sprint, l'objectif et la composition de l'équipe ne
peuvent être modifiés.
Ci-dessous la définition de l'objectif et des développeurs de ce sprint.
Objectif : Les utilisateurs M-Banking de l'application «Attijari Mobile Banking» sont
capables d’accéder un espace public où ils bénéficieront d’un ensemble de fonctionnalités
(consulter le système de géo localisation, consulter les cours de devise…).
Développeurs : Team.
51
3.1 Sprint planning ou planification du sprint
Une fois nous avons défini le but de notre sprint, il est temps de décider quelles histoires de notre
backlog du produit inclure dans le backlog du sprint.
Le tableau 11 résume donc le backlog du troisième sprint
Tableau 10 : Sprint3 backlog
Id Nom Priorité Description
1 Suivre les actualités de la banque
20 En tant qu’utilisateur M-Banking, je veux suivre les actualités d’Attijari Bank afin d'être au courant de ses nouveautés.
2 Suivre les cours de devise 20 En tant qu’utilisateur M-Banking, je veux suivre les cours de devise afin d’être au courant des changements de devise.
3 Suivre le marché de la bourse
20 En tant qu’utilisateur M-Banking, je veux suivre le marché de la bourse afin d'être au courant des changements.
4 Prendre un rendez-vous 20 En tant qu’utilisateur M-Banking je veux prendre un rendez-vous afin de planifier une rencontre avec le chargé clientèle de mon agence.
5 Envoyer un message 20 En tant qu’utilisateur M-Banking je veux envoyer un message la banque afin de communiquer mes réclamations et mes suggestions.
6 Appeler la banque 20 En tant qu’utilisateur M-Banking je veux appeler la banque afin d’entrer en contact immédiat avec le centre de relation client.
7 Consulter le système de géo localisation des agences
20 En tant qu’utilisateur M-Banking, je veux consulter le système de géo localisation afin de visualiser sur la carte les agences d’Attijari Bank sur le territoire tunisien.
52
8 Consulter le système de géo localisation des D AB
20 En tant qu’utilisateur M-Banking, je veux consulter le système de géo localisation afin de visualiser sur la carteles DAB d’Attijari Bank sur le territoire tunisien.
9 Consulter la liste des points de contacts des agences
20 En tant qu’utilisateur M-Banking, je veux consulter la liste des DAB afin d'avoir une idée sur leurs adresses.
10 Consulter la liste des points de contacts des DAB
20 En tant qu’utilisateur M-Banking, je veux consulter la liste des agences ou des DAB afin d'avoir une idée sur leurs adresses.
Passons maintenant au vif de notre sujet : les activités et le cycle de développement. Dans un
sprint nous pouvons dégager trois étapes principales qui sont la spécification fonctionnelle, la
conception, et le test. Tout au long de ce sprint, nous respectons ces activités pour construire le
plan de notre travail.
3.2 Spécification fonctionnelle
Dans cette partie, nous procéderons par un diagramme de cas d'utilisation du sprint puis une
description textuelle de ses histoires utilisateurs.
3.2.1 Diagramme de Cas d'utilisation
Il s'agit de la première étape de ce sprint. N’importe quelle personne possédant un terminal
mobile Android peut manipuler l’application pour différentes raisons. Ces utilisateurs, qui sont
considérés comme des clients potentiels de la banque, ont accès à un espace public dans lequel ils
peuvent bénéficier des différents services.
La figure 30 illustre le diagramme de cas d’utilisation global du Sprint 3.
53
Figure 30: Diagramme de cas d’utilisation global Sprint3
3.2.2 Description textuelle
Ci-dessous la description textuelle des différents cas d'utilisation généralisés de «Accéder aux
services publics d'Attijari Bank».
Le tableau 12 décrit textuellement le cas d'utilisation «Accéder aux services public d'Attijari Bank»
Tableau 11 : Description du cas d’utilisation «Accéder aux services public d’Attijari Bank»
Cas d’utilisation : Accéder aux services public d'Attijari Bank
Acteur : Utilisateur M-Banking
Pré condition : L’utilisateur M-Banking télécharge l’application sur son terminal mobile.
Post condition : L’utilisateur accède à l’espace public avec succès.
Description du scénario principal :
-Le système affiche l’interface principale de l'application.-Le client clique sur le bouton «Espace public».-Le système affiche le menu principal.
54
Scénarii de base:
Suivre les actualités de la banque
-A travers un sliding menu, le client choisit «Actualités».-Le système affiche l’interface appropriée.
Simuler les crédits et les placements
-A travers un sliding menu, le client choisit «Simulateur de crédit » ou «Simulateur de placement».-Le système affiche l’interface appropriée.-L’utilisateur remplit les champs de simulation et clique sur le bouton «Simuler».-Le système affiche le résultat calculé.
Suivre le marché de la bourse
-A travers un sliding menu, le client choisit «Bourse».-Le système affiche l’interface appropriée.
Suivre les cours de devise
-A travers un sliding menu, le client choisit de «Cours de devise».-Le système affiche l’interface appropriée.
A titre d'exemple, nous détaillons le cas d'utilisation «Suivre les cours de devise». Le scénario
pour le suivi de la bourse et des actualités estidentique à celui des cours de devise. Concernant les
simulateurs, il s’agit des simples calculs que l’utilisateur aura la possibilité de faire.
Le tableau 13 décrit textuellement le cas d'utilisation «Contacter la banque»
Tableau 12: Description du cas d’utilisation «Contacter la banque»
Cas d’utilisation : Contacter la banque
Acteur : Utilisateur M-Banking
Pré condition : L’utilisateur M-Banking télécharge l’application sur son terminal mobile.
Post condition : L’utilisateur est capable d’accéder à l’espace public avec succès.
Description du scénario principal :
-Le système affiche l’interface principale de l'application.-Le client clique sur le bouton «Espace public».-Le système affiche le menu principal.
Points d'extension:Consulter le système de géolocalisation
-A travers un sliding menu, le client choisit de «Recherche DAB et Agence» puis choisit «Localiser une Agence» ou «Localiser un DAB».-Le système affiche l'interface appropriée qui contient une carte où sont affichés les agences ou les DAB sur le territoire
55
tunisien avec leur coordonnés.
Consulter la liste les points de contact
-A travers un sliding menu, le client choisit de «Liste des points de contact» puis choisit «Liste des Agences» ou «Liste des DAB».-Le système affiche l'interface qui contient les régions dans lesquelles Attijari Bank a une ou plusieurs agence(s) ou DAB.-Le client choisit une région.-Le système affiche la liste appropriée.
3.3 Conception
La conception est la deuxième étape dans un sprint. Elle se traduit par un diagramme de classes et
un diagramme de séquences.
Le diagramme de classes permet de représenter une vue statique du système
d’information. [23]Il identifie la structure des classes du système, y compris les propriétés
et les méthodes de chaque classes, et les diverses relations qui peuvent exister entre les
classes y sont également représentées.
Le diagramme de séquence permet de représenter une vue dynamique du système
d’information. [23] Il permet de décrire les scénarios de chaque cas d'utilisation en
mettant l'accent sur la chronologie des opérations en interaction avec les objets.
Pour les cas d’utilisation de ce Sprint, nous allons présenter ces deux diagrammes.
A titre d'exemple, nous détaillons le cas d'utilisation «Suivre les cours de devise».Le scénario
pour les actualités et le marché de la bourse est identique à celui de devise.
Cas d’utilisation «Suivre les cours de devise»
o Diagramme de classes
Le diagramme de classes du cas d’utilisation «Suivre les cours de devise» se traduit par les
différentes classes participantes à la réalisation de ce dernier
La figure 31 illustre le diagramme de classes du cas d’utilisation «Suivre les cours de devise».
56
Figure 31: Diagramme de classes du cas d’utilisation «Suivre les cours de devise»
o Diagramme de séquences
A travers ce diagramme, nous allons décrire le scénario du cas d’utilisation «Suivre les cours de
devise». L’utilisateur M-Banking d’Attijari Bank accède au menu public et consulte la liste des
cours de devise à travers le web service «GetDevise».
La figure 32 illustre le diagramme de séquences du casd’utilisation «Suivre les cours de devise».
Figure 32: Diagramme de séquences du cas d’utilisation «Suivre les cours de devise»
Cas d’utilisation «Contacter la banque»
o Diagramme de classes
Le diagramme de classes du cas d’utilisation «Contacter la banque» se traduit par les différentes
classes participantes à la réalisation de ce dernier.
57
La figure 33 illustre le diagramme de classes du cas d’utilisation «Contacter la banque».
Figure 33: Diagramme de classes du cas d’utilisation «Contacter la banque»
o Diagramme de séquences
A travers ce diagramme, nous allons décrire le scénario du cas d’utilisation «Contacter la
banque». Si l’utilisateur M-Banking d’Attijari Bank choisit de contacter la banque, il peut
prendre un rendez-vous et/ou envoyer un message et/ou appeler la banque directement du
téléphone.
58
IU_ContacterBanqueradio_groupe : RadioGroup
saisir()onClick()()afficher(msg)()ViderChamps()charger_formulaire()
<<boundary>>
rendezvousid_dde_rendv : Stringnom : Stringprenom : Stringtel : Stringemail : Stringplage_horaire : Stringmessage : Stringtype_user : Stringtype_oper : Stringdate_oper : Dateuser_oper : Stringdate_val : Dateuser_val : Stringetat_demande : Stringdate_demande : Datetypdoc : Stringnumdoc : Stringdate_rendv1 : Datedate_rendv2 : Datedate_confirme : Date
select()insert()update()
<<entity>>
messageid_envmsg : Stringnom : Stringprenom : Stringemail : Stringtypdoc : Stringtypdemande : Stringmessage : Stringdate_demandetype_user : Stringtype_oper : Stringuser_oper : Stringdate_oper : Stringnumdoc : Stringetat_demande : Stringtel : String
select()insert()update()
<<entity>>
comptenumcpt : Stringclebct : Stringcodbanq : Stringcodugbct : Stringtypdoc : Stringnumdoc : Stringnom : Stringprenom : Stringdatclo : Stringadressecpt : Stringsin : String
select()
<<entity>>
IU_PrendreRendezVousnom : EditTextprenom : EditTexttelephone : EditTextemail : EditTextdate1 : EditTextdate2 : EditTextplageHoraire : SpinnertypeDocument : SpinnernumDocument : EditTextagence : AutocompleteEditTextobjet : EditTextnomClient : TextViewPrenomClient : TextViewcodeClient : TextViewnumCompte : SpinnertypeDocumentClient : TextViewnumDocumentClient : TextViewValider : Button
saisir()()onClick()()afficher(msg)()ViderChamps()charger_formulaire()GetResponseRendezVousClient()GetResponseRendezVousPublic()GetResponseNumCompte()
<<boundary>>
Utilisateur M-banking
(f rom Serv ices de l'application M-banking)...)
C_ContacterBanque
MessageClient()MessagePublic()RendezVousClient()RendezVousPublic()GetNumCompte()verifier_saisie()
<<control>>
IU_EnvoyerMessagenom : EditTextprenom : EditTexttelephone : EditTextemail : EditTextmessage : EditTexttypeDocument : SpinnernumDocument : EditTexttypeDemande : SpinnernomClient : TextViewPrenomClientt : TextViewcodeClient : TextViewtypeDocumentClient : TextViewnumDocumentClient : TextViewEnvoyer : Button
saisir()charger_formulaire()onClick()()afficher(msg)()ViderChamps()GetResponseMessageClient()GetResponseMessagePublic()
<<boundary>>
Pour le cas de prise d’un rendez-vous et envoi d’un message deux scénarios sont
possibles : un pour les clients d’Attijari Bank, qui trouveront dans l’interface des
informations personnelles affichées tel que le nom, prénom, code client, numéro de
compte...,et doivent également saisir d’autres informations supplémentaires Et l’autre
pour les clients potentiels de la banque qui doivent saisir plusieurs informations
d’identification.
Pour le cas d’appel, l’utilisateur M-Banking peut effectuer un appel direct vers le centre
de relation client.
La figure 34 illustre le diagramme de séquences du cas d’utilisation «Contacter la banque»
59
60
Figure 34: Diagramme de séquences du cas d’utilisation «Contacter la banque» Partie1
61Figure 35 : Diagramme de séquences du cas d’utilisation «Contacter la banque» Partie2
Cas d’utilisation «Consulter le système de géolocalisation»
o Diagramme de classes
Le diagramme de classes du cas d’utilisation «Consulter le système de géolocalisation» se traduit
par les différentes classes participantes à la réalisation de ce dernier.
La figure 36 illustre le diagramme de classes du cas d’utilisation «Consulter le système de
géolocalisation».
Figure 36: Diagramme de classes du cas d’utilisation «Consulter le système de géolocalisation»
o Diagramme de séquences
A travers ce diagramme, nous allons décrire le scénario du cas d’utilisation «Consulter le système
de géolocalisation».Si l’utilisateur M-Banking d’Attijari Bank choisit de consulter le système de
géolocalisation, il peut visualiser la carte de toutes les agences d’Attijari Bank et/ou visualiser la
carte de tous les DAB d’Attijari Bank
62
La figure 37 illustre le diagramme de séquences du casd’utilisation «Consulter le système de
géolocalisation »
Cas d’utilisation «Consulter la liste des points de contact»
o Diagramme de classes
Le diagramme de classes du cas d’utilisation «Consulter la lister des points de contact» se
traduit par les différentes classes participantes à la réalisation de ce dernier.
63
Figure 37: Diagramme de séquences du cas d’utilisation «Consulter le système de géolocalisation »
La figure 38 illustre le diagramme de classes du cas d'utilisation«Consulter la lister des points de
contact».
Figure 38 : Diagramme de classes du cas d'utilisation «Consulter la lister des points de contact».
o Diagramme de séquences
A travers ce diagramme, nous allons décrire le scénario du cas d’utilisation «Consulter la liste des
points de contact». Si l’utilisateur M-Banking d’Attijari Bank choisit de consulter la lister des
points de contact, il peut consulter la liste de toutes les agencesd’Attijari Bank par région et/ou
consulter la liste de tous les DAB d’Attijari Bank
64
Utilisateur M-banking
(f rom Serv ices de l'application M-banking)...)IU_ConsulterListePoinstDeContact
radio_groupe : RadioGroup
onItemClick()charger_formulaire()
<<boundary>>
IU_ListeRegionsListeRégions : ListNomRegion : TextViewLogoAttijari : ImageView
onItemClick()GetResponseRegion()onClick()
<<boundary>>
IU_ListeAgenceListeAgenes : ListNomAgence : TextViewAdresseAgence : TextViewTelephoneAgence : TextViewFaxAgence : TextView
onItemClick()GetResponseAgenceRegion()
<<boundary>>
IU_ListeDABListeDAB : ListnomDAB : TextViewadresseDAB : TextView
onItemClick()GetResponseDABRegion()
<<boundary>>
DABcode_dab : Stringnom_dab : Stringadresse_dab : Stringaltitude_dab : Numberlongitude_dab : Numberzoom_dab : Integertype_oper : Stringdate_oper : Dateuser_oper : String
select()insert()update()
<<entity>>
C_ConsulterListePointsDeContact
GetAgenceRegion()GetDABRegion()GetRegion()
<<control>>
agencecode_ug : Stringnom_ug : Stringadresse_ug : Stringaltitude_ug : Stringlongitude_ug : Stringzoom_ug : integertel_ug : Stringfax_ug : Stringtype_oper : Stringdate_oper : dateuser_oper : String
select()insert()update()
<<entity>>
regioncode_regionlanguetitre_region
select()update()insert()
<<entity>>+1
+1.nappartient
+1..n
+1appartient
La figure 39 illustre le diagramme de séquences du casd’utilisation «Consulter la lister des points
de contact»
3.4 TestL'approche Agile met le test au cœur des projets. Pour Scrum et les méthodes agiles en général, le
test ne se fait pas après la fin de développement. Au contraire, le test est une phase intégrée dès
le début du premier sprint jusqu'à la livraison du produit final.
Nous illustrons à ce niveau les captures d’écran réalisés au niveau de ce sprint. Après avoir
s’authentifier, le client d’Attijari Bank se trouve capable de bénéficier des différents services
bancaires offerts par Attijari Bank.
La figure 40 illustre l’interface du menu public.
65
Figure 39: Diagramme de séquences du cas d’utilisation «Consulter la lister des points de contact»
La figure 41 illustre l’interface de suivi des cours de devise.
Figure 40 : Interface du menu public Figure 41 : Interface de suivi des cours de devise
L’interface de consultation de la liste des agences divise en deux:
-La figure 42 illustre l’interfacede consultation des comptes ainsi que le solde de chaque compte.
-La figure 43 illustre l’interface des mouvements du compte approprié.
66
Figure 42: Interface de consultation de la liste des régions.
Figure 43: Interface de consultation de la liste des agences.
La figure 44 illustre l’interface d’envoi d’un message pour un abonné.
La figure 45 illustre l’interface permettant d’appeler la banque.
Figure 44 : Interface d’envoi d’un pour un abonné Figure 45: Interface d’appel
67
4. Conclusion
Le résultat d’un release est un produit livrable au client contrairement au résultat d’un sprint qui
est un produit potentiellement livrable. A la fin de ce chapitre, nous avons réussi à produire un
incrément ayant suffisamment de valeur pour notre client. Dans le chapitre qui suit, notre effort
sera consacré pour produire un nouveau release couvrant les fonctionnalités de gestion de
l’application mobile.
68
Chapitre 4 Développement de l'application
Backoffice
1. Introduction
Notre deuxième release sera composé de quatre sprints. Tout au long de ce chapitre, nous allons
traiter les histoires utilisateurs (User story) de nos sprints pour produire un ensemble d'incréments
potentiellement livrable. Avant de se lancer dans le premier sprint, l'équipe doit définir le but de
ce dernier qui doit être défini en terme métier et non pas en terme technique pour qu'il soit
compréhensible par les membres en dehors de l’équipe. Il s’agit de répondre à une question
fondamentale «Pourquoi faisons-nous ce sprint?».
2. Sprint 1 : Administration
Au début de chaque sprint, on définit un objectif et on lui associe une liste de fonctionnalités qui
constitueront le backlog de sprint. Au cours d'un sprint, l'objectif et la composition de l'équipe ne
peuvent être modifiés.
Ci-dessous la définition de l'objectif et des développeurs de ce sprint.
Objectif : L’administration de l'application Web: gérer les agences, les DAB, les régions et les abonnés.
Développeurs : Team.
2.1 Sprint planning ou planification du sprint
Une fois nous avons défini le but de notre sprint, il est temps de décider quelles histoires de notre
backlog du produit inclure dans le backlog du sprint.
Le tableau 14 résume donc le backlog du premier sprint.
69
Tableau 13 : Sprint1 backlog
Id Nom Description Priorité
1 Ajouter une agence En tant qu'administrateur, je veux ajouter une nouvelle agence afin que mon application soit mise à jour.
10
2 Modifier les coordonnées d'une agence.
En tant qu’administrateur, je veux modifier les coordonnées d'une agence afin que mon application soit mise à jour.
10
3 Supprimer une agence En tant qu'administrateur, je veux désactiver une agence afin que mon application soit mise à jour.
10
4 Ajouter un DAB En tant qu'administrateur, je veux ajouter un DAB afin que mon application soit mise à jour.
10
5 Modifier les coordonnées d'un DAB.
En tant qu'administrateur, je veux modifier les coordonnées d'un DAB afin que mon application soit mise à jour.
10
6 Supprimer un DAB En tant qu'administrateur, je veux désactiver un DAB afin que mon application soit mise à jour.
10
7 Ajouter un abonné En tant qu'administrateur, je veux ajouter un abonné afin que mon application soit mise à jour.
10
8 Mettre à jour les coordonnées d'un abonné
En tant qu'administrateur, je veux mettre à jour les coordonnées des clients M-Banking (en cas de changement de mot de passe ou de numéro de tel ou de nom) afin de faciliter l'accès pour nos clients.
10
9 Supprimer un abonné En tant qu'administrateur, je veux supprimer un abonné afin que mon application soit mise à jour.
10
Passons maintenant au vif de notre sujet : les activités et le cycle de développement. Dans un sprint nous pouvons dégager trois étapes principales qui sont la spécification fonctionnelle, la conception, et le test. Tout au long de ce sprint, nous respectons ces activités pour construire le plan de notre travail.
2.2 Spécification fonctionnelle
Dans cette partie, nous procéderons par un diagramme de cas d'utilisation du sprint puis une
description textuelle de ses histoires utilisateurs.
70
2.2.1 Diagramme de Cas d'utilisation
Après authentification, l'administrateur se trouve capable de gérer les abonnées, les agences, les
DAB et les régions.
La figure 46 illustre le diagramme de cas d’utilisation global du Sprint 1.
A titre d'exemple, nous détaillons le cas d'utilisation «Gérer les agences» et les autres cas d'utilisation généralisés suivent le même principe.
Après avoir s'authentifier, l'administrateur de l'application Mobile Banking pourra gérer les agences. La gestion inclut l'opération d'ajout, de modification des coordonnées et de suppression.
La figure 47 illustre le diagramme de cas d’utilisation «Gérer les agences».
71
Figure 46 : Diagramme de cas d’utilisation global du Sprint 1
Figure 47 : Diagramme de cas d’utilisation «Gérer les agences»
2.2.2 Description textuelle
Le tableau 15 décrit textuellement le cas d'utilisation «Gérer les agences»
Tableau 14 : Description textuelle du cas d’utilisation «Gérer les agences»
Cas d’utilisation : Gérer les agences
Acteur : Administrateur M-Banking Attijari Bank
Pré condition : -L’administrateur M-Banking Attijari Bank est identifié comme étant un administrateur.
Post condition : Une nouvelle agence est ajoutée, modifiée ou supprimée avec succès.
Description du scénario principal :
-Le système affiche l'interface principale.-L'administrateur clique sur l'onglet Agences.-Le système affiche l'interface appropriée.-Le client clique sur l'onglet "Agences".
Point d'extension :Ajouter une agence
-Le système affiche l'interface relative à «Ajouter une agence »-L'administrateur remplit les champs demandés et clique sur Enregistrer.-Le système enregistre les données et affiche un message de succès.
Point d'extension :Modifier les coordonnées d'une agence
-Le système affiche l'interface relative à «Modifier les coordonnées d'une agence»-L'administrateur remplit les champs demandés et clique sur Enregistrer.-Le système enregistre les données et affiche un message de succès.
Point d'extension : Supprimer une agence
-Le système affiche l'interface relative à «Supprimer une agence»-L'administrateur remplit les champs demandés et clique sur Enregistrer.-Le système enregistre les données et affiche un message de succès.
2.3 Conception
La conception est la deuxième étape dans un sprint. Elle se traduit par un diagramme de classes et
un diagramme de séquences.
72
Le diagramme de classes permet de représenter une vue statique du système
d’information [23].Il identifie la structure des classes du système, y compris les propriétés
et les méthodes de chaque classe, et les diverses relations qui peuvent exister entre les
classes y sont également représentées.
Le diagramme de séquences permet de représenter une vue dynamique du système
d’information. [23]. Il permet de décrire les scénarios de chaque cas d'utilisation en
mettant l'accent sur la chronologie des opérations en interaction avec les objets.
Pour le Sprint 1 «Administration» nous allons présenter les diagrammes de classes et de
séquences de l'opération «Gestion des agences» seulement puisque la gestion des abonnées, des
DAB et des régions suit le même principe.
o Diagramme de classes
Le diagramme de classes du cas d’utilisation «Gérer les agences» se traduit par les différentes
classes participantes à la réalisation de ce dernier.
La figure 48 illustre le diagramme de classes du cas d'utilisation «Gérer les agences».
o Diagramme de séquences
A travers ce diagramme, nous décrivons le scénario du même cas d’utilisation. L’administrateur
choisit l'opération à effectuer: Ajouter, supprimer ou modifier les coordonnées d'une agence.
Aussi, il peut effectuer une recherche avancée sur l'agence à modifier ou à supprimer.
La figure 49 illustre le diagramme de séquences du cas d’utilisation «Gérer les agences».
73
Figure 48 : Diagramme de classes du cas d’utilisation «Gérer les agences»
74
Figure 49 : Diagramme de séquences du cas d’utilisation «Gérer les agences»
2.4. Test L'approche Agile met le test au cœur des projets. Pour Scrum et les méthodes agiles en général, le
test ne se fait pas après la fin de développement. Au contraire, le test est une phase intégrée dès
le début du premier sprint jusqu'à la livraison du produit final.
Nous illustrons à ce niveau les captures d’écran réalisés au niveau de ce Sprint. Commençons par
l’interface principale de la gestion des agences et par la suite nous illustrons les fonctionnalités
d'ajout, de modification et de suppression d'une agence.
La figure 50 illustre l'interface principale de la gestion des agences.
La figure 51 illustre l'opération de suppression d'une agence
75
Figure 51 : Interface de l’opération de suppression d’une agence
Figure 50 : Interface principale de la gestion des agences
La figure 52 illustre l'opération d'ajout d'une agence
La figure 53 illustre l'opération de modification des coordonnées d'une agence
76
Figure 52 : Interface de l’opération d’ajout d’une agence
Figure 53 : Interface del’opération de modification des coordonnées d’une agence
3. Sprint 2: Gestion des demandes transactionnelles (Cartes,
Chéquiers, Virements)
Au début de chaque sprint, on définit un objectif et on lui associe une liste de fonctionnalités qui
constitueront le backlog de sprint. Au cours d'un sprint, l'objectif et la composition de l'équipe ne
peuvent être modifiés.
Ci-dessous la définition de l'objectif et des développeurs de ce sprint.
Objectif : Gestion des demandes d'obtention et demandes d'opposition sur les cartes et les chéquiers. Egalement, la gestion des demandes de virements.
Développeurs : Team.
3.1 Sprint planning ou planification du sprint
Une fois nous avons défini le but de notre sprint, il est temps de décider quelles histoires de notre
backlog du produit inclure dans le backlog du sprint.
Le tableau 16 résume donc le backlog du deuxième sprint.
Tableau 15 : Sprint 2 backlog
Id Nom Description Priorité
1 Accepter la demande d'obtention d'une carte
En tant qu'administrateur, je veux accepter la demande afin de répondre aux demandes des clients.
10
2 Décliner la demande d'obtention d'une carte
En tant qu'administrateur, je veux décliner la demande afin de respecter les conditions d'obtention d'une carte bancaire.
10
3 Supprimer la demande d'obtention d'une carte
En tant qu'administrateur, je veux supprimer la demande afin de mettre à jour les données.
10
4 Accepter la demande d'opposition sur une carte
En tant qu'administrateur, je veux accepter la demande afin de répondre aux demandes des clients.
10
5 Décliner la demande d'opposition sur une carte
En tant qu'administrateur, je veux décliner la demande afin de respecter les conditions d'opposition d'une carte.
10
77
6 Supprimer la demande d'opposition sur une carte
En tant qu'administrateur, je veux supprimer la demande afin de mettre à jour les données.
10
7 Accepter la demande d'obtention d'un chéquier
En tant qu'administrateur, je veux accepter la demande afin de répondre aux demandes des clients..
10
8 Décliner la demande d'obtention d'un chéquier
En tant qu'administrateur, je veux décliner la demande afin de respecter les conditions d'obtention d'un chéquier.
10
9 Supprimer la demande d'obtention d'un chéquier
En tant qu'administrateur, je veux supprimer la demande afin de mettre à jour les données.
10
10 Accepter la demande d'opposition sur un chéquier
En tant qu'administrateur, je veux accepter la demande afin de répondre aux demandes des clients.
10
11 Décliner la demande d'opposition sur un chéquier
En tant qu'administrateur, je veux décliner la demande afin de respecter les conditions d'opposition sur chéquier.
10
12 Supprimer la demande d'opposition sur un chéquier
En tant qu'administrateur, je veux supprimer la demande afin de mettre à jour les données.
10
13 Consulter les demandes d'obtention et d'opposition de cartes et de chéquiers
En tant qu'administrateur, je veux consulter les demandes d'obtention ou d'opposition sur chéquiers ou sur cartes afin de vérifier les données.
10
14 Accepter la demande de virement
En tant qu'administrateur, je veux accepter la demande afin de répondre aux demandes des clients.
10
15 Décliner la demande de virement
En tant qu'administrateur, je veux décliner la demande afin de respecter les conditions de virements
10
16 Supprimer la demande de virement
En tant qu'administrateur, je veux supprimer la demande afin de mettre à jour les données.
10
17 Consulter la liste des anciens virements
En tant qu'administrateur, je veux consulter les demandes de virements afin de vérifier les données.
10
Passons maintenant au vif de notre sujet : les activités et le cycle de développement. Dans un sprint nous pouvons dégager trois étapes principales qui sont la spécification fonctionnelle, la
78
conception, et le test. Tout au long de ce sprint, nous respectons ces activités pour construire le plan de notre travail.
3.2 Spécification fonctionnelle
Dans cette partie, nous procéderons par un diagramme de cas d'utilisation du sprint puis une
description textuelle de ses histoires utilisateurs.
3.2.1 Diagramme de Cas d'utilisation
Après avoir s'authentifier, l'administrateur se trouve capable de gérer les demandes
transactionnelles des clients de la banque qui sont les demandes d'obtention ou de opposition sur
cartes ou chéquiers et les demandes de virements réalisés par le client.
La figure 54 illustre le diagramme de cas d’utilisation global du deuxième sprint.
Figure 54 : Diagramme de cas d’utilisation globale Sprint2
A titre d'exemple, nous traitons le cas de demandes d'obtention de carte puisque le même scénario
se produit pour les autres cas d'utilisations générés qui sont «Gérer les demandes de chéquiers» et
«Gérer les demandes de virements».
Après authentification, l'administrateur pourra gérer les demandes d'obtention ou d'opposition sur
cartes réalisées par les clients; Il peut soit approuver une demande, si toutes les conditions sont
vérifiées, soit décliner les demandes, si une des conditions n'est pas vérifiée, ou supprimer la
demande si c'était juste une demande de test effectuée par l'équipe de développement. Aussi,
l'administrateur pourra consulter la liste des anciennes demandes déjà traitées.
79
La figure 55 illustre le diagramme de cas d’utilisation «Gérer les demandes de cartes»
Figure 55 : Diagramme de cas d’utilisation «Gérer les demande de cartes»
.
3.2.2 Description textuelle
Pour la gestion des cartes, le client a le choix entre effectuer une demande d'obtention ou
d'opposition. A titre d'exemple, notre raffinement se limite du cas d'utilisation généré : «Gérer les
demandes d'obtention».
Le tableau 17 décrit textuellement cas d’utilisation «Gérer les demandes d'obtention»
Tableau 16 : Description textuelle du cas d’utilisation «Gérer les demande d'obtention»
Cas d’utilisation : Gérer des demandes d'obtention
Acteur : Administrateur M-Banking Attijari Bank
Pré condition : -L’employé d’Attijari Bank est identifié comme étant un administrateur de l’application web du M-Banking.
Post condition : La table demande carte est mise à jour.Description du scénario principal :
-Le système affiche l'interface appropriée.-L'administrateur choisit l'opération qu'il désire effectuer en cliquant sur un bouton de commande.-Le système enregistre les données et affiche l'interface appropriée.
Points d'extension :Accepter une demande
-Le système affiche le dialogue relatif à «Accepter une demande»-L'administrateur traite la demande et enregistre son traitement-Le système enregistre les données.
80
Décliner une demande -Le système affiche le dialogue relatif à «Décliner une demande»-L'administrateur traite la demande et enregistre son traitement-Le système enregistre les données.
Supprimer une demande
-Le système affiche le dialogue relatif à «Supprimer une demande»-L'administrateur traite la demande et enregistre son traitement-Le système enregistre les données.
Consulter les anciennes demandes
-Le système affiche l'interface relative à la consultation des anciennes demandes.-L'administrateur peut faire une recherche avancée.
3.3 Conception
La conception est la deuxième étape dans un sprint. Elle se traduit par un diagramme de classes et
un diagramme de séquences.
Le diagramme de classes permet de représenter une vue statique du système
d’information.[23]Il identifie la structure des classes du système, y compris les propriétés
et les méthodes de chaque classes, et les diverses relations qui peuvent exister entre les
classes y sont également représentées.
Le diagramme de séquence permet de représenter une vue dynamique du système
d’information.[23] Il permet de décrire les scénarios de chaque cas d'utilisation en mettant
l'accent sur la chronologie des opérations en interaction avec les objets.
Comme déjà expliqué, nous illustrons seulement le cas d'utilisation généralisé «Gérer les
demandes de cartes».
o Diagramme de classes
Le diagramme de classes du cas d’utilisation «Gérer les demandes de cartes» se traduit par
les différentes classes participantes à la réalisation de ce dernier.
81
La figure 56 illustrant le diagramme de classes du cas d’utilisation «Gérer les demandes de cartes».
82
C_ConsulDdeCarte
initConsulDdeCarteForm()filterBy()initGestionConsulDdeCarte()
<<control>>
dde_carteid_dde_carte : stringetat_demande : stringdate_demande : dateuser_valid : stringdate_valid : datetype_oper : stringuser_oper : stringdate_oper : datenom : stringprenom : stringtype_carte : stringtypdoc : stringnumdoc : string
select()insert()update()
<<entity>>
C_GérerLesDemandesDeCarte
confirmerDdeCarte()declinerDdeCarte()supprimerDdeCarte()initiate()filterBy()initGestionDdeCarte()
<<control>>
C_ConsulDdeOpCarte
nitGestionConsulDdeOpCarte()filterBy()initConsulDdeOpCarteForm()
<<control>>
IU_GérerLesDemandesDeCartesAccepter la demande : commandButtonDécliner la demande : commandButtonSupprimer la demande : commandButtonOui : commandButtonNon : commandButton
afficher(dialogue)()fermer(dialogue)()click(btn)()afficher(msg)()saisir()
<<boundary>>
IU_ConsulDdeCarte
sasir()
<<boundary>>
IU_ConsulDdeOpCarte
saisir()
<<boundary>>
Administrateur M-banking d'Attijari Bank
(f rom Serv ices de l'application M-banking)...)
dde_op_carteid_op_carte : Stringdate_valid : Dateuser_valid : Stringetat_demande : Stringdate_demande : Datetype_oper : Stringdate_oper : Stringuser_oper : String
select()insert()update()
<<entity>>
C_GérerLesDemandesOpCarte
confirmerDdeOpCarte()declinerDdeOpCarte()supprimerDdeOpCarte()initiate()filterBy()initGestionDdeOpCarte()
<<control>>IU_GérerLesDemandesOpCarte
Accepter la demande : commandButtonDécliner la demande : commandButtonSupprimer la demande : commandButtonOui : commandButtonNon : commandButton
afficher(dialogue)()fermer(dialogue)()click()afficher()saisir()
<<boundary>>
Figure 56 : Diagramme de classes du cas d’utilisation «Gérer les demandes de carte»
o Diagramme de séquences
L'administrateur gère les demandes d'obtention et d'opposition sur cartes ; Dans les deux cas il peut soit accepter une demande, la décliner ou bien la supprimer s'il s'agit d'une demande de test effectuée par l'équipe de
développement. Egalement, l'administrateur peut consulter les demandes qui sont déjà traité auparavant. Et encore il peut effectuer une recherche avancée "La fonction (Saisir)" par code client, nom et d'autres critères.
A titre d'exemple nous illustrons le diagramme de séquence du cas d'utilisation généré «Gérer les demandes d'obtention des cartes ».
83
Figure 57: Cas d'utilisation généré «Gérer les demandes d'obtention »
3.4 Test
L'approche Agile met le test au cœur des projets. Pour Scrum et les méthodes agiles en général, le
test ne se fait pas après la fin de développement. Au contraire, le test est une phase intégrée dès
le début du premier sprint jusqu'à la livraison du produit final.
Nous illustrons à ce niveau les captures d’écran réalisés au niveau de ce sprint. Après avoir
s’authentifier, le client d'Attijari Bank se trouve capable de bénéficier des différents services
bancaires offerts par Attijari Bank.
La figure 58 illustre l’interface de gestion des demandes d'obtention de cartes.
La figure 59 illustre l'interface de la consultation des demandes cartes (demandes qui sont déjà
traitées).
84
Figure 58 : Interface de la gestion des demandes d’obtention
Figure 59 : Consultation des demandes de cartes
4. Sprint 3: Gestion des contacts
Au début de chaque sprint, on définit un objectif et on lui associe une liste de fonctionnalités qui
constitueront le backlog de sprint. Au cours d'un sprint, l'objectif et la composition de l'équipe ne
peuvent être modifiés.
Ci-dessous la définition de l'objectif et des développeurs de ce sprint.
Objectif : La gestion de contacts qui inclut la gestion des messages envoyés par les clients et des demandes de rendez-vous.
Développeurs : Team.
4.1 Sprint planning ou planification du sprint
Une fois nous avons défini le but de notre sprint, il est temps de décider quelles histoires de notre
backlog du produit inclure dans le backlog du sprint.
Le tableau 18 résume donc le backlog du troisième sprint
Tableau 17 : Sprint 3 backlog
Id Nom Description Priorité
1 Confirmer la demande de rendez-vous
En tant qu'administrateur, je veux accepter la demande afin d'organiser les visites des clients à l'agence.
10
2 Consulter la liste des anciens rendez-vous
En tant qu'administrateur, je veux consulter la liste des anciens rendez-vous afin de vérifier les données.
10
3 Confirmer la réception d'un message
En tant qu'administrateur, je veux confirmer la réception d'un message afin que la réclamation ou la suggestion du client soit prise en compte.
10
4 Consulter la liste des messages archivés
En tant qu'administrateur, je veux consulter la liste des messages archivés afin de vérifier les données
10
Passons maintenant au vif de notre sujet : les activités et le cycle de développement. Dans un Sprint nous pouvons dégager trois étapes principales qui sont la spécification fonctionnelle, la conception, et le test. Tout au long de ce Sprint, nous respectons ces activités pour construire le plan de notre travail.
85
4.2 Spécification fonctionnelle
Dans cette partie, nous procéderons par un diagramme de cas d'utilisation du sprint puis une
description textuelle de ses histoires utilisateurs.
4.2.1 Diagramme de Cas d'utilisation
Après avoir s'authentifier, l'administrateur pourra gérer les demandes de contact effectuées par les
abonnés qui sont une demande de rendez-vous ou un envoi de message dans le but de réclamer ou
de suggérer. Ces deux moyens de contact doivent être gérer par l’administrateur.
La figure 60 illustre le diagramme de cas d’utilisation global du troisième Sprint..
4.2.2 Description textuelle
Les tableaux suivants présentent la description textuelle des cas d'utilisation générés du cas
«Gestion des contacts»
Le tableau 19 décrit textuellement le cas d'utilisation «Gérer les demandes de rendez-vous»
86
Figure 60 : Diagramme de cas d’utilisation global Sprint3
Tableau 18 : Description textuelle du cas d’utilisation «Gérer les demandes de rendez-vous»
Cas d’utilisation : Gérer les demandes de rendez-vous
Acteur : Administrateur M-Banking Attijari Bank
Pré condition : -Administrateur M-Banking Attijari Bank est identifié comme étant un administrateur.
Post condition : Les demandes de rendez-vous sont traitées.Description du scénario principal :
-Le système affiche l'interface appropriée.-L'administrateur traite la demande et confirme son traitement.
Point d'extension :Consulter la liste des anciens rendez-vous
-Le système affiche l’interface relative à «Consulter la liste des anciens rendez-vous»
Le tableau 20 décrit textuellement le cas d'utilisation «Gérer les messages»
Tableau 19 : Description textuelle du cas d'utilisation «Gérer les messages»
Cas d’utilisation : Gérer les messages
Acteur : Administrateur M-Banking Attijari Bank
Pré condition : - Administrateur M-Banking Attijari Bank est identifié comme étant un administrateur.
Post condition : -Les messages sont bien reçus.Description du scénario principal :
-Le système affiche l'interface appropriée.-L'administrateur choisit l'opération qu'il doit effectuée en cliquant sur un bouton de commande
Point d'extension :Confirmer les demandes de rendez vous
-Le client traite la demande de rendez vous du client et enregistre les modifications.-Le système enregistre les données.
Consulter la liste des anciens rendez-vous
-Le système affiche l’interface relative à «Consulter la liste des messages archivés»
4.3 Conception
La conception est la deuxième étape dans un sprint. Elle se traduit par un diagramme de classes et
un diagramme de séquences.
Le diagramme de classes permet de représenter une vue statique du système
d’information.[23].Il identifie la structure des classes du système, y compris les propriétés
87
et les méthodes de chaque classes, et les diverses relations qui peuvent exister entre les
classes y sont également représentées.
Le diagramme de séquence permet de représenter une vue dynamique du système
d’information.[23].Il permet de décrire les scénarios de chaque cas d'utilisation en mettant
l'accent sur la chronologie des opérations en interaction avec les objets.
Pour les cas d’utilisation de ce Sprint, nous allons présenter ces deux diagrammes.
o Diagramme de classes
Le diagramme de classes du cas d’utilisation «Gestion de contacts» se traduit par les différentes
classes participantes à la réalisation de ce dernier.
o Diagramme de séquences
88
messageid_envmsg : Stringnom : Stringprenom : Stringemail : Stringtypdoc : Stringtypdemande : Stringmessage : Stringdate_demande : Datetype_user : Stringtype_oper : Stringuser_oper : Stringdate_oper : Datenumdoc : Stringetat_demande : Stringtel : String
insert()update()
<<entity>>
C_GérerLesMessages
initEnvMsgForm()archiverMsg()
<<control>>
C_GérerLesMessagesArchivés
initEnvMsgArchiveForm()
<<control>>
IU_GérerLesMessagesOui : commandButtonNon : commandButtonDétails
click()fermer(dialogue)()aficher(dialogue)()afficher(msg)()initGestionEnvMsg()saisir()
<<boundary>>
IU_GérerLesMessagesArchivésDétails : commandButton
click()afficher(dialogue)()fermer(dialogue)()initGestionEnvMsgArchive()saisir()
<<boundary>>
IU_GérerRendezvousSupprimer le rendez-vous : commandButtonConfirmer le rendez-vous : commandButtonDétails : commandButtonOui : commandButtonNon : commandButton
click()initGestionRendezVous()afficher(dialogue)()fermer(dialogue)()afficher(msg)()saisir()
<<boundary>>
Administrateur M-banking d'Attijari Bank
(f rom Serv ices de l'application M-banking)...)
C_GérerRendezvous
initRendezVousForm()confirmerRendezvous()supprimerRendezvous()ondateSelect()filterBy()
IU_GérerAncienRendezvousDétails : commandButton
click()initGestionAncienRendezvous()afficher(dialogue)()fermer(dialogue)()saisir()
<<boundary>>
rendezvousid_dde_rendv : Stringnom : Stringprenom : Stringtel : Stringemail : Stringplage_horaire : Stringmessage : Stringtype_user : Stringtype_oper : Stringdate_oper : Stringuser_oper : Stringdate_val : Dateuser_val : Stringetat_demande : Stringdate_demande : Datetypdoc : Stringnumdoc : Stringdate_rendv1 : Datedate_rendv2 : Datedate_confirme : Date
insert()update()select()
<<entity>>
C_GérerAncienRendezvous
initAncienRendezvousForm()filterBy()initGestionAncienRendv()
<<control>>
Figure 61 : diagramme de classe du cas d’utilisation «Gestion des contacts»
A titre d'exemple nous illustrons le diagramme de séquence de«Gérer les rendez-vous » puisque
c'est le même principe que celui de la gestion des messages.
Après authentification, l'administrateur aura accès à l'interface de gestion des rendez-vous où il
pourra soit confirmer la demande de rendez-vous dans l'une des dates proposés par le client ou
proposer une autre date selon la disponibilité du chargé clientèle de son agence, soit supprimer la
demande et contacter le client par téléphone. D'autre part, l'administrateur peut consulter la liste
des anciens rendez-vous. Dans les deux cas, il peut faire une recherche avancée pour faciliter sa
tâche.
La figure 63 illustre le diagramme de séquences du cas d’utilisation «Gérer les messages».
89
90
Figure 62 Diagramme de séquences du cas d’utilisation «Gérer les messages»
4.4 Test
L'approche Agile met le test au cœur des projets. Pour Scrum et les méthodes agiles en général, le
test ne se fait pas après la fin de développement. Au contraire, le test est une phase intégrée dès
le début du premier sprint jusqu'à la livraison du produit final.
Nous illustrons à ce niveau les captures d’écran réalisés au niveau de ce sprint. Après avoir
s’authentifier, l'administrateur de l'application «Attijari Mobile Banking» pourra gérer les
demandes de contact comme expliquer au début de notre sprint 3.
La figure 63 illustre l'interface de gestion de la liste des rendez-vous
La figure 64 illustre l'interface de gestion des rendez-vous
91
Figure 63 : Interface de la gestion de la liste des rendez-vous
Figure 64 : Interface de la gestion des rendez-vous
5. Conclusion
Le résultat d’un release est un produit livrable au client contrairement au résultat d’un sprint qui
est un produit potentiellement livrable. A la fin de ce chapitre, nous avons réussi à produire un
incrément ayant suffisamment de valeur pour notre client. Cet incrément est notre produit final et
donc la fin de ce release marque la fin de notre projet.
92
Chapitre 5 Codage et déploiement
1. Introduction
Dans ce chapitre, nous donnerons un aperçu sur le travail accompli au niveau de
l’implémentation des deux modules M1 (Front Office) et M2 (Back Office) définis dans les
chapitres précédents. Plus précisément, nous allons présenter les diagrammes de composant et
de déploiement de ces deux derniers, ainsi qu’un diagramme de classes global de toute
l’application suivi du schéma de la base de données.
2. Codage
Les travaux menés dans cette étape résument tout simplement dans l’implémentation et la
réalisation des histoires utilisateurs analysés lors des étapes précédentes. Pour notre cas, le
codage se traduit par un diagramme de composants pour chaque module, un diagramme de
classes global de toute l’application et un schéma de la base de données.
2.1 Diagramme de composants
«Le diagramme de composants représente les concepts connus de l’exploitant pour installer et
dépanner le système. Il s’agit dans ce cas de déterminer la structure des composants
d’exploitation que sont les librairies dynamiques, les instances de bases de données, les
applications, les objets distribués, les exécutables, etc…» [24].
Dans ce qui suit, nous allons commencer par présenter le diagramme de composants de
chaque module.
2.1.1 Diagrammes de composants de M1
Les classes d'interfaces et les classes contrôleurs au niveau conceptuel deviennent, au niveau
d'implémentation, les mêmes classes d'interface.Dans notre cas, le contrôleur est le couple
(class.java et webService.PHP).
La figure 88 illustre le diagramme de composants du module M1.
93
2.1.2 Diagrammes de composants de M2
Pour des raisons d'implémentation, le contrôleur dans notre cas est un fichier .XML, le
modèle est un fichier .java qui est le managedBean.
La figure 66 illustre le diagramme de composants du module M2
94
Figure 65 : Digramme de composants du module M1
Figure 66 : Diagramme de composants du module M2
2.2 Diagramme de classes global de l’application
clientcodclt : Stringnom : Stringprenom : Stringtel : Stringmail : Stringtypdoc : Stringnumdoc : String
select()
<<entity>>
DABcode_dab : Stringnom_dab : Stringadresse_dab : Stringaltitude_dab : Numberlongitude_dab : Numberzoom_dab : Integertype_oper : Stringdate_oper : Dateuser_oper : String
select()insert()update()
<<entity>>
regioncode_region : Stringlangue : Stringtitre_region : String
select()insert()update()
<<entity>>
+1.n
+1appartient
parametrecodparamvalparamlibparam
select()
<<entity>>
cartenumcarte : Stringdate_valid : Datenom : Stringprenom : Stringtypdoc : Stringnumdoc : Stringdatedoc : Datetype_carte : Stringdateopp : Datemntretrait : Stringmntpaie : Stringmntdebit : Stringetatcarte : String
select()
<<entity>>
agencecode_ug : Stringnom_ug : Stringadresse_ug : Stringaltitude_ug : Stringlongitude_ug : Stringzoom_ug : integertel_ug : Stringfax_ug : Stringtype_oper : Stringdate_oper : dateuser_oper : String
select()insert()update()
<<entity>>
+1..n+1
appartient
mouvementcodope : Stringlibop : Stringsensop : Stringdatop : Datedag : Datemntop : String
select()
<<entity>>
+1..n +1
est limité par
dde_cheqid_dde_cheq : stringtype_cheq : stringuser_oper : stringdate_oper : datetype_oper : stringdate_demande : dateuser_valid : stringdate_valid : stringetat_demande : string
select()insert()update()
<<entity>>
typcartecodtypcarte : Stringtype_carte : Stringdate_oper : Dateuser_oper : Stringtype_oper : Stringobservation : Stringnature : Stringplancher : Stringbin_carte : String
select()
<<entity>>
dde_virid_dde_vir : Stringmnt_vir : Stringlib_vir : Stringdate_demande : Dateetat_demande : Stringdate_oper : Stringtype_oper : Stringuser_oper : Stringdate_valid : Dateuser_valid : Stringcodugbct_ben : Stringcodbanq_ben : Stringclebct_ben : Stringcodugbct_don : Stringcodbanq_don : Stringclebct_don : Stringdate_vir : Date
select()insert()update()
<<entity>>
dde_op_carteid_op_carte : Stringtype_oper : Stringdate_oper : Stringuser_oper : Stringdate_valid : Dateuser_valid : Stringetat_demande : Stringdate_demande : Date
select()insert()update()
<<entity>>
+1
+1concerne
comptenumcpt : Stringclebct : Stringcodbanq : Stringcodugbct : Stringtypdoc : Stringnumdoc : Stringnom : Stringprenom : Stringdatclo : Stringadressecpt : Stringsin : String
select()opname()
<<entity>>
+1
+1..n
ouvert à
+1..n
+1
+1..n
+1
s'effectue
+Donneur
+Bénificiaire
dde_carteid_dde_carte : Stringetat_demande : Stringdate_demande : Dateuser_valid : Stringdate_valid : Datetype_oper : Stringuser_oper : Stringdate_oper : Datenom : Stringprenom : Stringtype_carte : Stringtypdoc : Stringnumdoc : String
select()insert()update()
<<entity>>
+1
+1..n
concerne
messageid_envmsg : Stringnom : Stringprenom : Stringemail : Stringtypdoc : Stringtypdemande : Stringmessage : Stringdate_demande : Datetype_user : Stringtype_oper : Stringuser_oper : Stringdate_oper : Datenumdoc : Stringetat_demande : Stringtel : String
select()insert()update()
<<entity>>
rendezvousid_dde_rendv : Stringnom : Stringprenom : Stringtel : Stringemail : Stringplage_horaire : Stringmessage : Stringtype_user : Stringtype_oper : Stringdate_oper : Stringuser_oper : Stringdate_val : Dateuser_val : Stringetat_demande : Stringdate_demande : Datetypdoc : Stringnumdoc : Stringdate_rendv1date_rendv2date_confirme
select()insert()update()
<<entity>>
agentmatricule : Stringidnom : Numberpwd : Stringnom : Stringprenom : Stringtelph : Stringtelph_poste : Stringmail : Stringadresse : Stringdate_embauche : Datecout : Numberauthority : Stringflg_suspendu : Number
select()
<<entity>>
+1..n
+1
gére
+1..n
+1
gére
+1..n
+1
gére
+1..n
+1
gére
+1..n
+1
gére
abonneid_abonnepassword_abonnecode_abonneid_mobile
insert()update()
<<entity>>
+1..n
+1
+1..n
+1
demande
+1..n
+1
demande
+1..n
+1
demande
chequiernumchequier : Stringdatelivraison : Datenumdebut : Stringnumfin : Stringtype_cheq : Stringetatchequier : String
select()
<<entity>>
dde_op_cheqid_dde_op_cheq : Stringtype_oper : Stringdate_oper : Dateuser_oper : Stringdate_valid : Stringuser_valid : Stringetat_demande : Stringdate_demande : Datedescription : String
select()insert()update()
<<entity>>
+1..n
+1
gére
+1.n
+1
demande
chequenumchq : Stringdatecheq : Dateetatcheq : Stringmntcheq : Stringnombenef : Stringdateopp : Date
select()
<<entity>>
+1+1
concerne
possede
Figure 67 : Diagramme de classe global de l’application
95
2.3 Schéma de la base de données
Pour construire le schéma de base de données de notre application, nous devons appliquer
certaines règles pour passer d’un schéma entité association (diagramme de classe) vers un
schéma relationnel {Voir Annexe A}.
Dans ce qui suit, nous présentons les tables de notre base de données.
Tableau 20 Table « abonne »
Nom de la table : abonne
Champs Types Contraintes
id_abonne VARCHAR(10) PRIMARY KEY
Nom VARCHAR(255) ---
Prenom VARCHAR(255) ---
password_abonne VARCHAR(255) ---
code_abonne VARCHAR(255) ---
Tel VARCHAR(255) ---
Mail VARCHAR(255) ---
id_mobile VARCHAR(255) ---
Typdoc VARCHAR(20) ---
Numdoc VARCHAR(15) ---
Tableau 21 : Table « region »
Nom de la table : region
Types Contraintes Contraintes
code_region VARCHAR2(3) PRIMARY KEY
Langue VARCHAR2(255) ---
titre_region VARCHAR2(255) ---
96
Tableau 22: Table « client »
Nom de la table : client
Champs Types Contraintes
Codclt VARCHAR2(8) PRIMARY KEY
Nom VARCHAR(30) ---
Prenom VARCHAR(30) ---
Tel VARCHAR(20) ---
Mail VARCHAR(30) ---
typdoc VARCHAR(20) ---
numdoc VARCHAR(15) ---
Tableau 23 : Table « compte »
Nom de la table : compte
Champs Types Contraintes
nucmpt VARCHAR2(13) PRIMARY KEY
clebct VARCHAR2(2) PRIMARY KEY
codugbct VARCHAR2(3) PRIMARY KEY
codbanq VARCHAR2(2) PRIMARY KEY
typdoc VARCHAR2(20) ---
numdoc VARCHAR2(15) ---
Nom VARCHAR2(255) ---
prenom VARCHAR2(255) ---
datclo DATE ---
adressecpt VARCHAR2(255) ---
Sin VARCHAR2(255) ---
97
Tableau 24 : Table « agent »
Nom de la table : agent
Champs Types Contraintes
matricule VARCHAR(5) PRIMARY KEY
idnom NUMBER(10) ---
Pwd VARCHAR2(100) ---
Nom VARCHAR2(50) ---
prenom VARCHAR2(50) ---
Telph VARCHAR2(50) ---
telph_poste VARCHAR2(50) ---
Mail VARCHAR2(100) ---
adresse VARCHAR2(254) ---
date_embauche DATE ---
Cout NUMBER(3) ---
authority VARCHAR(50) ---
flg_suspendu NUMBER(1) ---
Tableau 25 : Table «parametre»
Nom de la table : parametre
Champs Types Contraintes
codparam VARCHAR2(10) PRIMARY KEY
libparam VARCHAR2(255) ---
valparam VARCHAR2(255) ---
Tableau 26 : Table «agence»
Nom de la table : agence
Champs Types Contraintes
98
Codug VARCHAR2(3) PRIMARY KEY
nom_ug VARCHAR2(255) ---
adresse_ug VARCHAR2(255) ---
altitude_ug NUMBER ---
longitude_ug NUMBER ---
zoom_ug NUMBER ---
tel_ug VARCHAR2(255) ---
fax_ug VARCHAR2(255) ---
type_oper VARCHAR2(1) ---
date_oper DATE ---
user_oper VARCHAR(5) ---
Tableau 27 : Table «DAB»"
Nom de la table : DAB
Champs Types Contraintes
Code_dab VARCHAR2(3) PRIMARY KEY
nom_dab VARCHAR2(255) ---
adresse_dac VARCHAR2(255) ---
altitude_dab NUMBER ---
longitude_dab NUMBER ---
zoom_dab NUMBER ---
type_oper VARCHAR2(1) ---
date_oper DATE ---
user_oper VARCHAR(5) ---
Tableau 28 : Table «dde_carte»
Nom de la table dde_carte
Champs Types Contraintes
99
id_dde_carte VARCHAR2(10) PRIMARY KEY
type_carte VARCHAR2(5) ---
date_oper DATE ---
user_oper VARCHAR2(5) ---
type_oper VARCHAR2(1) ---
date_valid DATE ---
user_valid VARCHAR2(1) ---
etat_demande VARCHAR2(1) ---
date_demande DATE ---
Nom VARCHAR2(255) ---
prenom VARCHAR2(255) ---
typdoc VARCHAR2(20) ---
numdoc VARCHAR2(15) ---
Tableau 29 : Table «mouvement»
Nom de la table : mouvement
Champs Types Contraintes
Codop VARCHAR2(10) PRIMARY KEY
Libop DATE ---
sensop VARCHAR2(255) ---
Datop DATE ---
Dag DATE ---
mntop VARCHAR2(255) ---
Tableau 30 : Table «dde_cheq»
Nom de la table : dde_cheq
100
Champs Types Contraintes
id_dde_cheq VARCHAR2(10) PRIMARY KEY
type_cheq VARCHAR2(255) ---
date_oper DATE ---
user_oper VARCHAR2(5) ---
type_oper VARCHAR2(1) ---
date_valid DATE ---
user_valid DATE ---
etat_demande VARCHAR2(1) ---
date_demande DATE ---
Tableau 31 : Table « de_op_carte»
Nom de la table : dde_op_carte
Champs Types Contraintes
id_op_carte VARCHAR2(10) PRIMARY KEY
date_oper DATE ---
user_oper VARCHAR2(5) ---
type_oper VARCHAR2(1) ---
date_valid DATE ---
user_valid DATE ---
etat_demande VARCHAR2(1) ---
date_demande DATE ---
Tableau 32 : Table «dde_op_cheq»
101
Tableau 33 : Table «chequier»
Nom de la table : chequier
Champs Types Contraintes
numchequier VARCHAR2(10) PRIMARY KEY
datelivraison DATE ---
numdebut VARCHAR2(255) ---
numfin VARCHAR2(255) ---
type_cheq VARCHAR2(255) ---
etat_chequier VARCHAR2(255) ---
Tableau 34 : Table «dde_vir»
Nom de la table : dde_vir
102
Nom de la table : dde_op_cheq
Champs Types Contraintes
id_op_cheq VARCHAR2(10) PRIMARY KEY
date_oper DATE ---
user_oper VARCHAR2(5) ---
type_oper VARCHAR2(1) ---
date_valid DATE ---
user_valid DATE ---
etat_demande VARCHAR2(1) ---
date_demande DATE ---
description VARCHAR2(255) ---
Champs Types Contraintes
id_dde_vir VARCHAR2(10) PRIMARY KEY
numcpt_ben VARCHAR2(13) ---
numcpt_don VARCHAR2(13) ---
codugbct_ben VARCHAR2(3) ---
codugbct_don VARCHAR2(3) ---
codug_ben VARCHAR2(3) ---
codug_don VARCHAR2(3) ---
codbanq VARCHAR2(2) ---
codbanq VARCHAR2(2) ---
clecbt_ben VARCHAR2(13) ---
clecbt_don VARCHAR2(13) ---
mnt_vir VARCHAR2(255) ---
lib_vir VARCHAR2(255) ---
date_vir DATE ---
date_oper DATE ---
user_oper VARCHAR2(5) ---
type_oper VARCHAR2(1) ---
date_valid DATE ---
user_valid DATE ---
etat_demande VARCHAR2(1) ---
date_demande DATE ---
Tableau 35 Table «message»
Nom de la table : message
103
Champs Types Contraintes
id_envmsg VARCHAR2(10) PRIMARY KEY
nom VARCHAR2(255) ---
prenom VARCHAR2(255) ---
Tel VARCHAR2(255) ---
email VARCHAR2(255) ---
message VARCHAR2(255) ---
typdoc VARCHAR2(20) ---
numdoc VARCHAR2(15) ---
type_user VARCHAR2(1) ---
date_oper DATE ---
user_oper VARCHAR2(5) ---
type_oper VARCHAR2(1) ---
date_valid DATE ---
user_valid VARCHAR(15) ---
etat_demande VARCHAR2(1) ---
date_demande DATE ---
Tableau 36 : Table «cheque»
Nom de la table : cheque
Champs Types Contraintes
104
numchq VARCHAR2(10) PRIMARY KEY
datecheq DATE ---
etatcheq VARCHAR2(255) ---
mntcheq VARCHAR2(255) ---
nombenef VARCHAR2(255) ---
dateopp DATE ---
Tableau 37 : Table «typcarte»
Nom de la table : typcarte
Champs Types Contraintes
codtypcarte VARCHAR2(10) PRIMARY KEY
type_carte VARCHAR2(255) ---
date_oper DATE ---
user_oper VARCHAR2(5) ---
type_oper VARCHAR2(1) ---
observation VARCHAR2(255) ---
nature VARCHAR2(255) ---
plancher VARCHAR2(255) ---
bin_carte VARCHAR2(255) ---
Tableau 38 : Table «rendezvous»
Nom de la table : rendezvous
105
Champs Types Contraintes
id_dde_rendv VARCHAR2(10) PRIMARY KEY
nom VARCHAR2(255) ---
prenom VARCHAR2(255) ---
Tel VARCHAR2(255) ---
email VARCHAR2(255) ---
plage_horaire VARCHAR2(255) ---
message VARCHAR2(255) ---
typdoc VARCHAR2(20) ---
numdoc VARCHAR2(15) ---
date_rendv1 DATE ---
date_rendv2 DATE ---
type_user VARCHAR2(1) ---
date_oper DATE ---
user_oper VARCHAR2(5) ---
type_oper VARCHAR2(1) ---
date_valid DATE ---
user_valid VARCHAR2(15) ---
etat_demande VARCHAR2(1) ---
date_demande DATE ---
106
Tableau 39 : Table «carte»
Nom de la table : carte
Champs Types Contraintes
num_carte VARCHAR2(10) PRIMARY KEY
nom VARCHAR2(15) ---
prenom VARCHAR2(255) ---
typdoc VARCHAR2(20) ---
numdoc VARCHAR2(15) ---
type_carte VARCHAR2(255) ---
dateopp DATE ---
mntreatrait VARCHAR2(255) ---
mntpaie VARCHAR2(255) ---
mntdebit VARCHAR2(255) ---
etat_carte VARCHAR2(255) ---
3. Déploiement
Pour notre cas, le déploiement se traduit par un diagramme de déploiement qui permet de représenter la répartition géographique des composants matériels de notre système sous forme de nœuds.
3.1 Diagramme de déploiement de M1
L'utilisateur M-Banking demande une ressource auprès de son équipement Android. Ceci se
traduit par une requête HTTP GET ou POST qui sera envoyée à travers des web services PHP au
serveur de la base de données. La réponse finale est renvoyée au serveur de l'application mobile
sous forme d'un fichier JSON.
107
3.2 Diagramme de déploiement de M2
L'utilisateur demande une ressource auprès de son ordinateur. Ceci se traduit par une requête
HTTP qui sera envoyée au serveur de l'application. Ce dernier fournit la ressource, mais en
faisant appel à un autre serveur qui est le serveur de la base de données.
4. Conclusion
Au cours de ce chapitre, nous avons essayé de donner une meilleure visibilité du projet sur le plan technique, mettre en place le schéma de la base de données et présenter diagramme de déploiement des deux modules de l’application globale.
108
Figure 68 : Diagramme de déploiement de M1
Figure 69 : Diagramme de déploiement de M2
Conclusion et perspective
Les Smartphones sont devenus les accompagnantes indispensables de l’homme. Ceci est dû
principalement à la mise au point de multitude d’applications mobiles qui couvrent beaucoup de
secteurs, et parviennent même à satisfaire quelqu’un de nos besoins quotidiens.
C’est en considération de ce cadre qu’il nous a été confié de réaliser, au sein d'Attijari Bank, une
application de Mobile Banking sous Android qui constitue le Front office et une application Web
qui constitue, à son tour, le back office. Les études conceptuelles et techniques, ainsi que les
différentes étapes qui ont abouti à la réalisation de notre solution, ont fait l’objet des chapitres de
ce rapport.
Ce stage représente pour nous une opportunité irremplaçable, qui nous apermis de participer à un
projet d’envergure, de faire face aux contraintes réelles de l’entreprise, et de vivre les différentes
phases clés du développement et la production d’un logiciel.
Pour accomplir ce travail, nous avons adopté les méthodes agiles et plus précisément Scrum pour
la gestion de projet, UML est désormais notre langage de modélisation en utilisant le logiciel
Rational Rose. L'application mobile est développée en langage JAVA sous éclipse Luna et
l'application web enJ2eesous MyEclipse. D'autre part, nous avons développé des web services
PHP permettant de gérer la connexion avec le serveur de base de données. Afin de créer la base
de données, un système de gestion de base de données ORACLE a été exploité.
Ces choix nous ont permis de réaliser une application complète répondant aux attentes de
l’entreprise pour laquelle nous avons œuvré.
À l’issue de ce projet, nous pouvons envisager les perspectives suivantes :
Multilinguisme de l'application.
Gestion des habilitations pour les administrateurs de l'application web.
Augmenter le niveau de sécurité de l'application en utilisant le principe de Code QR .
Améliorer le design de l'application mobile.
109
Annexe APassage d’un schéma Entité/Association à un Schéma Relationnel
La déduction du schéma relationnel se base sur un ensemble de règles qui sont présentées comme
suit :
Règle 1 : Toute entité devient une table.
Règle 2 : Chaque propriété de l’entité devient un attribut de la table.
Règle 3 : L’identifiant de l’entité devient une clé primaire de la table
Règle 4 : Chaque association « un à plusieurs » est représentée par une clé étrangère dans la table
fille.
Règle 5 : Chaque association devient une relation, si les cardinalités maximales sont «n..n» Règle 6 : Chaque association «1..1» est représentée par l’intégration d’une clé étrangère dans la
table la moins récente.
Règle 7 : Chaque classe association entre deux classes est représentée par une table qui prend
pour clé primaire la concaténation des clés primaires des deux classes.
110
Neto graphie
[1]Site internet «SeanRon», DeveloppemtEtDesign,
Available:http://seanron.free.fr/?article7/la-methode-agile-scrum-et-extreme-programming
[2] MazziveBlog, Available:http://mazzive.com/blog/?p=12
[3]ABI Research, Available: https://www.abiresearch.com/press/2q-2014-smartphone-results-
forked-android-aosp-gro/
[4]UNIVERSITE VIRTUELLE DE TUNIS (uvt), rapport de PFE «Conception et réalisation
d'une application mobile M-Banking», Available : http://pf-mh.uvt.rnu.tn/803/1/Conception-
realisation-application-mobile-M-BANKING.pdf
[5]Oracle's Developper Guide,
Available:http://otndnld.oracle.co.jp/document/products/as10g/101300/B25221_03/web.1013/
b13593/undtldev010.html
[6]Site Personnel: Gradeux Vincent, de Gradeux Vincent, Available:http://gardeux-
vincent.eu/Documents/ProjetJEE/BACSWW_Hibernate_Jaxb_Spring/content/spring.html
[7] Site officiel du Spring, Cours de Spring Security Avalaible:http://projects.spring.io/spring-
security/
[8]Site: SlideShare.net, Available: http://fr.slideshare.net/cagataycivici/primetime-jsf-with-
primefaces-dec-2014
[9]Site Journal du net, Available:
http://www.journaldunet.com/encyclopedie/definition/972/34/20/tomcat.shtml
[10] Wikipedia, http://fr.wikipedia.org/wiki/Rational_Rose
[11]Wiki du Fablab Robert Houdin, Available:
http://fablab-robert-houdin.org/wiki/doku.php?id=tuto_installation_de_eclipse
[12]Site Personnel: Gradeux Vincent, de Gradeux Vincent, Available: http://gardeux-
vincent.eu/Documents/ProjetJEE/BACSWW_Hibernate_Jaxb_Spring/content/hibernate/
hibernate_3.html
[13]Wikipedia, Available: http://fr.wikipedia.org/wiki/Java_Development_Kit
111
[14]Site «Zeste de savoir», Available: https://zestedesavoir.com/tutoriels/335/creez-des-
applications-pour-android/420/les-bases-indispensables-a-toute-application/2135/installation-et-
configuration-des-outils/#3-eclipse-ladt-et-le-sdk
[15]Wikipedia, Available: http://fr.wikipedia.org/wiki/Oracle_Database
[16]Site officiel WampServer, Available : http://www.wampserver.com/
[17]Site: Futur, Available:
http://www.futura-sciences.com/magazines/high-tech/infos/dico/d/internet-java-485/
[18]Site officiel du groupe «AddiTeam», Available: http://www.additeam.com/SSII/php/
[19]Pierre Gambarotto «Technologies pour Web Services faciles : REST, JSON», Available:
https://2009.jres.org/planning_files/article/pdf/92.pdf
[20]Site: Figer.com, REST, un style d'architecture universel, , Par: Jean-Paul Figer,
Available: http://www.figer.com/publications/REST.htm#.VWCsPU9_Okq
[21]Site officiel du groupe «AddiTeam», Available: http://www.additeam.com/SSII/uml/
[22]Site MemoireOnLine, Informatique et télécommunication, Par Alain CHIKURU
MUGISHO,Available:http://www.memoireonline.com/10/12/6148/m_Conception-dune-
application-web-de-suivi-des-passagers-sur-tous-les-vols-nationaux-et-internation14.html
[23]Tarak Chaari «Atelier UML», Available :
http://www.redcad.org/members/tarak.chaari/cours/coursUML.pdf
[24]Pascla Roques, Franck Vallée «UML2 De l’action à l’analyse des besoins à la conception»
112
