Unified Modeling Language

Slides:



Advertisements
Présentations similaires
Applications N-Tiers Rappels: architecture et méthodologie
Advertisements

Langage de modélisation objet unifié
6 — Aperçu du processus unifié
Génie Logiciel 2 Julie Dugdale
XML - Henry Boccon-Gibod 1 XML, Langage de description La question du choix de formalismes Les entités et leur représentations modalités de modèles et.
Les cas d’utilisation (use cases)
UML - Présentation.
Introduction à UML NFE108 CNAM – LILLE Madame DELECLUSE
UML (Unified Modeling Langage)
Rational Unified Process (RUP)
Langage SysML.
UML : DIAGRAMME DE CAS d’UTILISATION
Présentation SysML (Systems Modeling Language ) est basé sur UML et remplace la modélisation de classes et d'objets par la modélisation de blocs pour un.
FSAB1402: Informatique 2 Techniques de Programmation Orientée Objet
UML : GENERALITES Rappel Diagrammes Niveaux de visions
Modélisation UML Diagrammes de Cas d’utilisation
Réforme de la voie technologique STI
Catherine Letondal Ingénierie Système Analyse des besoins Catherine Letondal 3/12/2010.
Les Cas d’utilisation.
Diagrammes de CAS D’UTILISATION
UML Etude de cas.
Analyse et Conception orientée objet
Réalisée par :Samira RAHALI
UML F. Laperruque INRA – SAGA CATI SICPA.
Modèle, Méthode et Conception
Département de génie logiciel et des TI Université du Québec École de technologie supérieure Systèmes dinformation dans les entreprises Systèmes dinformation.
Modélisation orientée objet UML
Analyse et conception orientée objet
Plan: Rappels Les catégories des méthodes d’analyse et de conception
Etude globale de système.
Unified Modeling Langage
Portée, arrimages et intervenants Évolution des méthodes
Processus d'un projet F.Pfister
Sensibilisation a la modelisation
UML Séquence 3 : (Diagramme d’activités)
Langage de modélisation graphique de systèmes
UML.
Chapitre 2: COMMUNICATION TECHNIQUE
GENIE LOGICIEL Détermination du périmètre cible d’une application
Introduction au langage de modélisation Unifié UML
UML : un peu d’histoire H. Lounis.
Le contenu est basé aux transparents du 7 ème édition de «Software Engineering» de Ian Sommerville«Software Engineering» de Ian Sommerville B.Shishedjiev.
Unified Modeling Langage
Extrait du Referentiel BTS Systèmes numériques Options : Informatique et réseaux et Électronique et communication S1 à S9 Définition des savoirs et savoir-faire.
Management de la qualité
2 Processus de conception de BD
Modélisation des flux Introduction et définition
LOGO 2010/2011 Encadré par: Mr Chaouech Helmi Elaborée par: Galloussi Ons Université de Carthage Faculté des Sciences économique et de Gestion de Nabeul.
Diagrammes des « cas d’utilisation » ou « Use Case »
Hiver 2004SEG2501 Chapître 41 Chapître 4 SDL – structure d’un système et son comportement.
Modélisation orientée objet UML
Chapitre 2 Rappels objet et Présentation des diagrammes UML
Chapitre 2 Rappels objet et Présentation des diagrammes UML
Les cas d’utilisation.
Nouvelles Technologies Internet & Mobile
Les concepts d’UML - Le Processus Unifié -
1 JEE 2010 Architectures n-tiers F.Pfister
UML support à la COO 2ème année IUT Calais-Boulogne Bénédicte Talon
TP D’UML Groupe N° 3.
Conférence 2TUP Stéphane Barthon 03/12/
Cas d’utilisation Une façon de représenter les fonctions d’un système (existant ou prévu) du point de vue utilisateur. Donc pour Cahier des charges Spécifications.
Schéma de base de données Présentation. Conception du schéma logique  Transformation du schéma conceptuel en structures de données supportées par les.
USE CASE Présentation. Technique importante ● Pilotage par cas d'utilisation (use case) ● Spécifications des besoins fonctionnels des acteurs ● Unité.
UML Unified Modeling Language. UML : 8 diagrammes 1.Classes 2.Activités 3.Séquences 4.Collaboration 5.Etats transition 6.Cas d’utilisation 7.Composants.
UML : Unified Modeling Language. Plan ● Introduction ● Diagramme d'activité ● Diagramme de classe.
UML : méthode Processus. Introduction(1) ● Cycles ● Spécification par cas d'utilisation ● Identifier les besoins ● Analyse par cas d'utilisation ● Affiner.
Les cas d’utilisation 420-KE2-LG.
Modélisation fonctionnelle : ETUDE DE CAS. 01 Modélisation fonctionnelle :étude de cas Ce chapitre va nous permettre d’illustrer pas à pas, sur une première.
Transcription de la présentation:

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

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).

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

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.

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.

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

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

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.

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

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.

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

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).

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

é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 …

é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

é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)

é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.