Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

UML (Introduction) Unified Modeling Language Pr. BENHADOU 3 Genèse d’UML • UML

UML (Introduction) Unified Modeling Language Pr. BENHADOU 3 Genèse d’UML • UML est le fruit de l’unification de 3 méthodes de modélisation orientées objet – OMT (Object Modeling Technique) : James Rumbaugh – Booch : Grady Booch – OOSE (Object Oriented Software Engineering) : Ivar Jacobson • UML est le fruit d’un consensus général – élaboré avec le concours de la communauté des utilisateurs • UML est une notation (relativement) simple et non propriétaire – standardisé par l’OMG (Object Management Group) 4 Genèse d’UML Autres méthodes Booch’91 OMT -1 OOSE Partenaires OMG UML 1.0 - 1997 (Q1) UML 0.9 - 1996 OMT -2 Booch’93 - 1993 Méthode unifiée 0.8 - 1995 UML 1.1 - 1997(Q4) UML 1.3 - 1999 - 2002 UML 2.0 5 UML est une notation • UML est un langage de modélisation objet – 9 diagrammes standardisés (facettes complémentaires d’un système) – Support des phases d’Analyse et de Conception orientée objet • UML est un langage de communication – utilisation d’un même formalisme par tous les intervenants – permet de lever les ambiguïtés du langage naturel • UML est un langage simple de haut niveau – facile à appréhender car visuel – indépendant de tout langage de programmation 9 Plusieurs axes de modélisation • Axe structurel – modélisation statique du système – quels objets manipule le système ? – détermination du QUOI • Axe comportemental / dynamique – modélisation dynamique du système – sous quelles conditions agit le système ? – détermination du QUAND • Axe fonctionnel – modélisation des traitements offerts par le système – que fait le système ? – détermination du COMMENT 10 Les diagrammes proposés par UML • Système (contextuel) – Diagramme de cas d’utilisation • Système (architecture) – Diagrammes de composants – Diagrammes de déploiement • Structurels – Diagramme de packages – Diagramme de classes – Diagramme d’objets • Dynamiques – Diagramme de collaboration – Diagramme de séquence – Diagramme d’états • Fonctionnels – Diagramme d’activités UML (Cas d’utilisation) Unified Modeling Language 14 Cas d’utilisation (Use Cases) Objectifs • Définir les besoins fonctionnels du système Les cas d’utilisation ont pour principal objectif la capture des fonctionnalités couvertes par le système • Définir le périmètre fonctionnel du système Les cas d’utilisation permettent de définir les frontières du système avec son environnement • Définir le dialogue entre l’utilisateur et le système Les cas d’utilisation recensent comment l’utilisateur interagit avec le système 15 Cas d’utilisation (Use Cases) Objectifs (suite) • Etablir les scénarios fonctionnels qui seront utilisés pour la recette du système Les cas d’utilisation recensent et décrivent les principales fonctionnalités attendues du système • Servir de support de référence tout au long des phases de développement du système Les cas d’utilisation seront consultés et référencés tout au long du processus de développement du système 16 Cas d’utilisation • Une interaction en provenance de l’extérieur déclenche un flot de contrôle (séquence d’activités) au sein du système Déposer argent Retirer argent • Pendant l’exécution de ce flot de contrôle, plusieurs interactions avec son initiateur peuvent avoir lieu • Chaque flot de contrôle correspond à une fonctionnalité ou un processus fonctionnel attendu du système 18 Cas d’utilisation (Notation) Notation • Un cas d’utilisation est représenté par un ovale • Le nom du cas d’utilisation apparaît à l’intérieur de l’ovale. Il est composé : - d’un nom optionnel de paquetage - du nom de la fonctionnalité qu’il prend en charge DAB::Retirer argent 19 1. Introduire la carte 2. Taper le code 3. … Description d’un cas d’utilisation • Titre (commence par un verbe) • Objectif (descriptif court : une phrase si possible) • Acteurs • Pré-conditions – conditions nécessaires pour que le cas d’utilisation s’exécute • Scénario nominal – description pas à pas textuelle – chaque étape du cas d’utilisation est numérotée • Exceptions • Post-conditions – état d’une partie du système après l’exécution du cas d’utilisation • Fréquence & performance requises 21 Acteur (Définition) • L’acteur est à l’origine des événements initiateurs reçus par le système • L’acteur dialogue par la suite avec le cas d’utilisation dont il est l’initiateur • L’ acteur possède un nom : celui du rôle qu’il joue lors de son interaction avec le système • L’acteur n’est pas forcément humain. Il peut s’agir : – d’un autre système – d’un équipement Un acteur définit un rôle qu’une entité extérieure assume lors de son interaction avec le système 23 Acteur (Notation) Notation • Un acteur est représenté par un petit personnage • Le nom de l’acteur apparaît sous le petit personnage • On peut définir des catégories d’acteurs plus générales ou au contraire spécialiser un type d’acteur Utilisateur Utilisateur externe Utilisateur interne 24 Comment déterminer les acteurs Se poser les questions suivantes : • Qui installe le système ? • Qui utilise le système ? • Qui démarre le système ? • Qui maintient le système? • Quels sont les autres systèmes qui utilisent le système ? • Qui fournit de l’information au système ? • Qui récupère de l’information à partir du système ? • … 25 Diagramme de cas d’utilisation (Définition) • Permet de définir de manière précise les frontières du système à modéliser • Montre les interactions entre le système et son environnement extérieur • Montre les dépendances existant entre les cas d’utilisation Le diagramme de cas d’utilisation est une représentation contextuelle de haut niveau du système modélisé 26 Notation Diagramme de cas d’utilisation (Notation) Cas d’utilisation 1 Cas d’utilisation 2 Cas d’utilisation 3 Acteur 1 Acteur 2 Le diagramme de cas d’utilisation met en scène : - les acteurs - les cas d’utilisation - les interactions entre acteurs et cas d’utilisation - les dépendances entre cas d’utilisation 28 Dépendances entre cas d’utilisation Il existe 3 types de dépendances entre use cases : • Les dépendances d’utilisation Mise en facteur de séquences d’événement communes • Les dépendances d’extension Externalisation de séquences d’événement exceptionnelles • Les dépendances de généralisation Généralisation / spécialisation de cas d’utilisation 29 Dépendance d’utilisation Cas d’utilisation 2 « include » Authentifier carte • Indique qu’un cas d’utilisation utilise systématiquement et intégralement une séquence d’activités décrite dans un autre cas d’utilisation • Est représentée par une flèche pointillée étiquetée « include », pointant vers le cas d’utilisation utilisé Cas d’utilisation 1 Cas d’utilisation 2 Acteur 1 « include » Le cas d’utilisation 1 utilise systématiquement le cas d’utilisation 2 Notation 31 « include » Authentifier carte Retirer argent Client « include » Déposer argent Dépendance d’utilisation Cas d’utilisation 2 Acteur 1 « include » « include » Déposer argent Authentifier carte Retirer argent Client Déposer argent • Permet de décomposer un cas d’utilisation complexe en cas d’utilisation plus simples • Permet de factoriser des comportements utiles à plusieurs cas d’utilisation 32 Dépendance d’extension • Indique qu’un cas d’utilisation utilise facultativement ou sous certaines conditions une séquence d’activités décrite dans un autre cas d’utilisation • Est représentée par une flèche pointillée étiquetée « extend », pointant vers le cas d’utilisation étendu Cas d’utilisation 2 Cas d’utilisation 2 Utilisateur « extend » Le cas d’utilisation 2 est une extension du cas d’utilisation 1 Notation Cas d’utilisation 1 33 Dépendance d’extension • Le cas d’utilisation étendu contient une liste de points d’extension • Un point d’extension est composé d’un nom suivi d’un numéro d’étape (emplacement) • Le cas d’utilisation qui étend indique dans sa description sous quelles conditions il se déclenche Cas d’utilisation 2 Cas d’utilisation 1 Points d’extension : . point extension1 : emplacement1 . point extension2 : emplacement2 Cas d’utilisation 2 Utilisateur « extend » Notation Condition de déclenchement Au point « point extension1 » : • Etape1 • Etape2 • … 34 Dépendance d’extension • Permet d’ajouter à un cas d’utilisation un comportement exceptionnel complexe (hors cas nominal) • Détermine les conditions d’application d’un comportement alternatif au cas nominal • Déporte la description d’une exception significative dans un cas d’utilisation Cas d’utilisation 2 « include » Authentifier carte Traiter authentification incorrecte Client « extend » Si le code fourni est incorrect Au point « Carte invalide » : 1. Alerter le client 2. Redemander la saisie du code 3. … Retirer argent Points d’extension : . Guichet vide : avant étape 1 . Carte invalide : avant étape 2 35 Dépendance d’extension •Titre •Résumé (une phrase) •Acteurs •Pré-conditions •Scénario nominal •Exceptions •Post-conditions .Exceptions • Un comportement exceptionnel complexe d’un cas d’utilisation doit être déporté dans un cas d’utilisation avec une dépendance « extend » • Un comportement exceptionnel simple doit être explicité dans le paragraphe « Exceptions » de la description du cas d’utilisation Retirer argent Points d’extension : . Guichet vide : avant étape 1 Traiter authentification incorrecte « extend » . Carte invalide : avant étape 2 36 Dépendance de généralisation Cas d’utilisation 2 « include » Authentifier carte • Indique qu’un cas d’utilisation est une spécialisation d’un autre cas d’utilisation • Est représentée par une flèche « d’héritage » pointant du cas d’utilisation spécialisé vers le cas d’utilisation le plus général Cas d’utilisation 1 Cas d’utilisation 2 Acteur 1 Le cas d’utilisation 2 est une uploads/Management/ cours-uml-support1-pdf.pdf