Diagrammes de CAS D’UTILISATION Modélisation Fonctionnelle

MODELISATION PAR CAS D’UTILISATION Place dans le processus de développement Besoins des utilisateurs Modélisation des cas d’utilisation Modélisation « Métier » Maquette IHM Modélisation de conception détaillée Modélisation dynamique Modélisation objet Scénarios d’utilisation Structuration Modélisation de l’architecture Modélisation des interactions Code

MODELISATION FONCTIONNELLE Décider de ce qu'il faut faire A quoi sert le logiciel?

MODELISATION PAR CAS D’UTILISATION Généralités Technique formalisée par Ivar Jacobson. Destinée à l ’expression du besoin. Complète le modèle objet en offrant une vision « fonctionnelle » du système. Centrée sur les utilisateurs. Formalisme très simple. Peut également servir à la conception des tests de validation.

MODELISATION PAR CAS D’UTILISATION Lien avec le modèle objet Intégration Réalisation Validation Conception Préliminaire Spécifications Cas d'utilisation Modèle Objet

MODELISATION PAR CAS D’UTILISATION Définition Un cas d’utilisation « raconte » comment on doit utiliser le système pour atteindre un but particulier Il correspond à une fonction du système Il décrit les interactions entre le système et les utilisateurs Il est exprimé en prose structurée Il détermine un contrat à remplir par le système Il induit des exigences fonctionnelles applicables au système et il peut être utilisé pour organiser la spécification

DIAGRAMMES DE CAS D ’UTILISATION Concepts ACTEUR représente un rôle joué par une personne ou une chose qui interagit avec le système mais qui lui est extérieure. est caractérisé par un nom qui exprime son rôle. une même personne physique peut être modélisée par plusieurs acteurs. Etudiant Inscription CAS D ’UTILISATION unité fonctionnelle cohérente assurée par un système ou une classe correspond à un certain type d’interaction entre le système et les acteurs. doivent être vus comme des classes dont les instances sont des scénarios.

DIAGRAMMES DE CAS D ’UTILISATION Un premier exemple

CAS D ’UTILISATION Identification des acteurs On distingue 4 catégories d ’acteurs: les acteurs principaux (ex: usager, client, etc.) les acteurs secondaires (ex: opérateur de maintenance, administrateur, etc.) le matériel externe (capteurs, imprimantes, périphériques divers, etc.) les autres systèmes (serveur central, service ou organisation, etc.) Un Acteur peut hériter d’autres Acteurs. Un Acteur peut posséder des Interfaces. Cycliste Facteur Circuler à bicyclette Distribuer le courrier

DIAGRAMMES DE CAS D ’UTILISATION Exemple de modélisation des acteurs

Source: Système Aéroporté de Surveillance Terrestre DIAGRAMMES DE CAS D ’UTILISATION Exemple avec utilisation de stéréotypes Operateur (from Segment Sol) Operateur de Maintenance Opérateur de Commandement Organisme Coordination communication d'Administration Opérateur CU Charge Utile (from Segment Air) pilotage Plate Forme Aeronautique +porteur Opérateur Contrôle/commande contrôle Source: Système Aéroporté de Surveillance Terrestre

DIAGRAMMES DE CAS D ’UTILISATION Modélisation des utilisateurs

CAS D ’UTILISATION Identification (1) Les cas d ’utilisation correspondent aux principales tâches de chaque acteur à une valeur ajoutée pour l ’utilisateur à des fonctionnalités ou à des services attendus à des opérations sur les données du système à des anomalies ou des cas particuliers. Un cas d ’utilisation doit être simple (description de 1 ou 2 pages maximum). Le nombre d ’acteurs en relation avec un cas d ’utilisation ne doit pas être trop important. 2 activités qui s ’enchaînent toujours font généralement partie du même cas d’utilisation. La difficulté majeure est de trouver le bon niveau d’abstraction.

CAS D ’UTILISATION Identification (2) Un cas d’utilisation représente un processus de « haut niveau » se déroulant de bout en bout et incluant plusieurs étapes successives. Ce n’est pas une opération élémentaire ou une transaction. Un cas d’utilisation peut être vu comme une collection de scénarios décrivant différentes façons d’utiliser le système pour atteindre un même but (avec ou sans succès). Un cas d’utilisation ne se décompose pas en « sous- cas d’utilisation ».

CAS D ’UTILISATION Description caractéristique La description d’un cas d’utilisation débute par une phrase du type « Ce cas d’utilisation est déclenché quand <un acteur> <adresse un stimulus au système> …» privilégie les interactions entre les acteurs et le système s’attache prioritairement à la séquence des événements qui conditionnent les interactions (flux nominal) se termine lorsque le but est atteint ou dans une situation d'exception. Si cette description est impossible, c’est probablement parce que l’objet considéré n’est pas vraiment un cas d’utilisation …

CAS D ’UTILISATION Construction 1) Identifier les acteurs (Qui utilise le système?) 2) Identifier grossièrement les cas d ’utilisation essentiels. 3) Identifier les cas d ’utilisation exceptionnels. 4) Décrire chaque cas d ’utilisation en quelques phrases. 5) Elaborer un diagramme. 6) Vérifier que tous les besoins identifiés ont été alloués à un cas d ’utilisation. 7) Recenser les principaux scénarios pour chaque cas d ’utilisation.

CAS D ’UTILISATION Niveaux de description Général Brève description 3-5 phrases Détaillé Description précise et structurée Description des alternatives Calculer un itinéraire Titre: Calculer un itinéraire Acteur: Usager Description: Ce cas d’utilisation commence lorsque l’usager se connecte au système pour obtenir un itinéraire à suivre. Il précise son lieu de départ et son lieu d’arrivée ainsi que les paramètres de calcul. Le système lui fournit une chronologie des étapes à suivre pour atteindre la destination dans les conditions souhaitées.

CAS D ’UTILISATION Description détaillée CANEVAS: nom explicite (= label UML) acteurs concernés brève description (entre 3 et 10 lignes) pré-conditions événement déclenchant événement qui cause l ’arrêt Résultats attendus / post-conditions description du flot d ’événements principal interactions avec les acteurs échanges d ’informations (paramètres des interactions) chronologie et origine des informations répétitions de comportement description des flots secondaires et des exceptions contraintes et règles de gestion exigences couvertes

CAS D ’UTILISATION Exemple: 1ère partie

CAS D ’UTILISATION Exemple: 2ème partie

DIAGRAMMES DE CAS D ’UTILISATION Liens entre cas d ’utilisation Communication – exprime le fait que l ’acteur participe à la réalisation d ’un cas d ’utilisation . C ’est la seule relation qui peut exister entre un acteur et un cas d ’utilisation. Consommateur Payer Généralisation - un cas d ’utilisation « enfant » hérite du comportement et de la sémantique du cas d ’utilisation parent Relation « Include » – Une relation « include » du cas d ’utilisation A vers le cas d ’utilisation B signifie que le flot d ’événements de A contient une séquence d ’événements qui correspond à B. Relation « Extend » – Une relation « extend » du cas d ’utilisation A vers le cas d ’utilisation B signifie que le flot d ’événements de A peut intervenir, de façon facultative, pendant le déroulement de B. B spécifie un comportement facultatif

DIAGRAMMES DE CAS D ’UTILISATION Exemple de relation « include » L ’existence d ’une relation « include » sur un cas d ’utilisation signifie qu’il inclut le comportement défini par un autre cas d ’utilisation. Rechercher une destination <<include>> Usager <<include>> Calculer un itineraire Visualiser sur fond de carte <<include>> Suivre les déplacements des Controleur véhicules La relation « include » permet de factoriser certaines parties d’un cas d ’utilisation

DIAGRAMMES DE CAS D ’UTILISATION Exemple de relation « extend » L ’existence d ’une relation « extend » sur un cas d ’utilisation signifie qu’il constitue une extension possible du comportement défini par le cas d ’utilisation désigné. mot clef (stéréotype) <<extend>> demande de remplacement de chaque occurrence trouvée Rechercher Extension points définition du remplaçant: avant début de recherche substitution: à chaque occurrence trouvée Remplacer Condition d’extension Points d’extension UML permet d’exprimer les conditions et les points d’extension.

DIAGRAMMES DE CAS D ’UTILISATION Exemple (1) Usager Rechercher une destination Calculer un itinéraire Controleur Visualiser sur fond de carte <<include>> Suivre les déplacements des véhicules Suivre les déplacements en convoi <<extend>>

DIAGRAMMES DE CAS D ’UTILISATION Cardinalités du lien de communication Usager Appeler un correspondant 1 Téléphoner en mode conférence <<extend>> Correspondant *

DIAGRAMMES DE CAS D ’UTILISATION Exemple (1) Source: Système Aéroporté de Surveillance Terrestre

DIAGRAMMES DE CAS D ’UTILISATION Exemple (2) Source: Système Aéroporté de Surveillance Terrestre

DIAGRAMMES DE CAS D ’UTILISATION Exemple (3) <<extend>> Programmation <<include>> Opérateur Centre de Mission Contrôle Emission de télécommandes <<include>> <<Actor>> Satellite Visualisation fil de l'eau <<extend>> Acquisition de Télémétries <<include>> Traitement Archivage Météorologue <<include>> Suivi de Mission Réception de télémesures Diffusion

CAS D ’UTILISATION Intérêt méthodologique Recentre le développement sur le besoin. Délimite le système à étudier. Permet d ’améliorer la compréhension du fonctionnement. Assure la transition entre l’aspect fonctionnel du cahier des charges et l ’aspect objet de la conception technique. Permet de planifier le développement. Edition Graphique Commandement Interprétation d'image Edition de Plan Renseigné Edition de Situation Gestion Données Edition Graphique Visualisation Carto/Géo Itération d ’architecture Itération de développement 1 Itération de développement 2 Itération de développement 3 Itération de développement 4 Proto  V1 = Proto + V2 = V1 + V3 = V2 + V4 = V3 + Photo Interprète Edition de Situation Edition de Plan Renseigné Interprétation d'image Gestion Données Visualisation Carto/Géo Administrateur

CAS D ’UTILISATION Hiérarchisation Il faut commencer par réaliser les cas d’utilisation les plus importants … Critères de priorité d’un cas d’utilisation: Importance de la fonctionnalité pour l’utilisateur Impact sur l’architecture technique Complexité des fonctions mises en œuvre Poids des exigences et contraintes à satisfaire Nouveauté de la technologie utilisée Incidence économique

CAS D ’UTILISATION Recommandations Ne pas présumer des choix de conception d’IHM Ne pas considérer les cas d’utilisation comme de simples fonctions. Ne pas chercher à spécifier le détail des cas d’utilisation "du premier coup" Ne pas hésiter à compléter le cas d’utilisation par d'autres diagrammes UML. Étudier alternativement les scénarios nominaux, alternatifs et d'exception Il est plus judicieux de séparer le travail concernant l’IHM d’un cas d’utilisation et le travail de spécifications fonctionnelles d’un cas d’utilisation. L’intérêt de séparer ces deux tâches concerne les évolutions futures du système : par exemple des modifications de choix d’IHM n’impacte pas le métier que l’on cherche à décrire ; il est donc normal que nos spécifications restent stables et inchangées. Il est donc fortement déconseillé de préciser dans les scénarios : « l’utilisateur choisit dans la ListBox un cours et clique sur le bouton Valider ». Ce type d’action n’est pas de la compréhension du métier. 2. Il faut bien différencier la notion de scénario et de cas d’utilisation. Un cas d’utilisation est un ensemble de scénarii. on peut pratiquement proposer l’analogie Classe – Objet, en ce sens que le scénario peut être considéré comme une instance d’un cas d’utilisation. 3. La description d’un cas d’utilisation en peut pas se faire d’un « seul jet ». Il ne faut chercher à d’écrire dans le détails tous les acteurs, toutes les pré et post conditions, tous les scénarii du cas d’utilisation. Les spécifications doivent être menées de façon itérative : On s’attarde d’abord à identifier les acteurs et un bref résumé pour les cas d’utilisation. La connaissance du métier s’enrichissant (échanges entre les fonctionnels et l’équipe de développement), les premiers scénarii pourront être proposés et ainsi de suite. 4. Proposer des diagrammes de séquence pour les scénarii, de classes pour les concepts métier participants au cas d’utilisation… 5. Je précise ici les définitions des termes que j’utilise pour décrire les scénarios des cas d’utilisation. En effet, comme je le précise en début d’article il n’y a pas de « normalisation » pour décrire les cas d’utilisation et donc suivant les analystes, les termes n’ont pas exactement le même sens. Dans notre cas, - Scénario nominal : C’est le scénario « idéal » (tout se passe bien) pour le cas d’utilisation. On décrit un enchaînement d’actions (Acteur-Système) qui conduisent au bon déroulement du cas d’utilisation. On parle également de scénario de base, scénario normal. - Scénario alternatif : Partant du scénario nominal, on étudie chaque point de l’enchaînement et s’il existe une variante, on propose « une nouvelle façon de dérouler le cas d’utilisation ». Pour les scénarios alternatifs, on remplit les post-conditions du cas d’utilisation. - Scénario d’exception : Même description que pour le scénario alternatif sauf que les postconditions du cas d’utilisation ne sont pas remplies.

CAS D ’UTILISATION Organiser le travail Le cycle de développement en Y Besoins des utilisateurs Choix techniques Y Recueil des Besoins fonctionnels Recueil des Besoins techniques branche fonctionnelle branche technique Études et prototypages Spécifications Architecture Conception détaillée Réalisation / Codage Tests et recette Livraison et déploiement Construction

CAS D ’UTILISATION Cas d’utilisation « métier » Les cas d’utilisation peuvent être utilisés pour conduire une modélisation « métier »: Un « Business Use Case » représente un processus métier de l’entreprise Les « Business Actors » et « Business Workers » représentent des participants internes ou externes à l’entreprise.

DIAGRAMMES DE CAS D ’UTILISATION Exercice Modéliser un système de type « Lecteur/Enregistreur  Vidéo » ( magnétoscope, DVD R/W, etc.) Identifier et formaliser ses cas d’utilisation

DIAGRAMMES DE CAS D ’UTILISATION Jeu d'échecs Identifier et modéliser des cas d'utilisation du jeu d'échecs. Proposez une stratégie de développement associée Décrivez l'un des cas en utilisant le canevas suivant nom explicite (= label UML) acteurs concernés brève description (entre 3 et 10 lignes) pré-conditions événement déclenchant événement qui cause l ’arrêt Résultats attendus / post-conditions description du flot d ’événements principal interactions avec les acteurs échanges d ’informations (paramètres des interactions) chronologie et origine des informations répétitions de comportement description des flots secondaires et des exceptions contraintes et règles de gestion exigences couvertes

Diagrammes de SEQUENCE Modélisation de scénarii d’utilisation

MODELISATION DES SCENARIOS Place dans le processus de développement Besoins des utilisateurs Modélisation des cas d’utilisation Modélisation « Métier » Maquette IHM Modélisation de conception détaillée Modélisation dynamique Modélisation objet Scénarios d’utilisation Structuration Modélisation de l’architecture Modélisation des interactions Code

MODELISATION DE SCENARIOS Étudier l'usage Comment utilisera-t-on le logiciel ?

MODELISATION DES SCENARIOS Cas d ’utilisation et scénarios Un scénario est une série d ’événements ordonnés dans le temps, simulant une exécution particulière du système. Pour chaque cas d ’utilisation, il existe un ou plusieurs scénarios dont la description permet d ’expliciter le comportement du système pour une situation donnée. Usager Correspondant Appeler un correspondant communication directe ligne occupée sans réponse communication par répondeur ligne en dérangement etc...

MODELISATION DES SCENARIOS Extrait du méta-modèle réalisation * classifier * Classifier (from Core) Instance (from Common Behavior) spécification 1..* * Cas d ’utilisation Acteur Scénario Extension Point : list of String

DIAGRAMMES DE SEQUENCE Généralités Les diagrammes de séquences montrent les interactions entre objets selon un point de vue temporel. temps

MODELISATION DES SCENARIOS Diagramme de séquence « système » Un diagramme de séquence « système » traite le système comme une « boîte noire » représente les interactions entre les acteurs et le système illustre la succession temporelle des événements qui influencent le fonctionnement du système met en évidence les responsabilités élémentaires du système permet de bien délimiter les frontières du système

DIAGRAMMES DE SEQUENCE Exercice Modéliser un scénario d’utilisation du « Lecteur/Enregistreur  Vidéo »