Editions ENI Livres | Vidéos | e-Formations
Description fonctionnelle du système
L’état des lieux
La description dynamique montre le fonctionnement du système lorsque les utilisateurs (les acteurs, au sens UML) exercent leur métier. Cette description dynamique est réalisée selon deux axes :
-
L’axe « opération des utilisateurs » traite de ce que les utilisateurs font en contact avec le système. Cet axe est le plus spontané, quasi naturel, car lorsque les utilisateurs racontent leur métier et expriment leurs besoins, ils sont principalement dans le registre du « faire ». Cet axe est formalisé en UML à l’aide du concept d’activité (activity, synonyme de processus), représenté par le diagramme d’activité. Une activité regroupe plusieurs actions unitaires.
-
Un axe « transformation des objets du métier » : cet axe traite de ce que les objets du métier deviennent lorsque les utilisateurs réalisent les opérations de leur métier (celles qui réclament la collaboration du système). Cet axe de description est beaucoup moins spontané, peu décrit par les utilisateurs, et est donc souvent pris en charge par des spécialistes de l’analyse du métier. Il est formalisé en UML à l’aide du concept de machine à états (state machine), représenté...
La notion de cas d’utilisation
1. Définition
Le cas d’utilisation décrit un comportement du système, en réaction à une sollicitation. C’est un moyen excellent de recueillir les exigences fonctionnelles du système, c’est-à-dire les services qu’il est censé rendre.
Les concepts clés sont au nombre de quatre :
-
L’acteur : c’est l’entité externe au système qui va solliciter celui-ci. Ce concept est identique à celui décrit lors de la modélisation dynamique. Un acteur peut être un humain ou une machine externe au système (un autre système).
-
Le cas d’utilisation.
-
L’interaction : c’est le couple demande de l’utilisateur - réponse du système.
-
Le système sujet : c’est la portion du système vu depuis le cas d’utilisation, c’est-à-dire la portion du système que l’acteur va pouvoir solliciter pour obtenir les services correspondants. Ce dernier concept n’est guère utilisé.
Afin de décrire le comportement du système, on exploite la notion d’interaction.
Un cas d’utilisation est fondamentalement un ensemble d’interactions (de couples demande - réponse). Le cas d’utilisation est un dialogue entre l’acteur et le système, que l’acteur (humain ou machine) a eu l’initiative d’engager. Ce dialogue est polarisé (orienté) : pour chacune des interactions du même cas d’utilisation, la demande vient le plus souvent de l’acteur, et la réponse du système.
De façon à rendre cet outil générique au maximum, la demande de l’acteur est assimilée à un événement. Ainsi, lors d’une interaction entre deux systèmes, le système demandeur émet un événement en direction du système cible, lequel répond par la fourniture d’une information.
En principe, un cas d’utilisation n’est exécuté que par un seul acteur. Néanmoins, certains auteurs admettent que plusieurs acteurs soient réunis par le même CU, sous réserve que :
-
Un seul acteur ait l’initiative du dialogue ; on l’appellera...
La description textuelle des cas d’utilisation
Le cas d’utilisation étant un ensemble d’interactions (c’est-à-dire de couples demande de l’acteur - réponse du système), décrire un cas d’utilisation, c’est décrire :
-
chacune des interactions, de manière ordonnée, ainsi que les règles du métier appliquées par le système (également appelées règles de gestion) ;
-
l’événement déclencheur du CU ;
-
les conditions que le système doit remplir pour que le CU puisse s’exécuter (les préconditions) ;
-
l’état du système lorsque le CU vient de s’achever (les postconditions).
C’est donc le moment où sera précisé ce dialogue entre l’utilisateur et le système. Cette description textuelle va permettre de préciser un point très important : il y a plusieurs manières d’exécuter le même cas d’utilisation.
Un scénario est un mode d’exécution du cas d’utilisation. Étant donné un CU, on pourra identifier et décrire trois familles de scénarios :
-
Le scénario nominal : c’est le mode d’exécution du CU lorsque tout se passe bien (il n’y a pas d’erreurs) et qu’il n’y a pas d’extension. Toutes les interactions se déroulent bien.
-
Le(s) scénario(s) exceptionnel(s) : c’est le mode d’exécution lorsqu’une erreur s’est produite (due au système ou à l’acteur) et qu’il faut corriger cette erreur afin d’éviter une panne au système ; en programmation objet, on parle de reprise d’exception. Ce scénario comprend des interactions destinées à traiter des cas spécifiques, potentiellement dangereux.
-
Le(s) scénario(s) optionnel(s) ou alternatif(s) : c’est le mode d’exécution lorsqu’une ou plusieurs interactions facultatives ont été lancées, au choix de l’acteur ou selon les conditions de l’environnement du système.
Là aussi, le niveau de précision de cette description peut varier et la description sera proposée selon trois niveaux :...
Les concepts UML en jeu
1. Le cas d’utilisation
« Use cases are a means to capture the requirements of systems, i.e., what systems are supposed to do. » C’est ainsi qu’UML définit un cas d’utilisation ; autrement dit, le cas d’utilisation se place du côté du système. La question fondamentale est : quel service est rendu à l’acteur par le système ?
Le cas d’utilisation décrit un double comportement : comportement du système et comportement de l’acteur. C’est une vision « boîte noire » : l’organisation interne du système et son comportement interne sont hors sujet. La vision « boîte blanche » du système (son organisation interne et les interactions entre ses composants internes) est l’objet des vues structurale et comportementale.
Exceptions et extensions sont à voir comme des variantes de comportement.
2. L’acteur
Un acteur décrit le rôle joué par tout utilisateur en interaction avec le système. Cet utilisateur peut être un autre système.
L’acteur dialogue avec le système : c’est ce que l’exemple a montré. En fait, est acteur tout ce qui peut dialoguer avec une entité, à condition que cette entité présente un comportement, c’est-à-dire...
Pour aller plus loin
1. Le cas d’utilisation et le pilotage de projet
Il est possible de sortir du trop difficile et rigide cycle en V pour piloter un projet informatique. Les cas d’utilisation sont pour cela une aide précieuse. Deux démarches sont possibles (incrémentale, itérative) :
-
Prototyper, puis construire, tester, livrer cas d’utilisation par cas d’utilisation. Cette démarche incrémentale permet de recueillir au plus tôt les avis de futurs utilisateurs du métier.
-
Construire chaque cas d’utilisation scénario par scénario : le scénario nominal, puis les scénarios d’exception puis ceux d’extension. Cette démarche itérative a l’avantage d’être capable d’encaisser l’instabilité des besoins des utilisateurs, voire les volte-face, sans que l’architecture globale de la solution s’en trouve bouleversée. Cette démarche nécessite en contrepartie une gestion des tests plus volumineuse.
Une méthode d’estimation des charges basée sur les cas d’utilisation (les use case points) a été mise au point par Gustav Karner en 1993, alors ingénieur de la société Rational Software avant son rachat par IBM. On rappelle que cette société a été à l’initiative de la création d’UML en réunissant ses trois auteurs : James Rumbaugh, Grady Booch, Ivar Jacobson (lui-même inventeur du concept de cas d’utilisation). Longtemps restée confidentielle, cette méthode tend à se répandre peu à peu. Elle sera abordée au chapitre Évaluation des charges d’un projet spécifié en UML.
2. Le cas d’utilisation et l’architecture logicielle
Vaut-il mieux expliquer le métier par un grand nombre de petits...
À retenir
1. Le double avantage à tirer d’une formalisation des cas d’utilisation
Les cas d’utilisation permettent de formaliser le comportement du système, lorsqu’un acteur le sollicite.
Cette formalisation fait le plus souvent appel à la notion d’interaction. On appelle interaction le couple demande de l’acteur - réponse du système à cette demande.
Au sein d’un cas d’utilisation, les interactions sont en principe synchrones : la réponse suit la demande et l’acteur attend cette réponse avant de poursuivre son travail.
Ce comportement consiste en un traitement de l’information. Celle-ci est fournie par l’utilisateur ; elle peut avoir été mémorisée auparavant, puis calculée et transformée ; il n’en reste pas moins que toute information a pour origine, directement ou indirectement, une action humaine.
Les cas d’utilisation sont donc un moyen pour raconter le contrat passé entre le système et les acteurs qui l’invoquent.
Mais ils sont aussi un moyen de pilotage de la construction du système : le concepteur devra lui fournir les capacités qui lui permettent de recueillir, mémoriser, transformer et distribuer l’information à qui de droit. Le travail de l’analyste du métier conditionne donc fortement la suite des travaux....