Modélisation de la vue fonctionnelle : Modèle de Cas d’utilisation
Modélisation de la vue fonctionnelle : Modèle de Cas d’utilisation
1. Modèle de Cas d’utilisation. 1
2. Utilisation du modèle de cas d’utilisation. 1
3. Le digramme de cas d’utilisation. 2
8. Association de communication : 3
9. Un exemple de diagramme de cas d’utilisation. 3
10. Relations entre les CUs. 4
11. Relation entre les acteurs. 5
12. Description textuelle de cas d’utilisation. 6
13. Description de haut niveau. 6
14. Description détaillée de chaque cas d’utilisation. 6
16. Un cas d’utilisation essentiel et réel 8
1. Modèle de Cas d’utilisation
Avant de développer un système il faut définir à quoi va-t-il servir.
Les cas d’utilisation est une représentation des fonctionnalités offertes par système de point de vue utilisateur. (Une réponse à la question quoi ? à quoi sert le système).
Par utilisateur on veut dire toute entité externe au système et qui interagisse avec lui. Il peut être une personne, un système, un matériel…etc.
Ce modèle fournit un outil pour organiser, structurer et documenter les informations trouvées durant la phase d’analyse. Il fait partie des artéfacts résultats de l’étape spécification du système du processus de développement.
Les cas d’utilisation sont introduits par Ivar Jacobson au début de 1990s. cette idée est inspirée des idées de scénarios.
2. Utilisation du modèle de cas d’utilisation
1. Capturer les besoins (requirements)
2. Planifier les itérations de développement
3. Valider le système.
Les cas d’utilisation sont présentés : sous forme graphique (diagramme de cas d’utilisation) , description textuelle des cas d’utilisation et des acteurs, les scénarios.
3. Le digramme de cas d’utilisation
Représente graphiquement le domaine d’étude en utilisant les concepts suivants :
1. Le cas d’utilisation(CU)
2. L’acteur
3. Association de communication entre l’acteur et le cas d’utilisation
4. Les limites de domaine.
En UML Ces concepts sont représentés comme suit :
Conceptuellement un digramme de cas d’utilisation est similaire à un menu de haut niveau qui montre les fonctionnalités principales du système.
4. Définition
5. Un cas d’utilisation
Est une représentation d’un service (fonctionnalité) rendu par le système à ses utilisateurs. Il modélise un ensemble de séquence d’actions produisant un résultat de valeur aux utilisateurs de système (acteur).
Un CU est une tâche à réaliser avec l’assistance du système.
N.B. un cas d’utilisation ne spécifie pas comment réaliser ce comportement.
Définition générale (Cockburn) « Un cas d’utilisation établit entre les différents intervenants un contrat régissant le comportement d’un système. Il décrit ce comportement sous diverses conditions, lorsque le système répond à une requête émanant de l’un des intervenants, appelé acteur principal. L’acteur principal amorce une interaction avec le système en vue d’atteindre un objectif particulier. Le système répond, en veillant à protéger les intérêts de tous les intervenants. Diverses séquences de comportement, ou scénarios, peuvent se déployer en fonction des requêtes effectuées et des conditions de leur réalisation. Le cas d’utilisation regroupe ces différents scénarios. »
6. Un acteur
Représente un rôle joué par une entité qui interagisse avec le système.
Un acteur représente un type d’utilisateur de système.
Exemple
Omar peut jouer le rôle de l’électricien et l’utilisateur. (fig 1.)
7. Types d’acteurs
Acteur primaire. : s’il est l’initiateur des échanges avec le système
Acteur secondaire. S’il est seulement sollicités par le système pour achever l’objectif
8. Association de communication :
Une relation entre un acteur et un cas d’utilsation. Représente le fait que une entité ayant ce rôle démmare le cas d’utilisation.
9. Un exemple de diagramme de cas d’utilisation
Problème de contrôle d’une lampe par un interrupteur (TD N°1)
Fig 1. Un exemple de diagramme de cas d’utilsation
10. Relations entre les CUs
La relation « include »
« include »
CU 1 est une partie obligatoire de CU 2.
Utile quand on peut factoriser un comportent commun à deux CU ou plus.
Lecture : cu1 inclut cu2 (dans le sens de la flèche).
Ceci veut dire que CU1 doit obligatoirement contenir CU2. C.a.d toute exécution de cu1 entraine l’exécution de cu2.
Par exemple : pour allumer, éteindre la lampe ou la changer il faut effectuer un login.
La relation « extend » étend
« extend »
CU2 est un comportement optionel de CU1
Utile pour spécifier qu’un CU1 peut-être augmenté avec le CU2
Lecture cu2 étend cu1 (dans le sens de la flèche).
Exemple
« extend »
Relation généralisation
Le cas CU1 est une généralisation du cas du cas CU1.
Lecture CU2 est une sorte de CU1.
Exemple
11. Relation entre les acteurs
Relation généralisation
Un électricien est un utilisateur.
Un internaute est un client.
12. Description textuelle de cas d’utilisation
Un nom représente un résumé d’un cas d’utilisation.
Une description de haut niveau et une description détaillée (e.g. textuelle) sont nécessaires pour comprendre chaque C U.
13. Description de haut niveau
Exemple
Retirer DeLArgent AuDistributeur
Lorsqu’un client a besoin de liquide il peut en utilisant un distributeur retirer de l’argent de son compte. Pour cela :
- le client insère sa carte bancaire dans le distributeur
- le système demande le code pour l ’identifier
- le client choisit le montant du retrait
- le système vérifie qu’ ’il y a suffisamment d ’argent
- si c’est le cas, le système distribue les billets et débite le compte du client
- le client prend les billets et retire sa carte
14. Description détaillée de chaque cas d’utilisation
Informations à décrire
Quand le cas d'utilisation commence, pré-conditions
Quand le cas d'utilisation se termine, post-conditions
Le chemin correspondant au déroulement normal
= les interactions entre le système et les acteurs
Les variantes possibles et les cas d’erreurs
Les éventuels besoins non fonctionnels
Exemple :
Retirer DeLArgent AuDistributeur
Précondition :
Le distributeur contient des billets, il est en attente d’une opération, il n’est ni en panne, ni en maintenance
Début : lorsqu’un client introduit sa carte bancaire dans le distributeur.
Fin : lorsque la carte bancaire et les billets sont sortis.
Postcondition :
Si de l’argent a pu être retiré la somme d’argent sur le compte est égale à la somme d’argent qu’il y avait avant, moins le montant du retrait. Sinon la somme d ’argent sur le compte est la même qu’avant.
Déroulement normal :
(1) le client introduit sa carte bancaire
(2) le système lit la carte et vérifie si la carte est valide
(3) le système demande au client de taper son code
(4) le client tape son code confidentiel
(5) le système vérifie que le code correspond à la carte
(6) le client choisi une opération de retrait
(7) le système demande le montant à retirer
…Variantes :
(A) Carte invalide : au cours de l’étape (2) si la carte est jugée invalide, le système affiche un message d’erreur, rejette la carte et le cas d’utilisation se termine.
(B) Code erroné : au cours de l ’étape (5)
Contraintes non fonctionnelles :
(A) Performance : le système doit réagir dans un délai inférieur à 4 secondes, quelque soit l’action de l’utilisateur.
(B) Résistance aux pannes : si une coupure de courant ou une autre défaillance survient au cours du cas d’utilisation, la transaction sera annulée, l’argent ne sera pas distribué.
Le système doit pouvoir redémarrer automatiquement dans un état cohérent et sans intervention humaine.
(C) Résistance à la charge : le système doit pouvoir gérer plus de 1000 retraits d’argent par jour
15. Scénario
Un scénario est un exemple d’utilisation de système par un acteur particulier dans un contexte spécifique.
On peut dire que c’est une instance (réalisation ou exécution particulière)d’un cas d’utilisation et un CU est une représentation d’un ensemble de scénarios.
Exemple
CU : Retirer DeLArgent AuDistributeur
SCENARIO a
• Le client insère sa carte dans le distributeur d2103
• Le système accepte la carte et lit le numéro de compte
• Le système demande le code
• Le client tape ‘ 1234 ’
• Le système indique que ce n’est pas le bon code
• Le système affiche un message et propose de recommencer
• Le client tape ‘ 6622’
• Le système affiche que le code est correct
• Le système demande le montant du retrait
• Le client tape 10000 Euros
• Le système vérifie s’il y a assez d ’argent sur le compte
16. Un cas d’utilisation essentiel et réel
Il est important de comprendre la différence entre ces deux types.
Un cas d’utilisation est dit essentiel s’il ne contient pas des détails de conception ou d’implémentation. Ce type est produit au début d’analyse avant que les décisions de conception et d’implémentation sont faites.
Un cas d’utilisation est de type réel s’il contient des détails sur la conception et l’implémentation. Par exemple un cas réel montre les détails concernant l’interface de l’utilisateur.