|
Etude pour la mise en place d'un système de paiement électronique dans une institution financière.( Télécharger le fichier original )par Patience KIMWESA Institut supérieur de commerce de Kinshasa - Licence en informatique de gestion 2011 |
Chapitre 4ème : ETUDE DE L'EXISTANT4.0. Introduction Dans le processus de conception d'un système d'information, la méthode RAD préconise l'étude du système existant. Ainsi, pour notre étude, il sera question de récolter les informations auprès des utilisateurs s'imprégner du domaine d'étude, nous chercherons à comprendre exactement le processus de circulation des informations. Cette tâche sera facilitée par l'élaboration des différents diagrammes UML, entre autre, le diagramme : ü De collaboration, ü De classes, ü De cas d'utilisations ü Et de séquences. C'est à partir de cette démarche que nous finirons par ce qui nous permettra de ressortir les points forts et les points faibles du système actuel.
· Le but27(*) de l'analyse est de traduire dans un langage proche de celui des informaticiens les modèles exprimés dans l'expression des besoins. · Cependant pour rester compréhensible par les clients ou utilisateurs, il n'intervient que des entités du domaine (métier) considéré. · Elle sert d'interface, avec l'expression des besoins, aux dialogues et aux contrats avec les clients et les utilisateurs. · L'analyse doit servir de support pour la conception, l'implémentation et la maintenance. UML regroupe différents concepts provenant de méthodes objets de référence à savoir, OOSE4, BOOCH3 et OMT2.
La complexité de concevoir un système d'information nécessite de suivre une méthode. La structure de la méthode RAD propose cinq étapes : § L'initialisation : ü Définition du périmètre général du projet, ü Structuration par thème le travail, ü Sélection des acteurs pertinents et ü Amorcer dynamique du projet ; § Le cadrage : concerne l'expression des besoins des utilisateurs, § Le design : Etape de conception ou de reconfiguration et de la modélisation du futur système; § La construction : Etape de réalisation du futur système par prototypage § La finalisation : se charge de l'officialisation de la livraison globale et le transfert du système en exploitation et en maintenance.
1ère phase : Repérage du domaine L'objet principal est la détermination de la finalité du projet, son périmètre, ainsi que les acteurs concernés; 2ème phase : Découverte des informations Permet de connaître et comprendre tous les aspects du système d'information et aussi repérer les grands concepts d'informations gérés dans le domaine; 3ème phase : Modélisation du workflow A ce niveau s'effectue l'identification des rôles des différents acteurs et leur façon de collaborer au sein du domaine. 4ème phase : Diagnostic Le diagnostic permet d'apprécier la gestion des informations et les processus; 5ème phase : Reconfiguration du système d'information C'est à ce stade que les nouveaux principes portant sur la gestion des informations ainsi que la configuration des processus sont fixés; 6ème phase : Modélisation du futur système d'information Concerne la modélisation des différents aspects du système d'information futur en s'appuyant sur les règles arrêtées lors de la phase précédente; 7ème phase : Rédaction du cahier des charges Cette phase concerne la mise en forme du cahier de charges du futur système d'information.
· Comprendre l'actuel fonctionnement du système par une description détaillée des ressources humaines et matérielles de la banque, · Répertorier les contraintes à prendre en compte en identifiant les points positifs et les points de dysfonctionnement, · Evaluer et critiquer la situation actuelle de la monétique en termes de système d'information, d'organisation et de méthodes de travail. · Eliminer les méthodes de gestion et d'organisation jugées défaillantes, · Considérer les souhaits des utilisateurs pour des propositions des solutions plus adéquates,
Sous la responsabilité du directeur, la direction de l'Informatique et de la Monétique de la banque comprend les agents suivants répartis selon leurs services : ü Un directeur; ü Une secrétaire; ü Quatre agents dans le service Système et Production; ü Trois agents dans le service Assistance aux Utilisateurs ; ü Trois agents dans le service Monétique.
Le parc informatique de la banque au niveau de la direction générale comprend : ü Plus de 250 micro-ordinateurs de bureau et des ordinateurs portables de marque, DeJI et HP, ü 1 nouveau système d'information fonctionnant sous Windows, ü 1 onduleur de 40kva, ü 2 onduleurs de 15kva, ü 2 onduleurs de 6kva, ü 4 hubs pour le réseau ü 1 serveur central contrôleur principal de domaine Windows 2003 ü 1 serveur de messagerie Microsoft Exchange, ü 1 serveur Unix Aix qui intègre le système DELTA-BANK et ü 1serveur vocal. ü Plus de 110 imprimantes de marques différentes soit HP (1200), HP (1100), HP5L, HP (1150), Canon LBP 800, Lexmark E321 et des imprimantes matricielles de marque Epson (FX, LX, LQ). Certaines imprimantes sont configurées sur machine d'utilisateur et d'autres partagées en réseau.
Le système informatique de la banque s'occupe de : ü La gestion du parc informatique, ü La gestion des logiciels installés, ü La maintenance du réseau informatique. ü L'administration de la base de données, le paramétrage, l'assistance technique aux utilisateurs et le traitement de fin de journée (Batch).
A la banque on trouve les logiciels de base et les logiciels d'application.
Dans cette catégorie nous avons d'une part des systèmes d'exploitation : ü Windows XP ü Unix, ü MS DOS : systèmes d'exploitation de microordinateurs Et d'autre part, des systèmes de gestion de base de données : ü Oracle 9i ü Informix, ü SQL Base, ü Access 2003 ü SQL Serveur, Des langages de programmation : ü Visual Basic, ü Easy PHP, ü Programmation Shell sous linux, avec les scripts.
Certains de ces logiciels ont été acquis par la Direction Informatique à travers les partenaires et d'autres ont été développée par les informaticiens de la banque. Ce sont: ü DELTA BANK, version 8 : logiciel bancaire ; ü DELTA PAIE : Gestionnaire de la paie du personnel; ü DELTA lMMO : Gestionnaire des Immobilisations ; ü DELTA SWIFT, MONEY EXPRESS, WESTERN UNION : pour le transfert d'argent, ü IMAGE CHEQUE : Gestionnaire de la Télé compensation; ü CORITEL & CORINET : Gestionnaire de la Télématique; ü D.A.B : Gestionnaire du distributeur automatique de billets; ü Une application qui gère les frais de mission ; ü Une application qui gère les courriers ; ü Une application qui gère les demandes de chéquiers ; ü Multi X pack: gestionnaire des cartes bancaires.
L'avènement de nouvelle forme d'organisation et le rôle stratégique que jouent les télécommunications dans le développement d'une entreprise, ont conduit la banque à opter pour une liaison spécialisée avec ses agences. En effet, toutes les agences de la banque utilisent le réseau VSAT28(*) et la technologie WIFI29(*) par des antennes BLR30(*)s qui relient les sites abritant les GAB31(*).
La liaison entre différentes ressources du réseau local de la banque est assurée par des câbles Ethernet. Ainsi, des prises ont été prévues dans chaque bureau pour assurer la liaison entre postes de travail du réseau local. Cette liaison passe aussi par le commutateur de palier. Un autre câble relie les commutateurs des étages à ceux de la salle informatique. La topologie du réseau ETHERNET 100 BASE-T répond à la disposition géographique des postes de travail et au nombre d'ordinateurs qui composent ce réseau.
La banque offre une gamme variée de cartes bancaires pour répondre à la satisfaction de ses clients. On y trouve par exemple : CASH ADVANCE, MALAKITE, IVOIRE, AKSANTI, permettant aux clients de la banque de retirer de l'argent 24h/24 dans les distributeurs des agences et de payer directement chez les commerçants partenaires. Les cartes internationales VISA et MASTER CARD sont aussi disponibles, permettant aux clients de la banque d'effectuer des retraits à travers le monde entier.
Le retrait d'argent peut s'effectuer à tout moment par les clients.
Le dernier solde du client peut être directement édité.
Il est possible de relever les 10 derniers mouvements effectués sur le compte. Plusieurs autres services sont disponibles par la banque.
Les clients de la banque peuvent directement grâce à une connexion internet, accéder à leur compte depuis un poste de travail et avoir toutes les informations et effectuer des opérations possibles comme s'ils étaient dans une agence de la banque : ü Consulter un compte; ü Commander un chéquier ou une carte bancaire; ü Editer un relevé de compte; ü Donner des ordres de virement ; ü Consulter le cours de change des principales devises. ü Etc.
Cette phase consiste à la prise de connaissance du projet et trouve ses fondements sur des interviews de direction avec différents membres de l'entreprise ayant une vue globalisante du domaine et pouvant fixer des grandes orientations.
Le principal objectif est la détermination des finalités du projet, ses limites ainsi que l'ensemble d'acteurs y intervenant. Cette phase est illustrée par le diagramme de flux ci-dessous.
Cette phase a été effectuée par de nombreuses rencontres que nous avons eues avec les différents intervenants (responsables de service, agents comptables, agents techniques) dans le processus d'élaboration du système de paiement électronique.
C'est grâce au diagramme de collaboration que les limites du projet sont représentées. Parce qu'il s'agit des opérations d'achat et de vente entre le client et son fournisseur, l'intervention de la banque ne pourrait avoir lieu qu'au cas où un client désire retirer son argent par chèque ou par carte bancaire ou encore lorsqu' un fournisseur dépose un chèque pour virement.
Ce diagramme facilite la mise en évidence des interactions entre objets du système et aussi entre objets et les messages qu'ils s'échangent. Lorsque le diagramme met en évidence des paquetages on parlera de diagramme de flux,
Le paquetage regroupe les éléments de modélisation du système à savoir : les classes, les associations, les objets, les cas d'utilisations etc. Et dans le cadre de notre travail, nous nous en servirons pour représenter les domaines identifiés lors de la phase 1. Formalisme de représentation d'un paquetage du diagramme de flux
Les paquetages communiquent entre eux moyennant le message. Formalisme de représentation d'un message du diagramme de flux :
Maîtriser les différentes façades du système d'information existant c'est-à-dire, comprendre les concepts importants d'informations que gère le domaine. Cette phase, c'est-à-dire la découverte des informations se fait simultanément avec le repérage du domaine et la modélisation du Workflow.
Nous avons profité des interviews faits avec les principaux acteurs du système lors de la phase précédente, à savoir le repérage du domaine pour découvrir les informations nous permettant de mieux circonscrire l'architecture du système en place.
a. Avec le Directeur de la DIM
b. Avec le Chef de service de la Monétique
c. Avec le chef de service de la Monétique
d. Chef de service assistance aux utilisateurs
a. Service de l'administration système
Une classe est un ensemble de données et de fonctions regroupées dans une même entité. Une classe est une description abstraite d'un objet. Les fonctions qui opèrent sur les données sont appelées des méthodes. Instancier une classe consiste à créer un objet sur son modèle. Entre classe et objet il y a, en quelque sorte, le même rapport qu'entre type et variable39(*).
Ce rectangle à trois compartiments est la représentation d'une classe : ü nom de la classe; ü les attributs; ü les méthodes.
Dans la notation UML, les attributs et méthodes publics sont précédés du signe plus tandis que les attributs et méthodes privés (encapsulés) sont précédés du signe moins.
Il s'agit des données caractérisant l'objet. Ce sont des variables stockant des informations sur l'état de l'objet40(*). Il est possible d'identifier une classe à partir d'un attribut. Il est typé (Integer, Real, String ...).
Les méthodes d'un objet caractérisent son comportement, c'est-à-dire l'ensemble des actions (appelées opérations) que l'objet est à même de réaliser. Ces opérations permettent de faire réagir l'objet aux sollicitations extérieures (ou d'agir sur les autres objets). De plus, les opérations sont étroitement liées aux attributs, car leurs actions peuvent dépendre des valeurs des attributs, ou bien les modifier.
La multiplicité définit le nombre d'instances de l'association pour une instance de la classe41(*). La multiplicité est définie par un nombre entier ou un intervalle de valeurs, elle est aussi la traduction d'une règle de gestion. De façon pratique, on utilise des valeurs:
L'association est la relation la plus courante et la plus riche du point de vue sémantique42(*). Une association est une relation statique n-aire (le plus souvent : elle est binaire) : c'est-à-dire qu'elle relie plusieurs classes entre elles. L'association existe entre les classes et non entre les instances : elle est introduite pour montrer une structure et non pour montrer des échanges de données.
Les attributs d'une classe dépendent fonctionnellement de l'identifiant de la classe. Parfois, un attribut dépend fonctionnellement de 2 identifiants, appartenant à 2 classes différentes. Une classe association est une association porteuse d'attribut(s).
Le principe de généralisation / spécialisation permet d'identifier parmi les objets d'une classe (générique) des sous-ensembles d'objets (des classes spécialisées) ayant des définitions spécifiques. La classe plus spécifique (appelée aussi classe fille, classe dérivée, classe spécialisée, classe descendante ...) est cohérente avec la classe plus générale (appelée aussi classe mère, classe générale ...), c'est-à-dire qu'elle contient par héritage tous les attributs, les membres, les relations de la classe générale, et peut contenir d'autres. Les relations de généralisation peuvent être découvertes de 2 manières : ü la généralisation : il s'agit de prendre des classes existantes déjà mises en évidences) et de créer de nouvelles classes qui regroupent leurs parties communes ; il faut aller du plus spécifique au plus général. ü La spécialisation : il s'agit de sélectionner des classes existantes (déjà identifiées) et d'en dériver des nouvelles classes plus spécialisées, en spécifiant simplement les différences. Ces 2 démarches, même si elles sont fondamentalement différentes, mènent au même résultat, à savoir la constitution d'une hiérarchie de classes reliées par des relations de généralisation. La relation de généralisation est très puissante car elle permet de construire simplement de nouvelles classes à partir de classes existantes. Cependant, elle est très contraignante dans le sens où elle définit une relation très forte entre les classes. Ainsi, l'évolution d'une classe de base entraîne une évolution de toutes les classes qui en dérivent. Cet effet boule de neige peut avoir des conséquences aussi bien positives (quand c'est l'effet recherché) que négatives.
Dans UML, l'agrégation n'est pas un type de relation mais une variante de l'association. Elle représente une association non symétrique dans laquelle une des extrémités joue un rôle prédominant par rapport à l'autre extrémité. L'agrégation ne peut concerner qu'un seul rôle d'une association. L'agrégation : ü se représente toujours avec un petit losange du côté de l'agrégat. ü est un type d'association qui exprime un couplage plus fort entre les classes. ü permet de modéliser des relations de type maître et esclaves. ü permet de modéliser une contrainte d'intégrité et de désigner l'agrégat comme contrainte. Formalisme :
Les Règles de Gestions (RG) retenues sont : RG1 : Un client a au moins un compte dans au moins une banque. RG2 : Un compte appartient à un et un seul client. RG3 : Un fournisseur a au moins un compte dans au moins une banque. RG4 : Une banque est en relation avec au moins une autre banque. RG5 : Un client possède au moins un chéquier. RG6 : Un chéquier contient des chèques. RG7: Un client édite un ou plusieurs chèques. RG8 : Un chèque dépend d'un compte. RG9 : Un compte appartient à une et une seule banque. RG10 : Un chèque règle au moins une facture. RG11: Un fournisseur délivre au moins une facture. RGI2 : Une facture s'applique à une livraison. RG13 : Une facture est générée par au moins une commande. RG14 : Une livraison se compose d'au moins un produit. RG15 : Une commande contient au moins un produit. RG16 : Une commande provoque au moins une livraison. RG17 : Un client peut passer plusieurs commandes. RG18 : Un fournisseur livre des produits. RG19 : Au moins une opération est faite sur un compte. RG20: Un fournisseur peut effectuer au moins une opération. RG21 : Un client peut effectuer plusieurs opérations. RG22 : Une carte bancaire peut être utilisée pour faire au moins un retrait. RG23 : Un client possède au moins une carte bancaire.
Après avoir analysé les informations recueillies lors des interviews auprès des différents acteurs du système nous avons représenté le diagramme de classe suivant :
Nous avons réalisé le diagramme de classes suivant avec Photoshop Cs4. Pour une question de lisibilité, les types des attributs n'ont pas été mentionnés dans le diagramme de classes mais dans la description des classes.
Après avoir identifié acteurs et entités, nous allons décrire les flux d'évènements et les activités des processus faisant usage des objets créées. Ce flux d'évènements est appelé « Workflow » (flux de travail). La description du workflow est utile : · pour la présentation de délai des interactions entre différents acteurs ; · pour identification des protocoles, des acteurs ou des entités ; · lorsque les fractions d'un processus ne sont pas claires ou complexes. · lorsque la conformité de la séquence d'activités est importante; · lorsqu'il y'a moins d'acteur, beaucoup d'entités utilisées et plusieurs activités à effectuer. Beaucoup de diagrammes peuvent découler de la description du workflow. Dans ce travail, nous ne nous intéresserons qu'aux diagrammes des cas d'utilisation et de séquence.
La modélisation du workflow, troisième phase a été rendue effective non seulement lors des différents entretiens et réunion avec les principaux acteurs du domaine d'étude, mais aussi partant des diagrammes obtenus dans les deux précédentes phases.
Un acteur représente une entité appartenant à l'environnement de l'application qui interagit avec l'application ou encore, il définit un ensemble harmonieux de rôles qu'un utilisateur ou une entité externe peut jouer en interagissant avec le système. Ainsi, il peut consulter et/ou modifier directement l'état du système en échangeant des messages pouvant transporter certaines données. Les principaux acteurs du système actuel sont : Le Comité de Pilotage C'est pour l'arbitrage et le contrôle des décisions à prendre que ce comité est mis en place. Ses principales missions sont : ü La définition de l'organisation et la mise en place des procédures ; ü La validation du plan d'action, des grands choix techniques et fonctionnels; ü Le contrôle du plan d'avancement des travaux. Le Groupe de Projet Le groupe de projet : ü Gère le déroulement du projet; ü Elabore les rapports sur l'activité ; ü Veille sur l'évolution du projet auprès du comité de pilotage; ü Etablit des documents en destination du comité de pilotage; ü Evalue les besoins et les solutions aux problèmes relevant de sa compétence. Le Groupe des utilisateurs Le groupe des utilisateurs a pour rôle : ü D'être consulté directement sous forme d'interview; ü De valider les procédures et les éléments de l'étude relevant de son domaine de compétence; ü De réaliser les tests et la validation des maquettes; ü d'être une ressource pour le projet.
Les cas d'utilisation décrivent sous la forme d'actions et de réactions, le comportement du système étudié du point de vue des utilisateurs. Ils définissent les limites du système et ses relations avec son environnement45(*). Plusieurs types de relations peuvent intervenir dans des cas d'utilisation : ü Relation d'inclusion (Include) La relation d'inclusion sert à enrichir un cas d'utilisation par un autre cas d'utilisation. Cet enrichissement est réalisé par une inclusion impérative, il est donc systématique. L'inclusion sert à partager une fonctionnalité commune entre plusieurs cas d'utilisation. Elle peut également être employée pour structurer un cas d'utilisation en décrivant ses sous fonctions. Dans le diagramme des cas d'utilisation, cette relation est représentée par une flèche pointillée munie du stéréotype «include». ü Relation d'extension (Extend) Comme la relation d'inclusion, la relation d'extension enrichit un cas d'utilisation par un cas d'utilisation de sous fonction. Cet enrichissement est analogue à celui de la relation d'inclusion mais il est optionnel. Comme pour l'inclusion, l'extension sert à structurer un cas d'utilisation ou à partager un cas d'utilisation de sous fonction. Dans le diagramme des cas d'utilisation, cette relation est représentée par une flèche pointillée munie du stéréotype «extend».
Dans le système existant, les Cas d'Utilisations (CU) sont : 1. CU1-Commander Produit 2. CU2- Livrer Produit 3. CU3-Faire Facture 4. CU4-Retirer CB 5. CUS- Retirer Chèque 6. CU6-Regler Espèce 7. CU7-Regler Chèque 8. CU8- Faire Virement
Un cas d'utilisation contient potentiellement plusieurs scénarios45(*) ü Un scénario correspond à l'exécution d'un ou plusieurs enchaînements joignant le début du cas d'utilisation à une fin normale ou non. ü Les enchaînements parcourus lors d'un scénario sont sélectionnés par : ? Les messages envoyés par les acteurs ? L'état et les actions du système. Un scénario est une instance d'un cas d'utilisation. Dans la description des cas d'utilisation on distinguera trois (3) types de scénario: ü Le scénario nominal qui montre un déroulement normal; ü Le scénario alternatif qui est une variante du scénario nominal; ü Le scénario d'exception qui illustre un déroulement anormal du cas d'utilisation. Cas d'utilisation 1 : CommanderProduit
Cas d'utilisation 2 : LivrerProduit
Cas d'utilisation 3 : FaireFacture
Cas d'utilisation 4 : RetirerCB
Cas d'utilisation 5 : RetirerChèque
Cas d'utilisation 6 : ReglerEspèce
Cas d'utilisation 7 : ReglerChèque
Cas d'utilisation 8 : FaireVirement
Suite aux descriptions textuelles, le scénario peut être représenté en utilisant un diagramme de séquences46(*) qui permet : ü de visualiser l'aspect temporel des interactions ü de connaître le sens des interactions (acteur vers système ou contraire). Ainsi, les diagrammes de séquences suivants illustrent chacun le scénario nominal des différents cas d'utilisation du système existant. Diagramme de séquence 1 : CU CommanderProduit
Diagramme de séquence 2 : CU LivrerProduit
Diagramme de séquence 3 : CU LivrerProduit
Diagramme de séquence 4 : CU RetirerCB
Diagramme de séquence 5 : CU RetirerChèque
Diagramme de séquence 6 : CU ReglerEspèce
Diagramme de séquence 7 : CU ReglerChèque
Diagramme de séquence 8 : CU faireVirement
L'objectif de la phase de diagnostic est de porter un jugement sur le système existant. Elle nous permettra donc, grâce à l'analyse faite dans les phases précédentes de déceler les forces et faiblesses du système actuel.
Comme nous avons eu à faire un bilan des informations et des flux échangés (workflow) au cours des phases 2 (découverte des informations) et 3 (modélisation du workt1ow), il nous restera d'en faire une synthèse afin de pouvoir proposer des solutions.
La Direction de l'informatique et de la monétique permet à la banque d'offrir à sa clientèle une diversité de produit et de service. Comme produit et service nous pouvons citer : ü Les cartes bancaires : Elles permettent au client d'effectuer des retraits sur les GAB (Guichets Automatiques de Billet). ü Les chéquiers ; Grâce au chèque, les clients peuvent faire des achats dans certains points de vente et des retraits d'espèce au niveau des guichets ou tout autre banque du Groupement Inter bancaire Monétique. ü Les GAB existent dans différents endroits dans la capitale et dans quelques succursales à travers le pays, fonctionnant à tout moment. Au niveau du GAB, le client peut effectuer des retraits d'espèces, obtenir un reçu et consulter son solde. ü Le e-banking : C'est un processus par lequel le client peut gérer ses transactions bancaires électroniquement à partir d'un poste connecté à Internet, sans qu'il ne soit obligé de se rendre dans une succursale physique. Grâce à ce service, le client peut consulter son solde, donner des ordres de virements, commander une carte bancaire ou un chéquier, bloquer une carte bancaire ou un chéquier, consulter le cours de change des principales devises, imprimer un Relevé D'identité Bancaire (RIB). ü Le serveur vocal (Coritel) ; C'est un processus par lequel le client peut gérer à partir d'un poste téléphonique ses transactions bancaires. A partir de ce service le client de la banque peut consulter son solde, le cours de change des principales devises et ouvrir un compte. Tous ces produits et services permettent au client de rentrer en possession de son argent dans les meilleurs délais, d'effectuer des achats et d'avoir l'état de son compte à tout moment. Cependant il existe des points de faiblesses. En effet avec l'évolution fulgurante des Nouvelles Technologies d'Information et de communication (NTIC) (de plus en plus de boutique en ligne), l'accroissement des utilisateurs d'institution bancaire, les désagréments liés à l'aspect manuel des chèques et l'indisponibilité des GAB à certains moment, le domaine de prestation devient peu performant.
Le rôle que joue chaque produit et service est d'une grande importance pour la Banque, mais dans l'objectif d'être encore plus proche du client, nous pensons que cela n'est pas suffisant. En effet certains problèmes dans le fonctionnement peuvent être relevés: ü la non-conformité des chèques; ü le retard dans le règlement des chèques; ü le manque de confidentialité; ü le non aboutissement d'un virement dû à l'insuffisance d'argent constaté dans le compte source; ü l'indisponibilité des GAB dû à une panne : § mécanique: lecteur de cartes défectueux, clavier brisé et disque dur corrompu; § logiciel: système d'exploitation en faute et pilote de périphérique dépassé; § communication: réseau en panne de façon intermittente; § humaine: mauvaise saisie. ü l'engorgement des guichets et les longues files d'attente due à la lenteur des traitements.
L'étude de l'existant nous a permis de comprendre le fonctionnement du système actuel. En effet elle nous a permis de souligner les points forts, les points faibles et les disfonctionnements du système dans sa globalité. Ces éléments constitueront non seulement la base des propositions du système futur pour pallier aux difficultés et insuffisances actuelles, mais aussi nous permettront d'avoir une vision plus approfondie de l'architecture du système à mettre en place. * 27 Robert Ogor : « Modélisation avec UML » page39 * 28 VSAT : Very Small Aperture Terminal * 29 WIFI : Wireless Fidelity * 30 BLR : Boucle Locale Radio * 31 GAB : Guichet Automatiques de Billets * 32 DIM : Direction de l'Informatique et de la Monétique * 33 SM : Service Monétique * 34 GAB : Guichet Automatique de Billet * 35 GIM : Groupement Interbancaire Monétique * 36 CTMI : Centre de Traitement Monétique Interbancaire * 37 SM : Service Monétique * 38 GAB : Guichet Automatique de Billet * 39 Jean Michel DOUDOUX : « Développons en Java 9.0 », page42 * 40 Laurent AUDIBERT : « UML2 » * 41 J.STEFFE - ENITA de Bordeaux : « COURS UML13.doc », Mars 2005, page 34 * 42 Idem, p34 * 43 Idem, p37 * 44 L.DEBRAUWER & F.V. DER HEYDE : « UML 2, Initiation, exemples et exercices corrigés » 2ème éd. Page 29 * 45 A. AIT ADDI, « Analyse et conception orientées objets », Cours UML 2009-2010, page 58. * 46 R.Ogor « Modélisation avec UML », mai-2006 ; p26 |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
