DÉVELOPPEMENT D`APPLICATIONS

Développement d'applicaWons décisionnelles – A. Guille 1
DÉVELOPPEMENT D’APPLICATIONS DÉCISIONNELLES Génie Logiciel DUT STID – 2ème année – Semestre 3 (2015) IUT Lumière Lyon 2 Adrien Guille adrien.guille@univ-­‐lyon2.fr hRp://mediamining.univ-­‐lyon2.fr/people/guille Développement d'applicaWons décisionnelles – A. Guille InformaWons générales •  OrganisaWon du module •  2 cours magistraux •  10 séances de TD/TP + 1 séance de révisions •  ÉvaluaWon •  Dossier à réaliser en groupe et à rendre en décembre 2015 •  Examen sur table en janvier 2016 •  Supports en ligne •  DiaposiWves des cours •  Sujets et correcWons des TD •  Références •  UML 2 – De l’apprenWssage à la praWque (2009) L. Audibert •  UML 2 – PraWque de la modélisaWon (2010) B. Charroux et al. 2
Développement d'applicaWons décisionnelles – A. Guille 3
ProblémaWque •  Les projets informaWques sont souvent des échecs •  Depuis les années 60 •  « Crise du logiciel » (conférence organisée par l’OTAN en 1968) •  Aujourd’hui encore (enquête conduite par Standish Group) •  Environ 16% (seulement) des applicaWons développées sont conformes aux aRentes des clients •  Environ 30% des applicaWons sont abandonnées en cours de développement •  Beaucoup d’applicaWons décisionnelles ne sont jamais uWlisées car elles ne correspondent pas aux besoins des clients •  Les clients ne savent pas ce qu’ils veulent •  Les clients ne savent pas exprimer ce qu’ils veulent •  Les développeur ne comprennent pas les clients •  Les clients ne comprennent pas les développeurs, etc. Développement d'applicaWons décisionnelles – A. Guille ProblémaWque •  Difficultés de communicaWons 4
Développement d'applicaWons décisionnelles – A. Guille 5
Génie logiciel •  Domaine de recherche né à la fin des année 60 à la NASA au cours du programme Apollo •  L’objecWf du génie logiciel est de raWonaliser le développement •  Structure du développement •  Phases •  Cycle •  Techniques facilitant le développement •  Techniques de modélisaWon •  Techniques de spécificaWon •  Techniques de test •  Techniques de gesWon de projet, etc. Développement d'applicaWons décisionnelles – A. Guille 6
Phases du développement d’une applicaWon •  Principales phases •  ModélisaWon des besoins •  Expression des besoins •  Analyse des besoins •  RédacWon du cahier des charges •  ConcepWon de l’applicaWon •  ÉlaboraWon des spécificaWons •  RéalisaWon de l’applicaWon •  Mise en œuvre d’un ouWl décisionnel / développement spécifique •  ValidaWon de l’applicaWon •  Conduite des tests d’intégraWon •  ReceRe uWlisateur •  Conduite des tests de conformité par le client Développement d'applicaWons décisionnelles – A. Guille 7
Cycle de développement linéaire •  Le cycle de développement en V •  Analyse des besoins, concepWon puis réalisaWon de l’applicaWon, tests de validaWon et receRe uWlisateur sont effectués en « cascade » ModélisaWon des besoins ConcepWon de l’applicaWon RéalisaWon de l’applicaWon ReceRe uWlisateur Tests d’intégraWon Développement d'applicaWons décisionnelles – A. Guille 8
Cycle de développement itéraWf •  Le cycle de développement itéraWf incrémental •  Après l’analyse des besoins, les foncWons sont réparWes en lots •  ConcepWon, réalisaWon, tests de validaWon et receRe uWlisateur sont effectués par lot ModélisaWon des besoins ReceRe uWlisateur ConcepWon d’une parWe de l’applicaWon Tests d’intégraWon RéalisaWon d’une parWe de l’applicaWon Développement d'applicaWons décisionnelles – A. Guille 9
ModélisaWon des besoins •  La modélisaWon des besoins est une étape cruciale •  Base de tout cycle de développement •  L’étude des causes de succès et d’échecs lors des projets décisionnels révèle que la plupart des échecs proviennent d’une mauvaise compréhension des besoins •  La modélisaWon des besoins se décompose en deux étapes •  Expression des besoins •  Plus ou moins informelle •  Analyse des besoins •  Technique semi-­‐formelle Développement d'applicaWons décisionnelles – A. Guille 10
ModélisaWon des besoins •  1ère étape : expression des besoins •  Appel à projet rédigé par la maîtrise d’ouvrage (i.e. MOA, le client) •  Rédigé en langage naturel •  MoWvant l’acquisiWon ou l’amélioraWon d’une applicaWon décisionnelle par le client (en terme d’usage et de bénéfices) •  PotenWellement problémaWque pour la maitrise d’œuvre (i.e. MOE, le développeur) •  Clarté : e.g. mauvaise descripWon du/des problème(s) à résoudre, langage naturel imprécis, besoins implicites •  Faisabilité : e.g. demandes surréalistes par rapport à l’état de l’art, au planning
•  Technicité : e.g. les foncWons aRendues sont décrites, mais pas les contraintes techniques •  EntreWens avec la MOA •  Interviews avec des uWlisateurs représentaWfs Détail :
PHASE I
Développement d'applicaWons décisionnelles – A. Guille 11
I - Expression des besoins
ModélisaWon des besoins COLLECTE BESOINS
MOA
Présentation du projet global BI : quels usages ? quels bénéfices potentiels ?
Situation de l’interlocuteur dans l’organisation.
Expression des besoins.
•  Grille de quesWons proposée par Béatrice Castetbon (UPPA) Objectif de l’interview : amener les utilisateurs à parler de ce qu’ils font et des
•  Amener les ulesquelles
Wlisateurs ils
à plearler raisons pour
font.de ce qu’ils font et des raisons pour lesquelles ils le font Grille
de questions à poser lors de l’interview :
Q1
Q2
Q3
Q4
Q5
Q6
:
:
:
:
:
:
Quelles sont les responsabilités de l’utilisateur ?
Quelle est sa place dans l’organisation ?
Quelles sont ses principales mesures de performance ?
De quelle façon détermine-t-il les progrès et la réussite ?
Quels sont leurs principaux processus ? les principales procédures ?
Pour chacun des principaux processus évoqués :
Q6.1 : pourquoi les utilisateurs veulent en analyser les résultats ?
Q6.2 : quelles sont les possibilités dont ils souhaitent disposer ?
Q6.3 : quelles sont les insuffisances actuelles ?
Q6.4 : quels sont les avantages et les incidences potentiels des
solutions envisagées ?
Q7 : Exemple de questions auxquelles il pourrait être répondu lorsque
l’entrepôt de données sera déployé. Quels sont les indicateurs à mettre
en place ?
Si la personne a une plus grande expérience de la manipulation des
données :
Q8 : Comment fait-elle la distinction entre les différents produits (agents,
prestataires, ressources ?)
Q9 : Comment classe-t-il naturellement les produits ?
! Comprendre les dimensions de l’activité ainsi que les regroupements
hiérarchiques.
Si la personne interviewée est plus analytique :
Q6.1
Q6.2
Q6.3
Q6.4
:
:
:
:
pourquoi les utilisateurs veulent en analyser les résultats ?
quelles sont les possibilités
ils souhaitent
disposer
Développement ddont
'applicaWons décisionnelles – A. Guille ? 12
quelles sont les insuffisances actuelles ?
quels sont les avantages et les incidences potentiels des
solutions envisagées ?
Q7 : Exemple de questions auxquelles il pourrait être répondu lorsque
l’entrepôt de données sera déployé. Quels sont les indicateurs à mettre
en place ?
Si la personne a une plus grande expérience de la manipulation des
données :
Q8 : Comment fait-elle la distinction entre les différents produits (agents,
prestataires, ressources ?)
Amener l
es uWlisateurs à parler de ce qu’ils font et des raisons pour lesquelles ils Q9 : Comment
classe-t-il
naturellement
les produits
?
le font ! Comprendre les dimensions de l’activité ainsi que les regroupements
hiérarchiques.
Si la personne interviewée est plus analytique :
Q10 : Quels types d’analyse elle effectue actuellement ? Analyse
standard / ad hoc
Q11 : Récupérer les copies des états ou des feuilles excel.
Q12 : Comment utilise-t-elle aujourd’hui ces analyses ?
Q13 : Quelles sont les possibilités d’amélioration ?
Si la personne est un responsable de haut niveau :
Q14 : Quelle est sa vision d’une meilleure exploitation des informations
de l’établissement ?
Q15 : Quelle est l’incidence d’un meilleur accès aux informations ? Quels sont
les avantages potentiels quantifiables ?
Q16 : Quels sont ses critères de réussite pour ce projet ? critères mesurables.
Q17 : Quel est le référent métier ?
ModélisaWon des besoins •  Grille de quesWons proposée par Béatrice Castetbon (UPPA) • 
• 
Cet interview ne garantit pas que l’ensemble des fonctions sera inclus dans la
première phase
dugprojet.
Néanmoins ceRe rille de quesWons ne garanWt pas l’idenWficaWon de toutes les foncWons que doit saWsfaire l’applicaWon décisionnelle BCASTETBON/BI/METHODOLOGIE
Page 2 / 7
01/12/2008
Développement d'applicaWons décisionnelles – A. Guille 13
ModélisaWon des besoins •  2ème étape : analyse des besoins •  MOA et MOE travaillent conjointement pour formaliser les besoins •  RédacWon du cahier des charges foncWonnel •  Langage naturel •  Diagrammes – UML (Unified Modeling Language)
Besoins DescripWon des problèmes à résoudre FoncWons DéfiniWon des foncWons (i.e. services) à assurer Périmètre du cahier des charges
ApplicaWon SoluWons apportées par l’applicaWon Développement d'applicaWons décisionnelles – A. Guille 14
ModélisaWon des besoins •  2ème étape : analyse des besoins •  MOA et MOE travaillent conjointement pour formaliser les besoins •  RédacWon du cahier des charges foncWonnel •  Langage naturel •  Diagrammes – UML (Unified Modeling Language)
Besoins FoncWons ApplicaWon Le cahier des charges fonc@onnel est un document essen@el du projet décisionnel
DescripWon des DéfiniWon des SoluWons •  Contrat entre MOA et MOE
à foncWons (i.e. apportées par • problèmes Référence pour l’élabora@on des spécifica@ons puis la résoudre services) à assurer l’applicaWon concep@on de l’applica@on décisionnelle
•  Base pour les tests d’intégra@on et la receNe u@lisateur
Périmètre du cahier des charges
Développement d'applicaWons décisionnelles – A. Guille ModélisaWon des besoins avec UML •  Unified Modeling Language •  Langage de modélisaWon unifié •  NotaWon dont l’interprétaWon est définie par un standard
•  Massivement uWlisé en entreprise •  Besoin d’un langage de modélisaWon unifié dès les années 80 •  PrésentaWon de l’UML en 1995 •  PrésentaWon de l’UML 1 en 1997 •  PrésentaWon de l’UML 2 en 2004 15
Développement d'applicaWons décisionnelles – A. Guille 16
ModélisaWon des besoins avec UML •  UML 2 proposent plusieurs diagrammes Diagramme Diagramme de structure Diagramme de classe Diagramme de déploiement Diagramme de comportement Diagramme de cas d’uWlisaWon Diagramme d’acWvité Taxonomie parWelle des diagrammes proposés par UML 2 Diagramme de séquence Développement d'applicaWons décisionnelles – A. Guille 17
ModélisaWon des besoins avec UML •  UML 2 proposent plusieurs diagrammes •  D’une part des diagrammes staWques •  D’autre part des diagrammes dynamiques Diagramme Diagramme de structure Diagramme de classe Diagramme de déploiement Diagramme de comportement Diagramme de cas d’uWlisaWon Diagramme d’acWvité Taxonomie parWelle des diagrammes proposés par UML 2 Diagramme de séquence Développement d'applicaWons décisionnelles – A. Guille 18
ModélisaWon des besoins avec UML •  UML permet de construire des modèles pour les différents aspects d’une applicaWon •  L’applicaWon du point de vue de l’uWlisateur •  La structure interne de l’applicaWon •  La manière dont l’applicaWon se déploie, etc.
•  Les modèles se complètent et peuvent être assemblés •  Pour réaliser aisément ces diagrammes il existe des logiciel appelés « ateliers de génie logiciel » •  e.g. le logiciel gratuit dans sa version « community » Visuel Paradigm (Design & Management Tool for Business IT Development) •  Pour modéliser les besoins que doit saWsfaire l’applicaWon décisionnelle on uWlise les diagrammes de cas d’uWlisaWon
Développement d'applicaWons décisionnelles – A. Guille 19
ModélisaWon des besoins avec UML •  Le diagramme de cas d’uWlisaWon •  FormalisaWon graphique des besoins compréhensible par MOA et MOE •  ReprésentaWon foncWonnelle des interacWons entre des uWlisateurs et l’applicaWon •  Exemple de diagramme Développement d'applicaWons décisionnelles – A. Guille 20
ModélisaWon des besoins avec UML •  Éléments d’un diagramme de cas d’uWlisaWon •  Acteurs, cas d’uWlisaWon et système modélisé •  RelaWons entre acteurs, entre cas d’uWlisaWons, entre acteurs et cas d’uWlisaWon •  L’acteur •  IdéalisaWon d’un rôle joué par une personne, un processus ou un système externe qui interagit avec l’applicaWon •  Représenté par un personnage avec son nom inscrit en-­‐dessous ou un rectangle portant le stéréotype << Actor >> Développement d'applicaWons décisionnelles – A. Guille 21
ModélisaWon des besoins avec UML •  Éléments d’un diagramme de cas d’uWlisaWon •  Acteurs, cas d’uWlisaWon et système modélisé •  RelaWons entre acteurs, entre cas d’uWlisaWons, entre acteurs et cas d’uWlisaWon •  L’acteur •  Une même personne peut jouer plusieurs rôles •  Plusieurs personnes peuvent jouer un même rôle •  Permet de définir des droits d’accès, différents points de vue de l’applicaWon, etc. Développement d'applicaWons décisionnelles – A. Guille 22
ModélisaWon des besoins avec UML •  Éléments d’un diagramme de cas d’uWlisaWon •  Acteurs, cas d’uWlisaWon et système modélisé •  RelaWons entre acteurs, entre cas d’uWlisaWons, entre acteurs et cas d’uWlisaWon •  Le cas d’uWlisaWon •  Unité cohérente représentant une foncWonnalité visible de l’extérieur •  Réalise un service pour l’acteur qui l’iniWe •  Représenté par une ellipse contenant le nom du cas d’uWlisaWon (une verbe à l’infiniWf) •  RelaWon d’associaWon avec un acteur Développement d'applicaWons décisionnelles – A. Guille 23
ModélisaWon des besoins avec UML •  Éléments d’un diagramme de cas d’uWlisaWon •  Acteurs, cas d’uWlisaWon et système modélisé •  RelaWons entre acteurs, entre cas d’uWlisaWons, entre acteurs et cas d’uWlisaWon •  ReprésentaWon d’un diagramme d’uWlisaWon •  La fronWère du système modélisé est définie par un cadre contenant les cas d’uWlisaWon, les acteurs étant à l’extérieur AssociaWon Acteur Nom du système Cas d’uWlisaWon FronWère du système Développement d'applicaWons décisionnelles – A. Guille 24
ModélisaWon des besoins avec UML •  Le diagramme de cas d’uWlisaWon •  RelaWon d’inclusion entre cas d’uWlisaWon •  Un cas d’uWlisaWon A inclut un cas d’uWlisaWon B si le comportement décrit par le cas A inclut le comportement du cas B
•  On représente ceRe relaWon par une flèche dirigée du cas A vers le cas B portant le stéréotype <<Include>> Développement d'applicaWons décisionnelles – A. Guille 25
ModélisaWon des besoins avec UML •  Le diagramme de cas d’uWlisaWon •  Acteur principal et secondaire •  Un acteur est principal par rapport à un cas d’uWlisaWon lui rend service •  Sinon c’est un acteur secondaire, e.g. sollicité pour des informaWons complémentaires •  Ajout des stéréotypes <<Primary>> et <<Secondary>> aux associaWons •  Par convenWon on représente les acteurs humains par des personnages et les autres types d’acteurs par des rectangles stéréotypés Développement d'applicaWons décisionnelles – A. Guille 26
ModélisaWon des besoins avec UML •  Le diagramme de cas d’uWlisaWon •  RelaWon d’extension entre cas d’uWlisaWon •  Un cas d’uWlisaWon A étend un cas d’uWlisaWon B si le cas A peut potenWellement intervenir au cours du cas B
•  RelaWon représentée par une flèche dirigée du cas A vers le cas B et associée au stéréotype <<Extend>> Développement d'applicaWons décisionnelles – A. Guille 27
ModélisaWon des besoins avec UML •  Le diagramme de cas d’uWlisaWon •  RelaWon d’extension entre cas d’uWlisaWon •  Le point d’extension permet de préciser à quel moment une extension peut intervenir •  La condiWon d’extension, décrite dans une note portant sur la relaWon, précise dans quel cas l’extension intervient Développement d'applicaWons décisionnelles – A. Guille 28
ModélisaWon des besoins avec UML •  Le diagramme de cas d’uWlisaWon •  RelaWon de généralisaWon entre acteurs •  Un acteur A est une généralisaWon de B si l’acteur A peut être subsWtué par B
•  L’acteur B hérite des associaWons de l’acteur A
•  RelaWon représentée par une flèche pleine de B vers A Développement d'applicaWons décisionnelles – A. Guille 29
ModélisaWon des besoins avec UML •  Le diagramme de cas d’uWlisaWon •  RelaWon de généralisaWon entre cas d’uWlisaWon •  Un cas d’uWlisaWon A est une généralisaWon du cas B si B est un cas parWculier de A
•  UWle pour découper un cas d’uWlisaWon complexe en sous-­‐cas plus simples •  RelaWon représentée par une flèche pleine de B vers A Développement d'applicaWons décisionnelles – A. Guille 30
ModélisaWon des besoins avec UML •  DescripWon textuelle d’un diagramme de cas d’uWlisaWon •  Donne des détails à propos des cas d’uWlisaWon illustrés par un diagramme •  Comporte généralement 3 parWes •  1ère parWe : idenWficaWon •  Nom du cas : tournure à l’infiniWf •  Résumé de son objec@f : descripWon de l’intenWon principale du cas d’uWlisaWon
•  Acteurs principaux : acteurs qui réalisent le cas d’uWlisaWon
•  Acteurs secondaires : acteurs recevant ou transmeRant de l’informaWon •  2ème parWe : foncWonnement •  Pré-­‐condi@ons : état dans lequel est l’applicaWon avant le cas d’uWlisaWon
•  Scénarios : descripWon sous la forme d’échanges d’évènements entre acteurs et applicaWon •  Scénario nominal, scénario(s) alternaWf(s) et scénario(s) d’excepWons •  Post-­‐condi@ons : état de l’applicaWon à l’issue des différents scénarios
Développement d'applicaWons décisionnelles – A. Guille 31
ModélisaWon des besoins avec UML •  DescripWon textuelle d’un diagramme de cas d’uWlisaWon •  Donne des détails à propos des cas d’uWlisaWon illustrés par un diagramme •  Comporte généralement 3 parWes •  3ème parWe : contraintes non foncWonnelles •  Fiabilité
•  Performance •  Accessibilité
•  etc.
•  CeRe troisième parWe de la descripWon textuelle du diagramme de cas d’uWlisaWon sert en parWculier lors des tests d’intégraWon et de la receRe uWlisateur Développement d'applicaWons décisionnelles – A. Guille 32
ModélisaWon des besoins avec UML •  DescripWon textuelle d’un diagramme de cas d’uWlisaWon •  IdenWficaWon •  Nom : ReWrer de l’argent •  ObjecWf : Accompagne le porteur d’une carte bancaire à travers les étapes du retrait d’argent •  Acteur principal : Porteur de carte bancaire •  Acteur secondaire : Système central d’authenWficaWon Développement d'applicaWons décisionnelles – A. Guille 33
ModélisaWon des besoins avec UML •  DescripWon textuelle d’un diagramme de cas d’uWlisaWon •  FoncWonnement •  Le cas d’uWlisaWon débute lorsque le porteur de carte bancaire insère sa carte •  Pré-­‐condiWon : la borne est approvisionnée en billets •  Scénario nominal : 1.  La borne demande la saisie du code PIN 2.  L’uWlisateur saisi son code PIN 3.  La borne confirme le code auprès du système central d’authenWficaWon 4.  La borne demande le montant désiré 5.  L’uWlisateur saisi le montant 6.  La borne confirme le retrait 7.  La borne rend la carte bancaire à l’uWlisateur 8.  L’uWlisateur récupère sa carte bancaire 9.  La borne délivre les billets Développement d'applicaWons décisionnelles – A. Guille 34
ModélisaWon des besoins avec UML •  DescripWon textuelle d’un diagramme de cas d’uWlisaWon •  FoncWonnement •  Scénario alternaWf : •  Au point 3 du scénario nominal : le code saisi est erroné 1. 
2. 
La borne demande à nouveau la saisie du code PIN Le scénario nominal reprend à parWr du point 3 •  Scénario d’excepWon : •  Au point 3 du scénario nominal : le code saisi est erroné pour la 3ème fois 1. 
La borne avale la carte bancaire et met fin au cas d’uWlisaWon •  Au point 8 du scénario nominal : l’uWlisateur ne reWre pas sa carte après 1 minute 1. 
La borne avale la carte bancaire et met fin au cas d’uWlisaWon •  Contraintes non foncWonnelles : •  Fiabilité •  CommunicaWon encryptée avec le système d’authenWficaWon •  Performance •  À l’étape 9 du scénario nominal, les billets doivent être délivrés en moins de 5 secondes Développement d'applicaWons décisionnelles – A. Guille 35
ModélisaWon des besoins avec UML •  Mise en œuvre •  IdenWfier les acteurs •  S’interroger sur les différents rôles que vont jouer les uWlisateurs (e.g. commercial, directeur commercial, directeur de producWon, administrateur des stocks) •  S’intéresser aux autres systèmes qui vont interagir avec l’applicaWon •  Périphériques (e.g. imprimante) •  Des soluWons décisionnelles déjà disponibles à intégrer dans le projet •  Des systèmes informaWques externes (e.g. système de mailing) •  Imaginer les fronWères de l’applicaWon décisionnelle •  Tout ce qui est à l’extérieur et interagit avec l’applicaWon est un acteur •  Tout ce qui est à l’intérieur est une foncWonnalité à modéliser •  S’assurer que les acteurs répertoriés communiquent bien directement avec l’applicaWon Développement d'applicaWons décisionnelles – A. Guille 36
ModélisaWon des besoins avec UML •  Mise en œuvre •  Recenser les cas d’uWlisaWon •  Déterminer l’ensemble des cas d’uWlisaWon couvrant de manière exhausWve les exigences foncWonnelles de l’applicaWon décisionnelle •  Éviter la redondance entre cas d’uWlisaWon •  Trouver le bon niveau d’abstracWon pour aReindre un niveau de détails adéquat •  S’assurer que chaque cas d’uWlisaWon décrit une foncWonnalité du point de vue d’un acteur et non pas de l’applicaWon •  Conclusion •  Le diagramme de cas d’uWlisaWon est un premier modèle de l’applicaWon •  Intégré au cahier des charges il permet de lever les ambiguïtés et visionner facilement les besoins •  Donne une vision foncWonnelle externe de l’applicaWon •  Boîte noire qui décrit ce fait l’applicaWon, mais qui ne décrit pas comment Développement d'applicaWons décisionnelles – A. Guille ModélisaWon des besoins avec UML •  Erreurs typiques •  Le diagramme ci-­‐dessous comporte deux erreurs 37
Développement d'applicaWons décisionnelles – A. Guille 38
ModélisaWon des besoins avec UML •  Erreurs typiques •  Le diagramme ci-­‐dessous comporte deux erreurs •  1ère erreur : il introduit un séquencement temporel entre des cas d’uWlisaWon •  2ème erreur : il lie des cas d’uWlisaWon par un trait plein, qui représente normalement une associaWon qui ne peut relier qu’un acteur à un cas d’uWlisaWon Développement d'applicaWons décisionnelles – A. Guille 39
ModélisaWon des besoins avec UML •  Erreurs typiques •  Le diagramme de droite comporte une erreur Les cas d’uWlisaWon pour le porteur de carte bancaire et le cyber-­‐client ne sont pas cloisonnés. La relaWon de généralisaWon entre « consulter ses comptes sur une borne » et « consulter ses comptes sur internet » implique que tout porteur de carte peut consulter ses comptes via le portail internet de la banque Développement d'applicaWons décisionnelles – A. Guille 40
ModélisaWon des besoins avec UML •  Erreurs typiques •  Le diagramme de droite comporte une erreur •  Les cas d’uWlisaWon pour le porteur de carte bancaire et le cyber-­‐client ne sont pas cloisonnés. La relaWon de généralisaWon entre « consulter ses comptes sur une borne » et « consulter ses comptes sur internet » implique que tout porteur de carte peut consulter ses comptes via le portail internet de la banque