[PDF] Chapitre II : Diagramme de cas dutilisation

View - Download Chapitre II : Diagramme de cas dutilisation

Previous PDF

Next PDF

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.

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.client acteurConsulter un solde

Retirer de l'argent

Verser l'argentBorne interactive d'une BanqueLimites du systeme

Systeme

Cas d'utilisation

Relations

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 preconditions.

Quand le CU se termine ? Les postconditions.

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 : Retirer de l'argent du distributeur :

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 :Retirer de l'argent

du distributeurPr écondition : Avoir de l'argent disponible fonctionel Debut : Insertion de la carte bancaire bancaire par le client.

Fin : Retrait de l'argent + la carte

Postcondition : Mettre a pour le solde. Si retrait effectuer operation annul é et solde tel qu'il est. SinonGarder 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

éePanne

Contraintes non fonctionelles :

>> Performances : Le systeme doit reagir dans un delait de

4 secondes, resistances aux pannes, resistance a la charge,

connexions en paralelle.

Retirer de l'argent

Retirer de l'argentS'identifier

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 BIl 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 :

Si le client existe on n'a pas besoin de le cr

éer.Dans certain cas, on peut

être appelé a verifier le solde lors d'un virement.Verifier solvabilité client

Verifier disponibilité

articlePasse code

Chargé des

codes UC AUC B

Créer clientGerer client<< extend >>

Effectuer virementVerifier solde<< extend >>

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.N.B : Contrainte au deux autres relations. La generalisation n'est pas un stereotype.AcheterLivrer<< extend >>

Payer

PayerPayerPayer

Retirer de l'argent

Retirer sur compte

epargneS'authentifier

Verification condition

de compte d'epargne <> <> 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 :

III.3. Relation entre acteurs :

La seul relation possible entre acteurs est la relation de generalisation.

ATTENTION :Creer un compte

Relation de

communicationFrontiere du systeme

Creer un compte

Fermer un compte

Retirer de l'argent sur

un compte

Annuler compte

Consulter compte

Retirer argent du

distributeur

Retirer argent

chequeFAUX !

Pas de communication

entre acteursRetirer argent

Consulter soldeFAUX !

Pas de communication

entre UCGuichetier en chefGuichetierquotesdbs_dbs13.pdfusesText_19

[PDF] diagramme de cas d'utilisation exercice corrigé

[PDF] scénario alternatif définition

[PDF] diagramme de sequence uml pdf

[PDF] diagramme de cas d utilisation extend

[PDF] diagramme de classe uml pdf

[PDF] lexique comptable anglais français pdf

[PDF] most common english expressions

[PDF] vocabulaire comptable anglais pdf

[PDF] correspondance plan comptable anglais francais

[PDF] regle de grammaire arabe tome 2

[PDF] conjugaison des verbes en arabe pdf

[PDF] corrigé cas ovh management

[PDF] corrigé bts management des entreprises 2016

[PDF] cas electra corrige

[PDF] cas fixit