1. Définition d'UML - Free

Analyse et modélisation Objet avec UML
1. Définition d'UML 5 2. Le diagramme de déploiement 12 3. Le diagramme de contexte 13 4. Les cas d'utilisation 14 5. Diagrammes d'instances (ou d'objets) 18 6. Diagramme de classes 19 7. Diagrammes d'activité 28 8. Diagrammes d'interaction, définition des opérations 32 9. Les diagrammes états - transitions 41 10. Diagramme de packages 46 11. Récapitulation 47
Par quoi commencer
même réduit à l'essentiel, UML reste vaste
pour commencer votre 1ère analyse, vous pouvez peut-être vous limiter à
lire
. le chapitre 1 Définition d'UML
. le début du chapitre 4 Les cas d'utilisation, paragraphes 1 et 2
. le début du chapitre 6 Diagramme de classes, paragraphes 1 à 3
. le début du chapitre 7 Diagramme d'activités, paragraphes 1 à 3
. le début du chapitre 9 Diagramme d'états, paragraphes 1 et 2
jetez un coup d'oeil aux chapitres 2 (Diagramme de déploiement) et 5 (Les
diagrammes d'instances) qui sont très courts gardez le reste pour plus tard... Bibliographie pour commencer
pour de bons conseils sur la façon d'utiliser UML
UML2.0, Fowler, Campus Press
UML2 en action, Roques et Vallée, Eyrolles
pour des exercices d'utilisation
UML2 par la pratique, Roques, Eyrolles
pour une présentation plus complète des modèles
Modélisation objet avec UML, Muller et Gaertner, Eyrolles Table détaillée
1. Définition d'UML 5 1.1. Qu'est-ce qu'UML 5 1.2. Objectif et place d'UML dans un projet logiciel 5 1.3. Approche retenue dans le présent support 6 1.4. UML en fait trop 7 1.5. UML ne fait pas tout 7 1.6. Références, outils 7 1.7. Première définition des principaux modèles 8 1.8. L'enchaînement des principaux diagrammes 11 2. Le diagramme de déploiement 12 3. Le diagramme de contexte 13 4. Les cas d'utilisation 14 4.1. Concepts et construction 14 4.2. Documentation 15 4.3. Enrichissements possibles 16 4.4. Rôle et place des cas d'utilisation 16 4.5. Pièges et conseils 17 5. Diagrammes d'instances (ou d'objets) 18 5.1. Concepts et construction 18 5.2. Rôle et place des diagrammes d'instance 18 6. Diagramme de classes 19 6.1. Première définition d'une classe 19 6.2. L'ébauche du diagramme de classes 20
6.2.1. Règles et étapes de construction 20
6.2.1.1. Première définition des associations 21 6.3. Pièges et conseils 22 6.4. L'enrichissement du diagramme de classes 23 6.5. Le diagramme de classes finalisé 23
6.5.1. Finalisation des attributs 24
6.5.2. Compléments sur les associations 24
6.5.2.1. L'agrégation 24
6.5.2.2. Attributs d'associations 25
6.5.2.3. Multiplicités 25
6.5.3. L'héritage 27 6.6. Plusieurs diagrammes de classe 27 7. Diagrammes d'activité 28 7.1. Rôle et place des diagrammes d'activité 28 7.2. Concepts de base du diagramme d'activité 28 7.3. Diagramme d'activité pour représenter un algorithme 29 7.4. Diagramme d'activités à couloirs d'activités 29 7.5. Représentation avec les objets utilisés 30 7.6. Quelques précisions 31
7.6.1. Activité ou état? 31
7.6.2. Synchronisation 31 8. Diagrammes d'interaction, définition des opérations 32 8.1. Deux formes de diagrammes d'interaction 32 8.2. Diagrammes de séquence (scénarios) 33
8.2.1. Premiers concepts et construction 33
8.2.2. Passage des messages aux opérations 35
8.2.2.1. Enrichissement du diagrammes de classes 36
8.2.3. Naissance et disparition d'un objet 36
8.2.4. Documentation des opérations 37 8.3. Diagrammes de collaboration 38 8.4. Pièges et conseils 39
8.4.1. "bons" et "mauvais" scénarios 39
8.4.2. Comparaison de deux solutions plus globales 40 9. Les diagrammes états - transitions 41 9.1. Premiers concepts et construction 41 9.2. La logique et la signification du diagramme d'états 42 9.3. Quelques éléments de modélisation complémentaires 43
9.3.1. Sous-états 43
9.3.2. Condition sur une transition 43
9.3.3. Transition sans changement d'état 43 9.4. Enrichissement du diagramme de classes 44 9.5. Rôle et place des diagrammes d'états 44 9.6. Pièges et conseils 45 10. Diagramme de packages 46 11. Récapitulation 47
Définition d'UML
1 Qu'est-ce qu'UML UML : Unified Modeling Language
né en 1995
définie comme norme par l'OMG (Object Management Group)
UML est une méthode de modélisation:
( UML définit comment représenter visuellement un logiciel
comment dessiner un modèle
et surtout quoi représenter sur chaque modèle ( UML ne définit pas quand ni pourquoi modéliser
cela est le rôle de la méthode de conduite de projet
Version courante: UML2 (adoptée en 2004)
- définit de nouveaux modèles
- apporte quelques améliorations aux modèles existants Extensions: les "profils" sont destinés à adapter UML à un contexte
spécifique
UML Real Time
UML pour les services web
2 Objectif et place d'UML dans un projet logiciel L'objectif et la place d'UML dépendent de la méthode de conduite de projet
adoptée
> à l'extrême la plus ambitieuse, UML modélise tous les détails du futur
logiciel
approche MOA (Model Driven Architecture)
approche actuellement à un stade expérimental
> à l'extrême la plus modeste, UML (s'il est utilisé) ne servira qu'à
clarifier quelques points difficiles du projet
approche du RAD (Rapid Application Development) et des méthodes
"agiles" (par exemple Extreme Programming)
la modélisation, lorsqu'elle est utilisée, est limitée aux
points qui nécessitent une clarification
> dans une approche intermédiaire, UML sert à réaliser le dossier
d'analyse et de conception, sans prétendre modéliser tous les détails
c'est l'approche présentée par exemple dans "UML en action",
mentionné dans la bibliographie
3 Approche retenue dans le présent support C'est la 3ème approche qui est retenue dans le présent support Dans cette approche, on va voir l'utilisation d'UML
- dans l'étude de besoins
- dans l'analyse métier
- dans la conception technique générale (l'architecture)
- dans la conception technique détaillée (les objets)
L'enchaînement des étapes sera probablement définition des termes
étude de besoins
dans l'approche traditionnelle, c'est ce qui aboutit au "cahier des
charges"
dans les approches modernes, c'est ce qui est destiné à formaliser les
besoins et à suivre leur prise en compte et leur évolution
("requirement management") analyse métier (analysis en anglais)
en général
- part de la définition des besoins fonctionnels
- ignore les contraintes techniques et l'environnement d'exécution
en conception objet
- se concentre sur les "objets métier", dits aussi "objets du domain"
- ignore les objets techniques (objets applicatifs, objets d'IHM, etc.)
La conception technique
conception technique générale (system design en anglais)
définit les choix d'architecture: langage(s) utilisé(s), bases de
données, protocoles réseau, répartition physique du logiciel, choix
d'outils d'implémentation ...
conception technique détaillée (object design en anglais)
détaille l'implémentation des objets métier
ajoute les objets techniques 4 UML en fait trop L'objectif d'UML est d'aller jusqu'à la génération du code (MDA, vu plus
haut) et de couvrir tous les types de projets logiciels
UML propose 9 types de diagrammes
UML2 en propose 13 ( il y a plus de modèles dans UML que ce qui est nécessaire dans la plupart
des projets l'objectif n'est pas d'utiliser tous les modèles mais de choisir ceux qui
sont utiles selon le type de projet 5 UML ne fait pas tout UML concerne seulement la modélisation, on l'a déjà dit; mais UML ne
contient pas tous les modèles qui peuvent être utiles
par exemple
. UML ne donne aucun outil pour modéliser une Interface Homme-Machine (le
dessin des pages ou des écrans de l'IHM, et surtout leur enchaînement -
la cinématique de l'IHM)
. la représentation d'un document XML sous forme d'un arbre d'objets UML
est bien moins lisible que sous la forme proposée par Altova (XMLSpy)
. la représentation des données peut être plus lisible en modèle entités-
associations (le modèle conceptuel de Merise) qu'en modèle relationnel
. la représentation d'un processus est plus riche dans les modélisations
spécialisées (BPMN, BPSS...) qu'en UML UML n'interdit pas d'utiliser d'autres modèles en complément.
6 Références, outils
Si l'on veut mieux comprendre UMl, on peut en étudier les ancêtres :
OMT: Object Modeling Technique (Rumbaugh)
Booch
Objectory ou OOSE (Jacobson)
UML est né de la fusion de ces 3 méthodes et s'est inspirée de beaucoup
d'autres (Schlaer et Mellor, Coad et Yourdon...)
Quelques AGLs de conception objet
et aussi les plugins des outils de développement
(en particulier Eclipse) 7 Première définition des principaux modèles
Sur les 13 types de diagrammes, 8 ou 9 au maximum sont importants dans
l'immédiat Il y a beaucoup e choses dans la norme UML, mais, selon les pères de la
méthode eux-mêmes, on peut analyser 80% des problèmes avec 20% de la norme
Ce sont ces 20% qui sont détaillés ici; le reste est seulement mentionné en
conclusion ( voir le cours "UML avancé" ) 1. Cas d'utilisation
[pic] décrit les interactions entre le