Analyse et Conception avec UML
n Utilisation d’un dictionnaire du domaine
n Les acteurs UML
n Les use-cases UML
n Outil de dialogue
n Informel, évolutif, simple a réaliser
n Etablir et figer la terminologie
– Permet de figer la terminologie du domaine d'application.
– Constitue le point d'entrée et le référentiel initial de l'application ou du système.
| |
Exemple de dictionnaire
– Dictionnaire d'un simulateur de vol
n L’université ESU (Pennsylvanie) désire automatiser son système d’inscription
– Le chef du service des inscriptions établit le programme des cours pour un semestre
• Un cours peut être offert plusieurs fois
– Les étudiants doivent sélectionner 4 cours primaires et 2 cours secondaires
– Dès qu’un étudiant s’est inscrit pour un semestre, le système de facturation est notifié
– Les étudiants peuvent utiliser le système pour modifier leurs choix pendant une certaine période de temps après leur inscription
– Les enseignants utilisent le système pour consulter leur emploi du temps (tableau d’activités en fonction des cours qui tournent)
– Les utilisateurs du système d’inscription reçoivent des mots de passe qui sont nécessaire à la procédure d’identification
n Une des notations d ’UML (use-cases)
n But :
– définir le système du point de vue des utilisateurs
– définir les limites précises du système
n Notation très simple, compréhensible par tous n Permet de structurer :
– les besoins (cahier des charges)
– le reste du développement
– la progression d ’un cycle en spirale
n Les cas d'utilisation sont nommes en utilisant la terminologie décrite dans le dictionnaire
Jean-Marie Favre S A3
n L’université ESU (Pennsylvanie) désire automatiser son système d’inscription
– Le chef du service des inscriptions établit le programme des cours pour un semestre
• Un cours peut être offert plusieurs fois
– Les étudiants doivent sélectionner 4 cours primaires et 2 cours secondaires
– Dès qu’un étudiant s’est inscrit pour un semestre, le système de facturation est notifié
– Les étudiants peuvent utiliser le système pour modifier leurs choix pendant une certaine période de temps après leur inscription
– Les enseignants utilisent le système pour consulter leur emploi du temps (tableau d’activités en fonction des cours qui tournent)
– Les utilisateurs du système d’inscription reçoivent des mots de passe qui sont nécessaire à la procédure d’identification
n Définir les acteurs externes
– physiques et logiques – rôle et entité concrète
« Un acteur est une personne ou une chose qui va interagir avec le système »
n Définir les acteurs externes
– physiques et logiques – rôle et entité concrète
« Un acteur est une personne ou une chose qui va interagir avec le système »
Etudiant
8
n Définir les acteurs externes
– physiques et logiques – rôle et entité concrète
« Un acteur est une personne ou une chose qui va interagir avec le système »
Etudiant
8
n Définir les acteurs externes
– physiques et logiques – rôle et entité concrète
« Un acteur est une personne ou une chose qui va interagir
avec le système »
Enseignant
Etudiant
8
n Définir les acteurs externes
– physiques et logiques – rôle et entité concrète
« Un acteur est une personne ou une chose qui va interagir
avec le système »
Enseignant
Etudiant
Système
de facturation
Client
n Un Acteur =
– élément externe qui interagit avec le système – rôle qu’un utilisateur joue par rapport au système ex: un enseignant, un guichetier
n Une même personne peut jouer plusieurs rôles ex: Marie est enseignante et étudiante
Maurice est directeur mais peut faire le guichetier
n Plusieurs personnes peuvent jouer un même rôle ex: Paul et Pierre sont deux clients
n Un acteur n’est pas forcément un être humain
ex: un distributeur de billet peut être vu comme un
acteur; un gestionnaire de mot de passes
Client
n Pour chaque acteur :
– choisir un identificateur représentatif de son rôle
– donner une brève description textuelle
Un guichetier est un employé de la banque chargé de faire l?interface entre le système informatique et les clients qu?il reçoit au comptoir. Le guichetier peut réaliser les opérations courantes : création d ?un compte, dépôt et retrait d ?argent, etc.
Guichetier
Jean-Marie Favre
n L’université ESU (Pennsylvanie) désire automatiser son système d’inscription
– Le chef du service des inscriptions établit le programme des cours pour un semestre
• Un cours peut être offert plusieurs fois
– Les étudiants doivent sélectionner 4 cours primaires et 2 cours secondaires
– Les étudiants peuvent utiliser le système pour modifier leurs choix pendant une certaine période de temps après leur inscription
– Les enseignants utilisent le système pour consulter leur emploi du temps (tableau d’activités en fonction des cours qui tournent)
– Les utilisateurs du système d’inscription reçoivent des mots de passe qui sont nécessaire à la procédure d’identification
Maintenir le Demander un Gérer un
Programme tableau de service Emploi du Temps
Cas d’utilisation
n Un cas d’utilisation est un motif de comportement intrinsèque au système
– Chaque cas d’utilisation est une séquence de transactions connectées, effectuées par un dialogue entre un acteur et le système
n Identification des besoins des acteurs
– Chef du service des inscriptions – maintenir le programme des études
– Enseignant – demander un tableau de service
– Etudiant – s’établir un emploi du temps
– Système de facturation – recevoir les informations de facturation du système d’inscription
Maintenir le Demander un Gérer un
Programme tableau de service Emploi du Temps
Système
– les cas d ’utilisation,
– mais pas les acteurs.
n Un modèle de cas d ’utilisation permet de définir :
– les fonctions essentielles du système,
– les limites du système,
– le système par rapport à son environnement.
Diagramme des cas d’utilisation
| Enseignant |
| Système de facturation |
n Objectif visualiser les relations entre acteurs et cas d’utilisation
n Au fur et à mesure que les cas d’utilisation sont documentés, des relations peuvent apparaître
– Une relation includes utilisation systématique
– Une relation extends dénote un comportement optionnel :
n 1 cas d’utilisation
– ensemble d’actions fournissant un résultat observable pour un acteur particulier.
– Quoi pas Comment (ni IHM, ni erreur)
– Décrire exhaustivement les exigences fonctionnelles
n Pour chaque cas d’utilisation candidat
– vérifier qu ’il fournit une valeur ajoutée notable
– contrôler qu’un événement externe au système déclenche son exécution
– décrire le cas d ’utilisation succinctement
n Acteur principal
– celui pour lequel le cas d’utilisation produit la plus value métier
n Attention
– à ne pas descendre trop bas
• un cas d’utilisation est une séquence d ’actions du système concrétisant une intention de l ’acteur
– à ne pas réinventer la décomposition fonctionnelle
• limiter à 20 le nombre de cas d’utilisations
– ne pas mélanger IHM et fonctionnel
Précondition :
Retirer Début : lorsqu ?un client introduit sa carte bancaire dans le DeLArgent 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.
Jean-Marie Favre
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
AuDistributeur (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, rejète la carte et le cas d ?utilisation se termine.
(B) Code erroné : au cours de l ?étape (5)
Jean-Marie Favre
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.
DeLArgent (B) Résistance aux pannes : si une coupure de courant ou
AuDistributeur 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 simultanément
Jean-Marie Favre