Modélisation fonctionnelle étude de cas

PRINCIPES ET DÉFINITIONS DE BASE ACTEUR

Un acteur représente un rôle joué par une entité externe (utilisateur humain, dispositif matériel ou autre système) qui interagit directement avec le système étudié. Un acteur peut consulter et/ou modifier directement l’état du système, en émettant et/ou en recevant des messages susceptibles d’être porteurs de données. Comment les identifier ? Les acteurs candidats sont systématiquement : • les utilisateurs humains directs : faites donc en sorte d’identifier tous les profils possibles, sans oublier l’administrateur, l’opérateur de maintenance, etc. ; • les autres systèmes connexes qui interagissent aussi directement avec le système étudié, souvent par le biais de protocoles bidirectionnels. Comment les représenter ? La représentation graphique standard de l’acteur en UML est l’icône appelée stick man, avec le nom de l’acteur sous le dessin. On peut également figurer un acteur sous la forme rectangulaire d’une classe, avec le mot-clé <>. Une troisième représentation (intermédiaire entre les deux premières) est également possible avec certains outils, comme cela est indiqué ci-après. Une bonne recommandation consiste à faire prévaloir l’utilisation de la forme graphique du stick man pour les acteurs humains et une représentation rectangulaire pour les systèmes connectés. CAS D’UTILISATION Un cas d’utilisation (« use case ») représente un ensemble de séquences d’actions qui sont réalisées par le système et qui produisent un résultat observable intéressant pour un acteur particulier. Figure 1-1. Représentations graphiques possibles d’un acteur 015- 050 chap1.fm Page 16 Vendredi, 18. ao t 2006 11:31 11 Modélisation fonctionnelle : étude de cas CHAPITRE 1 17 Chaque cas d’utilisation spécifie un comportement attendu du système considéré comme un tout, sans imposer le mode de réalisation de ce comportement. Il permet de décrire ce que le futur système devra faire, sans spécifier comment il le fera. Comment les identifier ? L’objectif est le suivant : l’ensemble des cas d’utilisation doit décrire exhaustivement les exigences fonctionnelles du système. Chaque cas d’utilisation correspond donc à une fonction métier du système, selon le point de vue d’un de ses acteurs. Pour chaque acteur, il convient de : • rechercher les différentes intentions métier avec lesquelles il utilise le système, • déterminer dans le cahier des charges les services fonctionnels attendus du système. Nommez les cas d’utilisation par un verbe à l’infinitif suivi d’un complément, du point de vue de l’acteur (et non pas du point de vue du système). Comment les analyser ? Pour détailler la dynamique du cas d’utilisation, la procédure la plus évidente consiste à recenser de façon textuelle toutes les interactions entre les acteurs et le système. Le cas d’utilisation doit avoir un début et une fin clairement identifiés. Il faut également préciser les variantes possibles, telles que le cas nominal, les différents cas alternatifs et d’erreur, tout en essayant d’ordonner séquentiellement les descriptions, afin d’améliorer leur lisibilité. Comment les représenter ? Le diagramme de cas d’utilisation est un schéma qui montre les cas d’utilisation (ovales) reliés par des associations (lignes) à leurs acteurs (icône du « stick man », ou représentation graphique équivalente). Chaque association signifie simplement « participe à ». Un cas d’utilisation doit être relié à au moins un acteur.

ÉTUDE D’UN GUICHET AUTOMATIQUE DE BANQUE

Cette étude de cas concerne un système simplifié de Guichet Automatique de Banque (GAB). Le GAB offre les services suivants : 1. Distribution d’argent à tout Porteur de carte de crédit, via un lecteur de carte et un distributeur de billets. 2. Consultation de solde de compte, dépôt en numéraire et dépôt de chèques pour les clients porteurs d’une carte de crédit de la banque adossée au GAB. N’oubliez pas non plus que : 3. Toutes les transactions sont sécurisées. 4. Il est parfois nécessaire de recharger le distributeur, etc. À partir de ces quatre phrases, nous allons progressivement : • identifier les acteurs ; • identifier les cas d’utilisation ; • construire un diagramme de cas d’utilisation ; • décrire textuellement les cas d’utilisation ; • compléter les descriptions par des diagrammes dynamiques ; • organiser et structurer les cas d’utilisation. L’énoncé précédent est volontairement incomplet et imprécis, comme il en est dans les projets réels !! Notez également que le problème et sa solution sont basés sur l’utilisation de cartes à puce dans le contexte des systèmes bancaires français. Si le GAB que vous avez l’habitude d’utiliser ne fonctionne pas exactement comme le nôtre, ce n’est pas très important. C’est surtout un prétexte pour vous montrer comment raisonner fonctionnellement avec les cas d’utilisation UML. Étape 1 – Identification des acteurs du GAB Quelles sont les entités externes qui interagissent directement avec le GAB ? Considérons linéairement les phrases de l’énoncé. EXERCICE 1-1. Les acteurs Identifiez les acteurs du GAB.  La phrase 1 nous permet d’identifier immédiatement un premier acteur évident : tout « Porteur de carte». Il pourra uniquement utiliser le GAB pour retirer de l’argent avec sa carte. En revanche, attention : le lecteur de carte et le distributeur de billets font partie du GAB. Ils ne peuvent donc pas être considérés comme des acteurs ! Vous pouvez noter ici que l’identification des acteurs oblige à fixer précisément la frontière entre le système à l’étude et son environnement. Si nous restreignions l’étude au système de contrôle-commande des éléments physiques du GAB, le lecteur de carte et le distributeur de billets deviendraient alors des acteurs. Autre piège : la carte bancaire elle-même est-elle un acteur ? La carte est bien externe au GAB, et elle interagit avec lui… Pourtant, nous ne recommandons pas de la répertorier en tant qu’acteur, car nous appliquons le principe suivant : éliminer autant que possible les acteurs « physiques » au profit des acteurs « logiques ». L’acteur est celui qui bénéficie de l’utilisation du système. C’est bien le Porteur de carte qui retire de l’argent pour le dépenser ensuite, pas la carte ! La phrase 2 identifie des services supplémentaires qui ne sont proposés qu’aux clients de la banque porteurs d’une carte de crédit de cette dernière. Il s’agit donc d’un profil différent du précédent, que nous matérialisons par un deuxième acteur, appelé Client banque1. La phrase 3 nous incite à prendre en compte le fait que toutes les transactions sont sécurisées. Mais sécurisées par qui ? Pas par le GAB. Il existe donc d’autres entités externes qui jouent le rôle de Système d’autorisation et avec lesquelles le GAB communique directement. Une interview de l’expert métier est nécessaire, pour nous permettre d’identifier deux acteurs différents : • le Système d’autorisation global Carte Bancaire, pour les transactions de retrait ; • le Système d’information de la banque, pour autoriser toutes les transactions effectuées par un client avec sa carte de la banque, mais également pour accéder au solde des comptes. Enfin, la phrase 4 nous rappelle qu’un GAB nécessite également des actions de maintenance, telles que le rechargement en billets du distributeur, la récupération des cartes avalées, etc. Ces actions de maintenance sont effectuées par un nouvel acteur, que nous appellerons pour simplifier : Opérateur de maintenance2. 1. Il faudrait parler en toute rigueur de « Porteur de carte client de la banque », mais c’est un peu long, d’où la nécessité absolue de documenter tout élément UML, y compris les acteurs. 2. Nous pourrions par exemple identifier un acteur supplémentaire appelé « Convoyeur » ou « Gabiste », chargé spécifiquement de remplir la caisse du GAB.Plutôt que de répertorier simplement les acteurs textuellement, on peut réaliser un premier diagramme que nous appelons diagramme de contexte statique. Il suffit pour cela d’utiliser un diagramme de classes dans lequel chaque acteur est relié par une association à une classe centrale unique représentant le système, ce qui permet en outre de spécifier le nombre d’instances d’acteurs connectées au système à un moment donné. Bien que ce diagramme ne fasse pas partie des diagrammes UML « officiels », nous l’avons très souvent trouvé utile dans notre expérience des projets réels.