Unified Modeling Language

Présentation au sujet: "Unified Modeling Language"— Transcription de la présentation:

1 Unified Modeling Language
UML (Introduction) Unified Modeling Language Mr Omar ASKANDER

2 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) Dans la première moitié des années 90, il existe une prolifération de méthodes orientées objet. A cette époque, seules quelques méthodes se dégagent du lot. Partant de la constatation que les concepts véhiculés par ces différentes méthodes sont très proches, une volonté d’unification apparaît. UML est né de cette volonté d’unification. Il est issu de l’intégration de la méthode généraliste OMT (qui apportent la majeure partie des concepts objets, classes, associations, modèles d’état, …) ; de la méthode Booch plus orientée Conception ; de la méthode OOSE à laquelle il emprunte le concept des cas d’utilisation indispensables en amont du cycle de vie de développement logiciel (expression des besoins). UML n’est pas une notation propriétaire bien au contraire il a pour vocation d’être implémentée par de nombreux fabricants d’outils. C’est aussi une notation standardisée puisque fin 1997, il est devenu une norme OMG (Object Management Group).

3 Genèse d’UML - 2002 - 1999 - 1997(Q4) - 1997 (Q1) - 1996 - 1995 - 1993
Méthode unifiée 0.8 - 1995 OMT-2 Booch’93 - 1993 Autres méthodes Booch’91 OMT-1 OOSE Partenaires OMG

4 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 UML est un langage ouvert possibilité d’ajouter des notes (texte) utilisation de stéréotypes permettant d’étendre la notation, améliorant ainsi la sémantique des éléments modélisés Avant tout l’objectif est de modéliser un problème. Le paradigme retenu est le paradigme objet. Pour cela on a à notre disposition 9 diagrammes standardisés permettant de décrire un système sous différentes facettes complémentaires. UML propose un cadre pour l’Analyse et la Conception orientée objet. UML a aussi un rôle d’unificateur du discours sur un projet. Tout le monde parle le même langage sans ambiguïté. UML est aussi un langage manipulant des concepts simples, graphiques (un schéma vaut mieux que de longs discours) et indépendant des langages de programmation ce qui le situe à un niveau d’abstraction plus élevé. Cette indépendance garantit aussi la portabilité et la réutilisabilité des modèles UML.

5 UML n’est pas une méthode
UML n’est pas une méthode, ce n’est qu’une notation attente de la part des utilisateurs d’une normalisation du formalisme définir un processus de développement logiciel universel est illusoire UML est indépendant de toute démarche ce qui en fait un langage universel mais favorise la mise en œuvre d’un processus itératif et incrémental, fondé sur les cas d’utilisation et centré sur l’architecture Mais attention, Unified Modeling Language n’est qu’une notation, un langage de modélisation objet comme l’indique son nom. Les auteurs d’UML ont souhaité dans un premier temps se concentrer sur un langage commun facilitant les interactions entre les différents intervenants lors du développement d’un logiciel.

6 Partie I : Modélisation fonctionnelle
Plan Du Cours Partie I : Modélisation fonctionnelle Partie II : Modélisation Statique Partie III : Modélisation Dynamique Partie IV : La Conception

7 Modélisation fonctionnelle:
Partie I : Modélisation fonctionnelle: Acteur Cas d’utilisation Scénario

8 Modélisation fonctionnelle
Principes & Définitions 1/ Acteur : 1.1 Définition : un acteur représente un rôle joué par une entité externe. Il peut être Humain, ou non Humain (Dispositif matériel ou autre système) Un Acteur peut consulter et/ou modifier directement l’état du système, en émettant et/ou recevant des messages susceptibles d’être porteurs de données.

9 Modélisation fonctionnelle
1.2 Identification : Acteur Humain : toutes personnes qui intervienne dans le cas étudié Acteur Non Humain : Touts dispositifs ou système susceptibles de participer au système étudié 1.3 Représentation : On utilise l’icône appelée en UML stick man avec le nom de l’acteur sous le dessin. Pour les Acteurs non Humain on utilisera une forme rectangulaire avec le mot clé en haut « ACTOR » Client

10 Modélisation fonctionnelle
2/ Cas d’Utilisation: (Use Case) 2.1 Définition : Chaque cas d’utilisation Représente un ensemble d’actions qui sont réalisées par le système et qui produisent un résultat observable intéressant pour un acteur donnée. C’est un comportement attendu du système. Il permet de décrire ce que le futur système devra faire, sans spécifier comment il le fera.

11 Modélisation fonctionnelle
2.2 Identification : Chaque cas d’utilisation correspondant à une fonction métier du système L’ensemble des cas d’utilisation doit décrire les exigences fonctionnelles du système. 2.3 Représentation : Le Diagramme de Cas d’utilisation est un schéma qui montre les cas d’utilisation (ovales) reliés par des associations(ligne) à leurs acteurs (stick man ou représentations graphiques) On utilise l’icône appelée Acteur Humain

12 Modélisation fonctionnelle
3/ Scénario: 3.1 Définition : Un scénario représente une succession particulière d’enchaînements,s’exécutant du début à la fin du cas d’utilisation, un enchaînement étant l’unité de description de séquences d’actions. un Cas d’utilisation contient : Un scénario nominal Des scénarios alternatifs (qui se terminent de façon normale) Des scénarios d’erreur (qui se terminent en échec).

13 Scénario 3.3 Représentation : Erreur Fin Normale Début Enchaînements

14 étude de Cas : GAB GAB : Guichet automatique de Banque offres les services suivants : 1/ Distribution d’argent a tout porteur de carte banc aire via un lecteur et un distributeur de billets. 2/ Consultation de solde de compte et autres services. A retenir : 3/ Toutes les transactions sont sécurisées. 4/ il est parfois nécessaire de recharger le distributeur …

15 étude de Cas : GAB EXRCICE 1 : ACTEURS Dans cet exercice on est appelle à identifier les entités externes qui réagissent directement avec le GAB. T.A.F : 1.1 Identifier les acteurs du GAB. 1.2 Identifier les acteurs principaux et les acteurs secondaires 1.3 élaborer le digramme correspondant

16 étude de Cas : GAB EXRCICE 2 : CAS D’ UTILISATIONS En reprenant les acteurs dégagés de l’exercice 1 lister les différentes façons qu’ils ont pour utiliser le GAB. T.A.F : décrivez la partie obligatoire du cas utilisation RETIRER DE LARGENT (pour acteur non client de la banque)

17 étude de Cas : GAB Extraire de l’exercice précédant :
EXRCICE 3 : SCENARIO Extraire de l’exercice précédant : les enchaînements alternatifs les enchaînements d’erreur.