UML
Unified Method Language
Langage de modélisation pour la
Conception Orientée Objet
Introduction – Historique – Grands Principes
Analyse, Conception et Ingénierie
Diagrammes Structurels (vue statique)
Diagrammes Comportementaux (vue dynamique) Conclusion
Introduction
UML est un Langage de modélisation permettant de décrire un projet et ses
composantsà la fois d’un point de vue statiqueet d’un point de vue dynamique.
Il est issu de diverses méthodes d’analyse et de conception Orientée Objet
Rumbaugh (OMT)
Booch (OOD)
Jacobson (OOSE)
Plusieurs méthodes d’analyse et de conception entre 1988 et 1996:
Sally Shlaer et Steve Mellor: 2 ouvrages sur analyse et conception (1989 et 1991)
Peter Coad et Ed. Yourdon: approches « orientées prototypes » (1991,1993 et 1995) Conception pilotée par responsabilités
(communautée smalltalk 1990) et cartes CRC (Class-Responsability-Collaboration) (1989)
Grady Booch (Rational software) développement de systèmes en ADA (1994, 1996)
Jim Rumbaugh (laboratoires de recherche
General Electric) travaille sur OMT (Object
Modeling Technique) (1991 et 1996)
Ivar Jacobson (communicateurs téléphonique Ericsson) introduit le concept
de cas d’utilisation (use case) (1992 et
1995)
Conférence OOPSLA’94 : Grand clivage entre les différentes communautés mais idée d’une standardisation
1994 Jim Rumbaugh quitte G.E. pour rejoindre Grady Booch chez Rational Software pour fusionner leurs méthodes.
OOPSLA’95 version 0.8 de la méthode unifiée 1995 Ivar Jacobson rejoint l’équipe.
OOPSLA’96 Présentation d’UML
1996 Mise en place d’un groupe de travail par l’OMG (Object Management Group)
1997 Soummision d’UML 1.0 à l’OMG
1999 UML 1.3 est rendu publique
2000 publication de la spécification complète
Semestre Automne
2005 LO43 UML - Franck Gechter 11
Langage visuel de modélisation
Exploitable par des méthodes d’Analyse et de Conception différentes
Adapté à toutes les phases du développement
Compatible avec toutes les techniques de réalisation
Indépendant des langages de programmation
Base formelle pour la compréhension du langage
Encourage l’utilisation de la conception orientée objet
Supporte les concepts de développement de haut niveau: patterns, composants, frameworks.
Différentes façon de représenter un système :
Point de vue dynamique
Point de vue statique
En UML cela se traduit par 9 principaux digrammes:
5 diagrammes structurels (point de vue statique)
4 diagrammes comportementaux (point de vue
dynamique)
Diagramme de Cas d’utilisation (use case)
Diagramme de classes
Diagramme d’objets
Diagramme de composants
Diagramme de Déploiement
Diagramme de Séquences
Diagramme d’Activités (États - Actions)
Diagramme d’États – Transitions
Diagramme de Collaboration
Semestre Automne
2005 LO43 UML - Franck Gechter 16
|
|
Implémentation
Diagramme des cas d’utilisation: décrit les fonctions du système selon le point de vue des utilisateurs (Jacobson)
Diagramme de séquence:
représentation temporelles des
interactions entre les objets (point de vue de l’IHM)
Diagramme des classes: structure des données du système définie comme une ensemble de relation entre classes (association, composition, agrégation, spécialisation, implémentation,…)
Diagramme d’objets: illustration macroscopique des objets et des relations qui les lient.
Diagramme de collaboration: représentation des interactions entre les objets.
Diagramme États-Transitions: comportement des objets d’une classe (états possibles et transitions entre ces états)
Diagramme d’activités: structure temporelle d’une activité d’un objet
Diagramme de séquence: représentation temporelle des interactions entre objets pour une opération donnée
Diagramme de déploiement: description de la répartition des composants (objets) sur la structure matérielle cible
Diagramme de composants: architecture des composants physiques d’un application
Semestre Automne
2005 LO43 UML - Franck Gechter 21
Semestre Automne
2005 LO43 UML - Franck Gechter 22
Analyse des besoins:
Compréhension des besoins à couvrir par le logiciel Formalisation de ces besoins
Représentation des besoins:
Use cases + scénarii : utilisation du logiciel par les acteurs
Diagrammes de classe/objets : structure du système
Diagramme de collaboration : interactions entre les éléments du système (acteurs et composants)
Un système est conçu pour des utilisateurs
Use cases
Description des comportements du système vis-àvis de l’utilisateur
Facilitent structuration des besoins
Représentation simple et expressive
Expriment les limites et les objectifs du système Simplifient les échanges avec le rédacteur du cahier des charges
C’est la représentation d’une fonctionnalité, réponse d’une stimulation de l’utilisateur
Acteur:
Entité externe qui interagit avec le système
Prend des décisions
Possède un rôle vis-à-vis du système
Il peut être un utilisateur et/ou un autre système
Acteur ? Utilisateur
Un utilisateur peut jouer plusieurs rôles
Plusieurs utilisateurs peuvent jouer un même rôle
Un acteur peut être un autre système
Cas d’utilisation:
Ensemble des actions réalisés par le système en réponse à une action donnée
Suite d’interaction entre acteurs et système Correspond à une fonction visible à l’utilisateur
Formalisation l’obtention d’un objectif Les cas d’utilisation doivent être mutuellement exclusifs
Donner les différents cas d’utilisation des différents acteurs d’une banque
Ne correspondent pas à des communications entre les cas.
Permettent une structuration des cas d’utilisation
Utilisation d’un autre cas (usesou include):
permet l’extraction d’un comportement commun à plusieurs cas d’utilisations (exemple: donner sont code de carte bleu à un GAB)
Semestre Automne
2005 LO43 UML - Franck Gechter 30
Le système correspond à l’ensemble des use cases sans les acteurs
Un use case = un chemin d’exécution possible
Un scénario =
un chemin particulier d’exécution une séquence d’événements / instructions.
instance des cas d’utilisation
Il s’agit en général d’un descriptif sous forme de texte des actions à effectuer pour un cas d’utilisation donné Il peut être décomposé en plusieurs sous scénarii:
L’un correspondant au scénario optimal
Les autres correspondants aux alternatifs
(tests d’erreurs, mauvais renseignements,
…)
Semestre Automne 2005 LO43 UML - Franck Gechter 32
Détaillez le scénario correspondant à un retrait d’argent dans un GAB
Semestre Automne
2005 LO43 UML - Franck Gechter 34
Une classe est une description abstraite permettant de définir des objets ayant:
Des propriétés,
Des comportements,
Des relations,
Des sémantiques…
…Communes
| ||||
Les différents champs, hormis le nom, sont optionnels
| Nom de la classe | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Nom attribut : type = valeur initiale • Chaque nom est unique • La valeur de l’attribut dépend de chaque objet Exemple
Les méthodes
Propriétés d’accessibilité des attributs et des méthodesOn retrouve les trois niveaux de protections classiques: Privé (-) Protégé (#) Publique (+) Les attributs dérivésUn attribut dérivé permet d’indiquer clairement qu’un attribut découle d’autres propriétés (exemple: la surface d’un rectangle dépend de sa largeur et de sa longueur) Il sont noté /nom attribut et ont des valeurs calculées à partir des autres attributs Exemple
Analyse Conception Relation entre les classesAssociation Agrégation Composition Spécialisation Les associationsReprésente une association structurelle entre 2 classes. Ces associations peuvent être nommées. Elles peuvent également posséder des cardinalités Les associations
Les associationsToute association binaire possède 2 rôles. Un rôle définit la manière dont une classe intervient dans une relation. Attention: Lorsqu’il y a trop d’associations entre deux classes c’est suspect… Les associations
Cardinalité et multiplicité des associationsLa cardinalité est une information qui quantifie le nombre nécessaire de fois pour la participation d’un objet à une instance. Cardinalité et multiplicité des associations Exemple:
Les associations réflexivesLes contraintes sur les associationsContraintes qui portent sur une relation ou un groupe de relation (en général mise entre accolades {}) Contraintes de sous ensemble: Collection incluse dans une autre collection Une association parmi un groupe d’associations est possible Les contraintes sur les associations
Délégués des élèves * * AgrégationUne agrégation est une relation non symétrique. Cette relation est à mettre en rapport avec la notion d’agrégation que nous avons vu en C++ Cas d’utilisation : Une classe B « fait partie » d’une classe A Les valeurs d’attributs de la classe B se propagent dans A Une action sur A implique une action sur B Les objets de B sont subordonnés aux objets de A Il suffit que l’un de ces critère soit vérifié Agrégation exemple• Une agrégation peut avoir une cardinalité • Une agrégation peut également avoir un rôle CompositionC’est un cas particulier d’agrégation Peut être modélisée au moyen d’attributs. Le composant est physiquement présent dans l’agrégat Implique une contrainte sur la valeur de cardinalité coté agrégat (0 ou 1) 0 implique un attribut non renseigné La composition doit être retenue lorsqu’un attribut participe à la relation | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| - Moteur | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
La relation de généralisation – spécialisation est une sorte d’héritage public comme on l’a vu en C++.
Cette relation peut contenir des contraintes:
Selon plusieurs critères (véhicule motorisation ou véhicule milieu)
Inclusif ou exclusif
Exemple de spécialisation : relation entre
Association, Agrégation et Composition
Semestre Automne
2005 LO43 UML - Franck Gechter 59
Liens structurels entre les instances des classes des projets.
Facilite la compréhension de structures complexes On peut représenter les instances de trois façons:
| Nom de l’objet | Nom de l’objet:Nom de Classe |
:Nom de Classe
| Semestre Automne 2005 | LO43 UML - Franck Gechter | 60 |
Les objets composés d’autre objets peuvent être visualisés
Les valeurs des attributs sont optionnels
Les valeurs des liens sont optionnels
Les liens réflexifs des diagrammes de classes peuvent être explicités en terme d’instances
Les liens de cardinalité supérieur à deux peuvent être représentés de la façon suivantes
Semestre Automne 2005 LO43 UML - Franck Gechter 61
Semestre Automne
2005 LO43 UML - Franck Gechter 62
2005 LO43 UML - Franck Gechter 63
Modélisation des interactions entre les différents objets suite à un événement externe au système.
Mise en place d’un aspect temporel
Synchrone: l’émetteur de la requête est bloqué jusqu’à la fin du traitement
Asynchrone: l’émetteur peut poursuivre son exécution.
Il est possible d’effectuer des échanges conditionnels
On peut matérialiser la création et la destruction d’objets
|
|
Message synchrone Message asynchrone
| :A | :B | :C |
Utilisation d’un téléphone pour la communication entre deux personnes
Semestre Automne
2005 LO43 UML - Franck Gechter 68
Décrit le comportement des objets d’une classe au moyen d’un automate à états finis.
Comportement d’un objet = graphe
Nœuds états de l’objet: étape dans le cycle de vie d’un objet.
• Satisfait certaines conditions
• Réalisation potentiel de certaines actions
• Attente d’événements.
Arc Transitions entre états: exécution d’une action ou réaction de l’objet
Chaque objet est dans un état particulier à un instant donné.
Chaque état est identifié par un nom
Chaque diagramme d’état transition comprend:
Un état initial unique pour un niveau de hiérarchie donné.
Des états intermédiaires
Éventuellement un (ou plusieurs) état final (finaux) (un système ne s’arrêtant pas, n’a pas d’état final)
Transitions
Les transitions sont unidirectionnelles
Le diagramme d’état transition est un graphe orienté
Événements
Un événement correspond à l’occurrence d’une situation donnée
L’événement est déclencheur de la transition interétat
Les événements peuvent être conditionnels
Semestre Automne
2005 LO43 UML - Franck Gechter 74
C’est une variante des diagrammes étatstransition.
Mets l’accent sur les activités, leurs relations et leurs impacts sur les objets.
Une activité mets en œuvre un ou plusieurs objets.
Les transitions entre activités peuvent être conditionnées par des expressions booléennes.
On peut éventuellement synchroniser deux activités déclenchés par la même transition
On peut également démarrer une activité en synchronisant l’achèvement de deux autres.
Tous les diagrammes ne sont pas nécessaire pour chaque projet.
Ils servent à illustrer et détailler des éléments du projet.
L’étape d’analyse et de conception se fait toujours avant l’implémentation.
Cours de Frédéric Julliard - Université de Bretagne
Sud
UML Martin Fowler – CampusPress 2002
Cours de Jacques Lonchamp(rubrique enseignement):
