UML propose un outil qui nous aide à définir et à comprendre ce à quoi doit ressembler le logiciel que l'on nous demande de développer.
Le distributeur automatique de billets est une machine dont je ne pourrais plus me passer. En effet, non seulement elle permet de retirer des espèces et de consulter son solde mais certains modèles proposent désormais de retirer des timbres ! Je vous propose donc d'en représenter les fonctionnalités à l'aide d'UML et plus particulièrement avec un diagramme de cas d'utilisation.
Quand on parle de cas d'utilisation, on s'intéresse toujours à un système particulier ; dans notre cas, le système dont nous souhaitons représenter les fonctionnalités se trouve être le distributeur automatique de billets. UML propose de délimiter le système par un rectangle et d'y indiquer son nom ; nous allons donc nous empresser de le faire.
La fonction de notre distributeur est de rendre un certain nombre de services aux personnes qui possèdent une carte bancaire ; celles-ci vont donc interagir avec lui. UML introduit la notion d'acteur pour représenter quelqu'un qui interagit avec le système. Un acteur est représenté par un bonhomme ; nous appellerons le nôtre « Porteur de carte bancaire. »
Quelles sont les fonctionnalités proposées par notre distributeur ? La première est bien entendu le retrait d'espèces. Cette fonctionnalité se caractérise par un certain nombre d'interactions entre le porteur de la carte bancaire et le distributeur — le porteur de la carte bancaire va introduire sa carte dans le distributeur qui va alors lui demander son code secret, le porteur de la carte va ensuite saisir son code, ... Dans un diagramme de cas d'utilisation, les fonctionnalités qui se traduisent par des interactions entre un ou plusieurs acteurs et le système sont appelées cas d'utilisation et sont représentées par des ellipses placées à l'intérieur du rectangle qui délimite le système.
Pour indiquer que le retrait d'espèces s'adresse au porteur de carte bancaire et que ce dernier va pour cela interagir avec le système, il suffit d'ajouter une association — qui est représentée par un trait continu — entre l'acteur et le cas d'utilisation.
Est-ce que le porteur de carte bancaire est le seul acteur à interagir avec le distributeur de billets ? En fait non : ce dernier doit communiquer un système extérieur que l'on appellera Réseau interbancaire ; il s'agit du système qui relie toutes les banques entre elles et auquel le distributeur s'adresse pour savoir notamment si la carte bancaire n'est pas une carte volée, le distributeur d'adresse aussi à lui afin de débiter le compte du porteur de carte. Parce que le réseau interbancaire est extérieur au système et qu'il interagit avec celui-ci, il faut le considérer comme un acteur. Et puisqu'on a besoin de lui pour pouvoir effectuer un retrait d'espèces, on le relie au cas d'utilisation correspondant par une association.
Bien entendu, ce n'est pas là la seule fonctionnalité proposée par le distributeur au client ; il peut aussi retirer des timbres et consulter le solde de son compte bancaire. Ces deux fonctionnalités s'adresse au porteur de carte bancaire et font intervenir le réseau interbancaire :
Mais un distributeur doit être approvisonné. Il s'agit-là d'une autre fonctionnalité qui implique des interactions. Cependant, le client n'y participe pas. Par contre le banquier si !
Considérons monsieur Dupont. Monsieur Dupont est banquier ; il a la charge d'approvisionner le distributeur comme nous l'avons indiqué dans le diagramme. Mais il peut aussi vouloir effectuer un retrait comme tout un chacun. Comment pourrions-nous l'exprimer ? Vous êtes tenté d'ajouter une association entre le banquier et le cas d'utilisation « retrait d'argent » ? Vous auriez tort ! En effet, quand monsieur Dupont veut retirer de l'argent au distributeur, il joue le rôle de porteur de carte bancaire et est donc représenté par l'acteur du même nom : un acteur est en fait un rôle vis à vis du système.
Pire, ajouter une association entre le banquier et le retrait d'espèce signifierait que lorsque un client veut retirer de l'argent au distributeur, le banquier a un rôle à jouer, ce qui n'est absolument pas le cas.
Pour finir, il faut savoir que l'on omet souvent de représenter les limites du système étudié. Nous obtenon donc le diagramme de cas d'utilisation suivant :
Un acteur est un élément extérieur au système et qui interagit avec lui. Typiquement, il s'agit d'un rôle bien particulier d'une ou de plusieurs personnes . Revenons sur ces points ; tout d'abord un acteur est un rôle : un rôle peut être tenu par plusieurs personnes et une personne peut tenir plusieurs rôles vis à vis du système — il sera donc représenté par plusieurs acteurs ; ensuite un acteur ne représente pas forcément des personnes, il peut aussi s'agir d'autres systèmes qui interagissent avec le système que nous sommes en train de décrire ; enfin, les acteurs sont extérieur au système, ie qu'on ne représentera jamais en tant qu'acteur un élément constitutif du système ou le système lui-même.
Un cas d'utilisation est une interaction typique entre un ou plusieurs acteurs et le système. Cette interaction a un but et peut se décomposer en une série d'étapes réalisées chacunes soit par un des acteurs soit par le système.
Une association entre un cas d'utilisation et un acteur indique que l'acteur participe au cas d'utilisation, ie qu'il intervient au cours de certaines étapes de ce cas d'utilisation. Si plusieurs acteurs sont associés au même cas d'utilisation, ce n'est pas parce que l'un ou l'autre peut réaliser le cas d'utilisation : c'est parce qu'ils ont tous un rôle à jouer dans le cas d'utilisation.
Bien entendu, le diagramme de cas d'utilisation ne suffit pas à décrire les interactions entre les acteurs et le système ; par contre, il met clairement en évidence quels acteurs participent à un cas d'utilisation particulier et à quels cas d'utilisation un acteur peut participer.
Comment, dans ce cas, décrire plus précisément chacun des cas d'utilisation ? De ce point de vue, UML ne dit pas grand chose si ce n'est qu'on utilise souvent du texte. Dans la suite nous allons vous proposer une façon possible de structurer vos descriptions, celle-ci étant relativement répandue.
Prenons l'exemple du retrait d'espèces. Ce cas d'utilisation pourrait être décrit de la façon suivante :
Comment est organisée cette description ? Elle rappelle tout d'abord le nom du cas d'utilisation que l'on est en train de décrire ainsi que son but global. Ensuite apparaît le scénario principal ; il est constitué d'une succession d'étapes réalisées soit par un des acteurs soit par le système. On constatera que l'on ne s'intéresse ici qu'à ce qui se passe entre les acteurs et le système, pas à ce qui se passe dans le système. On adopte résolument un point de vue extérieur au système, celui de ses utilisateurs.
Le scénario principal doit représenter ce qui se passe dans la majorité des cas — j'ai tendance à dire dans 95% des cas, — quand tout se passe sans accroc. Bien entendu, il est toujours possible qu'un problème survienne, qu'un cas particulier se présente : on en tiendra compte dans la partie concernant les alternatives. Dans l'exemple ci-dessus, nous n'en avons considéré qu'une, celle qui survient lorsque le client saisit un mauvais code secret. Il n'y a pas vraiment de règles pour la rédaction des alternatives. Il est cependant utile d'indiquer à quelle étape du scénario principal l'alternative survient et pour quelles raisons, quelles étapes en découlent et à quelle étape on rejoint le scénario principal, si jamais on le fait.
Enfin, on peut indiquer des pré-conditions — ie des conditions dans lesquelles on doit se trouver pour pouvoir réaliser un cas d'utilisation — et les post-conditions — ie des conditions dans lesquelles on se trouve lorsque l'on a réalisé un cas d'utilisation. On peut distinguer les post-conditions de succès que l'on obtient en général lorsque l'on réalise le scénario principal et les post-conditions d'échec que l'on obtient souvent lorsque l'on passe par une alternative.
Mais que l'on s'entende bien là dessus : le modèle que nous venons de vous proposer n'est pas standardisé ; vous êtes libre de supprimer certaines parties et d'en ajouter d'autres. Seul un élément est essentiel : c'est le scénario principal qui met en évidence les interactions entre les différents acteurs et le système.
Comme vous vous en doutez, les cas d'utilisation et les acteurs doivent être identifiés très tôt dans le processus, surtout en ce qui concerne les fonctionnalités majeures. En effet, c'est grâce à eux que vous obtiendrez une vision claire de ce que doit proposer l'application à développer.
Prenez garde toutefois à ne pas vous limiter aux cas d'utilisation. En effet, certaines fonctionnalités ne peuvent pas être exprimées à l'aide de cas d'utilisation (qui sont, je le rappelle des interactions typiques entre un ou plusieurs acteurs et le système). Il s'agit typiquement de la prise en compte de l'Euro. En outre, un certain nombre d'exigences, notamment les exigences techniques, ne sont pas des fonctionnalités.
Pour finir, si les cas d'utilisation sont identifiés en amont du projet, ils seront utilisé tout au long de celui-ci : ils serviront aux concepteurs pour imaginer une solution, aux équipes de test pour définir les plans de test, ...
Copyright © 2002-2012 Olivier Mangez – Tous droits réservés