Chapitre II : Diagramme de cas d'utilisation I) Definition : Le diagramme de cas d'utilisation est un diagramme UML utilisé pour donner une vision globale du comportement fonctionnel d'un systeme logiciel. Un cas d'utilisation represente une unité discrete d'interaction entre un utilisateur (Human ou Machine) et un system. Il est une entité significative de travail Dans un diagramme de cas d'utilisation il existe des acteurs (actors) qui interagissent avec des cas d'utilisation (use case) UC. Les use case permettent de structurer les besoins des utilisateurs et les objectifs du systeme. Une fois identifié et structuré ces besoins : Definissent le contour du systeme a modiliser. Permettent d'identifier les fonctionalités principales ou critiques du systeme. II) Formalisme : II.1. Notion de systeme : Le systeme est un ensemble de cas d'utilisation, il contient les cas d'utilisation mais pas des acteurs. Un modele de cas d'utilisation permet de definir : Les fonctions essentielles du systeme. Les limites du systeme. Le systeme par rapport a son environnement. Limites du systeme Borne interactive d'une Banque Systeme Consulter un solde Cas d'utilisation Verser l'argent client acteur Relations II.2. L'acteur : La premiere etape de modelisation consiste a definir le perimetre du systeme. Toute entité en dehors de cette organisation et qui interagi avec le systeme est appelé acteur selon UML.
Un acteur est un type stereotypé representant une abstraction qui reside juste dehors du systeme. Remarque : Un acteur n'est pa forcement une personne physique, elle peut etre une societé, un robot, un service, etc... Il existe quatre types d'acteurs : II.2.1. Les acteurs principaux : Ce sont les acteurs qui vont realiser le cas d'utilisation. II.2.1. Les acteurs secondaires : Les acteurs secondaires ceux qui font que recevoir des informations a l'issue de la realisation d'un cas d'utilisation. II.2.3. Peripheriques externes : Les dispositifs materiaux incontonnables qui font partie du domaine de l'application et qui doivent absolument être utilisés. Ex ; capteur, horloge externe, etc... II.2.4. Systeme externe : Les systemes avec lesquels le systeme interagie. Ex ; Le systeme interbancaire, le fisc, l'etat. N.B : Ne pas confondre entre Acteur et Utilisateur (personne qui utilise le systeme) Remarque : Une même personne peut jouer plusieurs roles, ex : Morris est directeur mais jou le rôle de guichetier. Plusieurs personnes peuvent jouer un même rôle. Un acteur n'est pas forcement un être humain. II.3. Le cas d'utilisation : II.3.1. Desctription detaillé d'un cas d'utilisation : Quand le cas d'utilisation commence? Les pre conditions. Quand le CU se termine? Les post conditions. Le chemin correspondant au deroulement normal. Les variantes possibles et les cas d'erreurs Les informations entre le systeme et les acteurs. Les informations echangés Les eventuels besoins non fonctionnels.
Exemple : du distributeur : du distributeur Précondition : Avoir de l'argent disponible fonctionel Debut : Insertion de la carte bancaire bancaire par le client. Fin : Retrait de l'argent + la carte Post condition : Mettre a pour le solde. Si retrait effectuer operation annulé et solde tel qu'il est. Sinon Garder la carte si carte volé. Deroulement normale : > Client insere la carte > Systeme lit la carte et verifie la validation > Demande de code > Verification du code > Choisir operation de retrait > Systeme demande le montant > Choix valide > Le systeme fournit la carte, les billets et le ticket Variantes : Carte invalide Carte eronée Panne Contraintes non fonctionelles : >> Performances : Le systeme doit reagir dans un delait de 4 secondes, resistances aux pannes, resistance a la charge, connexions en paralelle. III) Les relations : III.1. Les relations entre Use Case : a L'inclusion : Dans ce type d'interaction (association), le premier cas englobe l'autre, et son issue de la resolution du second. Ce type de description est utile pour extraire un ensemble de sous comportements communs. Plusieurs taches. Elle est representé par une fleche en pointié et le stereotype «include» Exemple : S'identifier
Verifier solvabilité client Passe code Chargé des codes Verifier disponibilité article b L'extention : Les extentions stereotyopes «extends» represente des prolongement logique de certaines taches sous certaines conditions. Autrement dit, un cas d'utilisation A etant un cas d'utilisation B, l'orsque le cas d'utilisation A peut être appelé au cours de l'execution du cas d'utilisation B UC A UC B Il est representé par une fleche en pointiés avec le terme «extend» Ce type de relations peut être utile pour traiter des cas particuliers. Exemple : Créer client << extend >> Gerer client Si le client existe on n'a pas besoin de le créer. Effectuer virement << extend >> Verifier solde Dans certain cas, on peut être appelé a verifier le solde lors d'un virement.
Acheter << extend >> Livrer c La generation : Le cas d'utilisation A est une generalisation du cas d'utilisation B si B est un cas particulier de A, c'est a dire lorsque A peut être substitué par B pour un cas preci. Ces relations sont des trains pleins terminés par une flèche en triangle. <<include>> S'authentifier Retirer sur compte epargne <<include>> Verification condition de compte d'epargne N.B : Contrainte au deux autres relations. La generalisation n'est pas un stereotype.
III.2. Les relations entre acteur et cas d'utilisation : Represente une communication initié par l'utilisation. Elle represente un echange de message potentiellement dans les deux sens. Ex : Creer un compte Relation de communication Frontiere du systeme III.3. Relation entre acteurs : La seul relation possible entre acteurs est la relation de generalisation. Creer un compte Guichetier Fermer un compte sur un compte Annuler compte Guichetier en chef ATTENTION : FAUX! Pas de communication entre acteurs Consulter compte Retirer argent du distributeur Retirer argent cheque Retirer argent FAUX! Pas de communication entre UC Consulter solde