[0:00]Salut, je m'appelle Stéphane et aujourd'hui, je vais vous apprendre tout ce que vous devez savoir sur les diagrammes de cas d'utilisation. Pour commencer, je vais vous donner un aperçu général et ensuite, on parlera de système, acteurs, de cas d'utilisation et relations. Pour finir, on va construire ensemble un diagramme de cas d'utilisation, et je vais partager avec vous des exemples afin de pouvoir vous expliquer tous ces concepts en profondeur. Avez-vous déjà eu une idée qui vous paraît logique, mais que vous avez du mal à expliquer à quelqu'un d'autre sans qu'il soit totalement perdu ? Peut-être s'agit-il d'une idée d'une nouvelle application mobile, et à chaque fois que vous en parlez, personne ne comprend véritablement comment l'utiliser. Le diagramme de cas d'utilisation est très utile dans ce genre de scénario et voici une description simple. Premièrement, on voit un système ou une application, on voit ensuite des personnes, organisation ou autre système avec lesquels ils interagissent. Enfin, on voit un flux montrant ce qu'effectue le système ou l'application. C'est un diagramme simplifié qui n'est typiquement pas très détaillé, mais c'est un moyen efficace de communiquer facilement des idées complexes. Mais avant de commencer ce tutoriel, parlons de comment est-ce que vous allez pouvoir créer un diagramme de cas d'utilisation. Vous pouvez le dessiner avec un stylo et du papier, mais utiliser un logiciel de diagramme serait bien plus facile. Aujourd'hui, je vais utiliser le Lucidchart et vous pouvez aussi l'utiliser car il est gratuit. Cliquez simplement sur ce lien afin d'accéder au site internet de Lucidchart. Entrez votre adresse email et vous aurez un compte Lucidchart gratuit en quelques secondes. C'est facile à utiliser et vous pouvez suivre avec moi pendant qu'on construit le diagramme de cas d'utilisation. Nous allons repartir notre diagramme en quatre éléments différents : système, acteurs, cas d'utilisation, relations. Commençons avec les systèmes. Un système est ce que vous développez. Ça peut être un site internet, le composant d'un logiciel, un processus business, une application ou autre chose. Un système est représenté par un rectangle et le nom du système est mis au-dessus. On va faire un cas d'utilisation pour une application bancaire simplifiée. On appellera notre système App Bancaire. Le rectangle définit l'étendue de notre système. Tout ce qui est à l'intérieur du rectangle se passe dans l'application bancaire. Tout ce qui est à l'extérieur du rectangle ne se déroule pas dans l'application bancaire. Le prochain élément est l'acteur qui est dépeint par le personnage bâton. Un acteur est quelqu'un ou quelque chose qui utilise le système afin d'accomplir un objectif. Ça peut être une personne, une organisation, un autre système ou un dispositif externe. Qui sera l'utilisateur de notre App Bancaire ? Un client bien évidemment. Nous allons avoir des clients qui téléchargent et utilisent notre App Bancaire. Un autre acteur qui fera partie de notre diagramme est la banque. La banque va fournir les informations qui alimentent notre application bancaire, comme les transactions et les soldes de comptes bancaires. Voici quelques éléments à garder à l'esprit dans l'utilisation des acteurs. Premièrement, il est important de noter que les acteurs sont les objets externes. Ils doivent toujours être placés en dehors de notre système. Deuxièmement, les acteurs sont comparables à des types ou catégories. Pour notre App Bancaire, un acteur ne sera pas un individu ou une organisation spécifique. Vous ne devrez surtout pas appeler aux acteurs Jean et Société Générale. Nos acteurs doivent demeurer catégoriels. Jusque là, nous avons deux acteurs qui utilisent notre application, client et banque. Cela nous amène à notre prochaine étape, qui est de différencier les acteurs primaires et secondaires. Un acteur primaire initialise l'utilisation de notre système, pendant que l'acteur secondaire réagit aux actions du système. Par exemple, quel acteur est l'acteur primaire ou secondaire ? L'acteur primaire est le client. Le client va initier l'utilisation de notre système. Il prendra son téléphone, ouvrira notre App Bancaire et fera quelque chose avec. La banque, par contre, est un acteur secondaire. La banque n'agira que si le client fait quelque chose. Si le client décide de consulter le solde de son compte, seulement à ce moment-là, la banque commence à interagir avec notre système pour fournir le solde. Les acteurs primaires doivent être à gauche du système et les acteurs secondaires à droite. Ceci est une manière d'appuyer le fait que le client initie l'App Bancaire et ensuite la banque réagit. Le prochain élément est un cas d'utilisation et c'est là qu'on commence véritablement à décrire ce que notre système fait. Un cas d'utilisation est dépeint avec une forme ovale et représente une action qui accomplit une tâche dans notre système. Ils seront placés dans notre rectangle parce qu'ils sont des actions qui se passent dans notre App Bancaire. Alors, que fera notre App Bancaire ? On va simplifier les choses. Notre App Bancaire va permettre à un client de se connecter, de vérifier son solde bancaire, de transférer des fonds entre comptes et payer des factures. De ce fait, nous aurons des cas d'utilisation qui décrivent chacune de ces actions.
[4:56]Nous aurons un cas d'utilisation qui s'appelle Connexion, un autre qui s'appelle Vérifier Solde Bancaire, un autre Transférer des Fonds et finalement Faire un paiement. Vous pouvez noter que chacun de ces cas d'utilisation commence avec un verbe et réitère qu'une action se passe. Nous voulons aussi qu'il soit suffisamment descriptif. Si le cas d'utilisation ne dit que transfert, cela serait trop vague. Finalement, en bonne pratique, les cas d'utilisation sont en ordre logique quand possible. C'est la raison pour laquelle on met connexion tout au début. C'est la première chose qui se passe quand un client utilise notre App Bancaire. L'élément final dans le diagramme de cas d'utilisation sont les relations. Un acteur par définition utilise notre système pour atteindre un objectif. Par conséquent, chaque acteur doit interagir avec au moins un cas d'utilisation de notre système. Dans notre exemple, un client va se connecter sur notre App Bancaire. On dessine alors un trait solide entre l'acteur et le cas d'utilisation qui montre cette relation. Ce type de relation est appelée une association qui signifie une communication ou une interaction de base. Un client va aussi interagir avec le reste des cas d'utilisation. Il va vérifier son solde, transférer des fonds et faire des paiements, donc on tracera aussi des traits pour chaque cas d'utilisation. Les acteurs secondaires auront aussi des relations. N'oubliez pas que chaque acteur doit interagir avec au moins un cas d'utilisation. Donc, avec quel cas la banque interagira-t-elle ? Quand un client veut vérifier son solde bancaire sur son application, la banque va fournir le montant correct. Dessinons un trait entre la banque et vérifier le solde. De cette manière, lorsque le client veut transférer des fonds ou initier un paiement, la banque va suivre ces transactions. Nous n'avons pas besoin de tracer un trait pour se connecter parce que ce processus se déroule dans l'App Bancaire. Il n'est donc pas nécessaire pour la banque de s'impliquer dans le processus de connexion. Il y a trois autres types de relations en plus de l'association : l'inclusion, l'extension et la généralisation. Construisons ce diagramme avec des cas d'utilisation additionnels afin d'expliquer ces différents types de relations. Lorsqu'un client entre ses informations de connexion, notre App Bancaire vérifie le mot de passe avant de finir le processus de connexion. Cependant, si le mot de passe est incorrect, l'App Bancaire affichera un message d'erreur. Alors, créons ensemble deux nouveaux cas d'utilisation pour vérifier un mot de passe et afficher un message d'erreur de connexion. Quand un client transfère des fonds ou fait un paiement, notre App Bancaire va s'assurer que le client a suffisamment d'argent sur son compte pour effectuer ses transactions. Alors, créons un autre cas d'utilisation appelé Vérifier les Fonds Disponibles. Finalement, lorsqu'un client veut faire un paiement, notre App Bancaire lui donnera l'option de payer avec son compte courant ou son compte d'épargne. On va créer deux cas d'utilisation de plus appelés Payer avec Compte Courant et Payer avec Compte d'Épargne. Retournons au cas d'utilisation Vérifier Mot de Passe et passons en revue les relations. Quel est le rapport entre ce cas d'utilisation et le reste du diagramme ? Aucun de ces acteurs font directement cette action. Cette action se passera immédiatement dans notre App Bancaire à chaque fois que quelqu'un essaie de se connecter. Cela définit la relation d'inclusion. Une relation d'inclusion montre la dépendance entre un cas d'utilisation de base et un cas d'utilisation inclus. À chaque fois qu'un cas d'utilisation est exécuté, le cas d'utilisation inclus est exécuté en même temps. En d'autres termes, un cas d'utilisation de base a besoin d'un cas d'utilisation inclus afin d'être complet. Lorsque vous avez une relation d'inclusion, vous tracez une ligne pointillée avec une flèche qui pointe vers le cas d'utilisation inclus. Dans notre exemple, se connecter est le cas d'utilisation de base et vérifier le mot de passe est le cas d'utilisation inclus. À chaque fois que l'utilisateur se connecte, notre App Bancaire vérifie automatiquement le mot de passe. Le cas d'utilisation de connexion ne sera pas complet à moins que le processus de vérification du mot de passe soit fait. On dessine une ligne pointillée pointant vers notre cas d'utilisation inclus et on écrit « inclus » entre guillemets. Le prochain type de relation est la relation d'extension. Une relation d'extension un cas d'utilisation de base et un cas d'utilisation d'extension. Lorsqu'un cas d'utilisation de base est exécuté, le cas d'utilisation d'extension se déroulera parfois de temps en temps. Le cas d'utilisation d'extension se passera seulement si certains critères sont remplis. En d'autres termes, c'est comme si vous avez l'option d'étendre le comportement du cas d'utilisation de base. Dans le cas d'une relation d'extension, on dessine une ligne pointillée avec une flèche qui pointe vers le cas d'utilisation de base et on écrit « extension » entre guillemets. Dans notre exemple, se connecter est un cas d'utilisation de base et montrer les erreurs de connexion est un cas d'utilisation d'extension. Notre App Bancaire ne montrera pas un message d'erreur de connexion à chaque fois que le client se connecte. Ça se passera occasionnellement quand le client tape un mot de passe incorrect. Parce qu'il s'agit de relations d'extension, on dessine une ligne pointillée avec une flèche qui pointe vers le cas d'utilisation de base et on écrit « étendre » entre guillemets. J'espère que la différence entre les relations d'inclusion et d'exclusion est claire. Juste pour clarifier, voici un exemple simple pour faire la différence entre les deux. Si vous éternuez, vous fermez vos yeux. Ça, c'est une relation d'inclusion parce que cela arrive à chaque fois que vous éternuez. De plus, si vous éternuez, vous pourriez dire excusez-moi. Ça, c'est une relation d'extension parce qu'elle s'ajoute à l'éternuement, mais n'est pas nécessaire lorsqu'on éternue. Pour résumer, une relation d'inclusion se passe à chaque fois, une relation d'extension se passe souvent. Mais n'oubliez pas que les flèches pointent dans les directions différentes. Il est aussi important de savoir que plusieurs cas d'utilisation de base peuvent pointer vers la même relation d'inclusion ou d'exclusion. Par exemple, transférer des fonds et faire un paiement pointeront vers Vérifier les Fonds Disponibles comme un cas d'utilisation inclus.
[11:11]Nous voulons que notre App Bancaire s'assure que ces deux cas d'utilisation de base soient effectués. Pas besoin de dupliquer le cas d'utilisation Vérifier les Fonds Disponibles. Le plus simple, le mieux c'est. Le dernier type de relation est la généralisation, aussi connu sous le nom d'héritage. Lorsqu'un paiement est effectué à partir de notre App Bancaire, il peut se faire soit via un compte courant ou un compte d'épargne. Dans ce scénario, faire un paiement est un cas d'utilisation général. Payer à partir d'un compte d'épargne et Payer à partir d'un compte courant sont des cas d'utilisation spécialisés. On peut utiliser les termes parent et enfant. Chaque enfant partage les aptitudes communes du parent, mais chaque enfant a quelque chose qui lui est propre. Pour montrer que c'est une généralisation, on trace ce type de flèche depuis l'enfant vers le parent. On peut avoir des généralisations avec des cas d'utilisation tout comme nous l'avons ici. On peut aussi avoir des généralisations avec des acteurs. Dans certains scénarios, vous pourriez distinguer entre un nouveau client et un client récurrent. Ces deux types de clients peuvent être enfant d'un acteur général, qui vous permettra d'avoir un certain type de comportement ou de qualité unique pour chacun de ces enfants. Le dernier type de forme qu'on va aborder est le cas d'utilisation avec des points d'extension. Dans cet exemple-ci, le nom du cas d'utilisation est au-dessus de la ligne et ensuite, il y a des points d'extension en-dessous de la ligne. Les points d'extension sont juste une version détaillée des relations d'extension. Ce cas d'utilisation nous montre qu'un client peut établir leur profil via notre App Bancaire. Ces points d'extension nous montrent que pendant que le client crée son profil, il a l'option d'explorer différents modules de l'application. Si le client est confus, il peut visiter le menu d'aide. Si le client veut des détails sur ses informations personnelles, il peut visiter la section confidentialité. Ces points d'extension dérivent des cas d'utilisation d'extension. Visiter le menu d'aide et montrer la section confidentialité. On peut même ajouter une note pour montrer sur quelle sorte de conditions ces points d'extension sont activés. Nous avons maintenant un diagramme de cas d'utilisation complet avec tous les éléments qui expliquent ce que fait notre App Bancaire. C'est un exemple de base, mais n'oubliez pas que même les systèmes les plus complexes nécessitent une visualisation simplifiée de leur fonctionnalité, comportement et relations. Gardez les autres détails pour d'autres diagrammes. Si vous aimerez voir cet exemple-ci, cliquez sur la carte. Vous pourrez voir l'exemple exact qu'on vient de créer, ainsi que d'autres exemples et ressources. Merci d'avoir regardé ce tutoriel sur UML. Inscrivez-vous à notre chaîne afin de voir plus de tutoriels. Laissez un commentaire si vous avez des idées ou des questions. Et enfin, cliquez sur le lien pour obtenir un compte gratuit Lucidchart et commencer dès aujourd'hui à créer vos propres diagrammes UML.
