Diagrammes de cas d’utilisation

Diagrammes de cas d’utilisation

La partie fonctionnelle du modèle UML d’une application permet de spécifier les fonctionnalités offertes par l’application sans pour autant spécifier la façon dont ces fonctionnalités sont réalisées par les objets de l’application. Le principe fondateur du paradigme objet est de réunir en une seule et même entité, l’objet, des données et des traitements. À l’époque de la création de ce paradigme, ce principe était considéré comme révolutionnaire, car il allait à rebours des paradigmes existants (fonctionnel et données), qui visaient à séparer les données et les traitements dans des entités différentes. L’avantage le plus important qu’apporte ce principe fondateur est de permettre l’identification, la décomposition et la réutilisation d’entités capables de réaliser des traitements uniquement grâce aux données qu’elles possèdent. Avec le paradigme objet, il est possible de considérer une application comme un ensemble d’objets indépendants mais cohérents, chacun réalisant la tâche pour laquelle il a été conçu. Ainsi, si une tâche réalisée par un objet est nécessaire dans une autre application, il est possible de réutiliser l’objet. L’inconvénient de ce principe fondateur est qu’il masque les fonctionnalités offertes par des groupes d’objets. En effet, leur spécification n’est pas explicite et est répartie dans les traitements et dans les interactions réalisés par chacun des objets participant au groupe. De ce fait, il est très difficile de spécifier les besoins fonctionnels que nous avons sur une application à l’aide d’objets. Ces besoins fonctionnels, qui s’expriment naturellement à l’aide de fonctions, ne peuvent donc être exprimés simplement sous forme de groupes d’objets.

Par exemple, si nous voulions spécifier à l’aide d’objets les besoins fonctionnels d’une application de gestion de prêts bancaires tels que la création d’un prêt ou le calcul d’un taux d’intérêt, il faudrait spécifier l’ensemble des objets participant à la réalisation de l’application et spécifier chacun des traitements associés à ces objets. Si cela reste faisa- ble, ce n’est guère naturel pour nous développeurs, plutôt habitués à utiliser le découpage fonctionnel. Pour résoudre ce problème et réconcilier le paradigme objet avec la possibilité d’expri- mer les besoins d’une application sous forme de fonctions, UML définit le concept de cas d’utilisation.Nous recommandons que l’intitulé du cas d’utilisation respecte le pattern « verbe + compléments ». Le verbe de l’intitulé permet de spécifier la nature de la fonctionnalité offerte par l’application, tandis que les compléments permettent de spécifier les données d’entrée ou de sortie de la fonctionnalité. Le concept de cas d’utilisation offre une vue fonctionnelle sur l’application. La façon dont sera réalisé concrètement un cas d’utilisation n’apparaît pas dans la définition du cas d’utilisation. Elle sera précisée par la suite, lors de l’établissement des liens de cohérence avec les autres parties du modèle.

Il est possible d’élaborer plusieurs diagrammes de cas d’utilisation à chaque niveau d’abstraction permettant de regrouper les fonctionnalités de l’application en différents sous-systèmes. Cependant, nous considérons dans ce cours qu’il suffit d’élaborer un unique diagramme de cas d’utilisation par niveau d’abstraction. Ce diagramme représente les fonctionnalités principales de l’application à un niveau d’abstraction donné et les principaux bénéficiaires de ces fonctionnalités. Il correspond en quelque sorte à l’emballage commercial des applications vendues en grande surface, sur lequel sont écrites les fonctionnalités offertes par l’application à ses utilisateurs. Nous savons que les fonctionnalités d’une application orientée objet sont réalisées par les objets qui composent l’application. Ces objets sont spécifiés à l’aide des classes présentes dans la partie structurelle du modèle de l’application, alors que les fonctionnalités sont spécifiées dans la partie fonctionnelle du modèle. Il est donc nécessaire de faire apparaître un lien de cohérence entre les parties structurelle et fonctionnelle du modèle UML afin de savoir quels sont les objets réalisant telle ou telle fonctionnalité.