Vous êtes sur la page 1sur 90

Analyse et

conception UML

Dr. MOUSSE Ange Mikaël


Enseignant-Chercheur à l’Univiersité de Parakou
Mikael.mousse@univ-parakou.bj
La problématique du logiciel

 Complexité des logiciels à développer:


– La problématique du domaine
– Le processus de développement
– L’inhérente flexibilité du logiciel
=> Besoin de modéliser, de comprendre, …
 Les tendances

– L’utilisation du paradigme objet : anticipation à l’évolution


– Génération des programmes sur la base de modèles
– Micro-architectures (design patterns)
– L’informatique distribuée et les architectures J2EE/.Net

Module UV
Analyse et
Conception UML
Page 2 / 90
Agenda

 Brève histoire d’UML (Unified Modeling Language)


 Appréhender la notion d’objet/classe
 Les nouveaux processus de développement unifiés
 Présentation des neufs diagrammes UML
– Diagrammes et vues
– Guide méthodologique
– Exemples
 Problématique et étude de cas.

Module UV
Analyse et
Conception UML
Page 3 / 90
Histoire d’Unified Modeling Language

 L’approche « orienté-objet » a 40 ans


– 1966 Une idée à Oslo
– 1969 La recherche au PARC (Xerox)
– 1980 Version industrielle de Smalltalk
– 1986 1200 personnes pour OOPSLA’86
– 1996 Omniprésence des solutions objets
– 2006 Stabilisation de la transition vers l’objet
 Une notation unifiée issue des travaux de G. Booch, J.
Rumbaugh et I. Jacobson
 Soumise à l’OMG en janvier 1997 et acceptée en Nov. 2001
 Actuellement version 1.5 d’UML validée par l’OMG
 La version 2.0 d’UML est en cours de finalisation par l’OMG.

Module UV
Analyse et
Conception UML
Page 4 / 90
Histoire d’UML

 Approche fonctionnelle : diviser pour régner


 La fonction donne la forme du système

Module UV
Analyse et
Conception UML
Page 5 / 90
Histoire d’UML

 Approche objet
– Les objets sont des entités autonomes, qui collaborent afin
de réaliser des services globaux, devant être rendus par le
système.
– Les objets sont proches du monde réel
– Dégager des concepts et des familles d’entités

Module UV
Analyse et
Conception UML
Page 6 / 90
Histoire d’UML

 La fonction (au sens service) est réalisée par des


objets qui collaborent.
3: Ouvrir
Porte
Cabine

1: Aller au RDC

Lumière Bouton

2: Clignoter

Module UV
Analyse et
Conception UML
Page 7 / 90
Histoire d’UML

 Conclusion sur la complexité des logiciels:


– Le logiciel est complexe par nature
– Il faut gérer cette complexité
– Les systèmes peuvent être décomposés selon ce qu’ils font
et/ou selon ce qu’ils sont : changement de point de vue!
– L’approche objet apporte une réponse plus efficace au
problème de la complexité que l’approche fonctionnelle
• Réutilisabilité, Evolutivité, Stabilité, Extensibilité

Module UV
Analyse et
Conception UML
Page 8 / 90
Définir UML

 UML est une notation, pas une méthode


 UML est un langage de modélisation objet
 UML convient pour toutes les méthodes objet
 UML est dans le domaine public

UML est la notation pour


documenter les modèles objets

Module UV
Analyse et
Conception UML
Page 9 / 90
Le chaos des objets

 Le monde qui nous entoure est constitué de très


nombreux objets en constante interaction : le chaos.
 Pour comprendre le monde, l’être humain a tendance
à regrouper les éléments qui se ressemblent :
– Regrouper des objets suivant des critères de ressemblance
s’appelle classer
– Les humains ont classé les animaux, les plantes, les
champignons, les atomes, ...
– Les informaticiens classent des « objets informatiques »,
ayant des propriétés et des comportements analogues

Module UV
Analyse et
Conception UML
Page 10 / 90
Caractéristiques fondamentales des objets

 Un objet est caractérisé par deux notions


fondamentales :
– L’état
– Le comportement

Module UV
Analyse et
Conception UML
Page 11 / 90
L’état d’un objet

 L’état regroupe les valeurs instantanées de


l’ensemble des attributs d’un objet.
 L’état évolue au cours du temps.
 L’état d’un objet à un instant donné est la
conséquence de ses comportements passés.

Module UV
Analyse et
Conception UML
Page 12 / 90
Exemples de caractérisation de l’état

 Pour un signal électrique : l’amplitude, la pulsation,


la phase, ...
 Pour une voiture : la marque, la puissance, la
couleur, le nombre de places assises, ...

Module UV
Analyse et
Conception UML
Page 13 / 90
Exemple d’évolution de l’état

Une voiture Une voiture


30 litres
Bleu

979 kg
Après un parcours
de 100 Km 12 CV

Une voiture
20 litres

Module UV
Analyse et
Conception UML
Page 14 / 90
Le comportement d’un objet (1/3)

 Le comportement décrit les actions et les


réactions d’un objet.
 Le comportement regroupe toutes les
compétences d’un objet.
 Le comportement se représente sous la forme
d’opérations ou de services.

Module UV
Analyse et
Conception UML
Page 15 / 90
Le comportement d’un objet (2/3)

 Un objet peut faire appel aux


compétences d’un autre objet

Un autre objet
Un message

Un objet
Opération 1
Opération 2 {...}
{...}

Module UV
Analyse et
Conception UML
Page 16 / 90
Le comportement d’un objet (3/3)

 L’état et le comportement sont liés


– Le comportement dépend de l’état
– L’état est modifié par le comportement

: Avion
En vol

Atterrir

Décoller : Avion
: Tour de contrôle Au sol

Module UV
Analyse et
Conception UML
Page 17 / 90
Les processus de développement

 De nombreux processus de développement existent à


l’heure actuelle et doivent être adaptés au contexte du
projet et de l’Entreprise.
 Chaque processus apporte sa propre méthodologie.
 UML est une notation qui doit s’accompagner d’une
méthodologie.
 Des travaux d’unification des processus voient le jour :
– Le Rational Unified Process (RUP)
– L’eXtreme Programming (XP)
– Le Two Track Unified Process (TTUP, 2TUP)
Module UV
Analyse et
Conception UML
Page 18 / 90
Le Two Track Unified Process : cycle en Y

Gestion de la
complexité
technologique

Spécification
fonctionnelles
prototype
Dossier d’analyse
Dossier d’architecture

Dossier de conception

Module UV
Analyse et
Conception UML
Page 19 / 90
Le Two Track Unified Process : cycle en Y

 Le TTUP permet une étude parallèle pour spécifier :


– le fonctionnel : modélisation du domaine, des besoins et du
problème à résoudre. Il s’agit de la branche de gauche.
– le technique : spécifier les choix techniques et l’architecture
logicielle. Il s’agit de la branche de droite.
 La troisième branche consiste d’articuler le mieux
possible les composants métiers avec des
composants technologiques.
 Le TTUP permet de produire une solution logicielle,
basée sur des composants réutilisables et extensibles.
 Le processus est itératif et incrémental

Module UV
Analyse et
Conception UML
Page 20 / 90
Illustration du TTUP

 La problématique consiste à publier un catalogue de


produits en ligne, à destination des particuliers.
 Branche fonctionnelle:
– Spécifier les besoins des utilisateurs du système, modéliser
la structure du catalogue, les traitements liés à l’identification
cliente, les promotions, l’intégration avec l’existant, etc.
 Branche technique:
– Spécifier le choix et le type de serveur (J2EE), le système
de stockage, les langages de développement utilisés, les
frameworks et middleware à prendre en compte, etc.
– Définir l’architecture (type client léger), les services mis à
disposition sur le Web et en Intranet.

Module UV
Analyse et
Conception UML
Page 21 / 90
Le Two Track Unified Process : cycle en Y

 La branche centrale:
– Déterminer les classes du système, organisation des
traitements, la mise en place des patterns, etc.
– Concevoir de manière détaillée la solution logicielle.

Module UV
Analyse et
Conception UML
Page 22 / 90
Guide méthodologique

 La modélisation des besoins:


– Identifier les acteurs et les services attendus du système
(besoins fonctionnels, cas d’utilisation, scenarii)
– Identifier les besoins et contraintes techniques
– Découpage en couches (application n-tiers)
– Élaborer les spécifications fonctionnelles sur la base du
cahier des charges.

Module UV
Analyse et
Conception UML
Page 23 / 90
Les diagrammes

 Cas d’utilisation  Standardiser les artefacts du


 Séquences développement
 Collaboration – Modèles, notation et diagrammes
 Classes
 Ne pas standardiser le processus
– Dirigé par les cas d’utilisation
 Objets
• Fonctionnalités du système du point
 États/transitions de vue de l’utilisateur
 Activités – Centré sur l’architecture d’utilisation
 Composants • Différentes vues du système qui doit
être construit
 Déploiement – Itératif et incrémental
• Découpage du projet en parties, mini-
projet ou en lot, représentant une
itération donnant lieu à un incrément
(stade du développement du produit)

Module UV
Analyse et
Conception UML
Page 24 / 90
Les diagrammes

 Cas d’utilisation Des diagrammes adaptés aux différentes vues du


système. Une vue est une préoccupation dans
 Séquences la définition de l’architecture logicielle :
 Collaboration – Cas d’utilisation
• Fonctionnalités du systèmes, scenarii.
 Classes – Logique
 Objets • Aspects fonctionnels du système, les concepts,
les objets et leur organisation
 États/transitions – Implémentation
 Activités • Codes sources, fichiers de données,
exécutables, bibliothèques, CVS
 Composants – Processus
• Concurrence et parallélisme, démarrage et arrêt
 Déploiement du système, tolérance au pannes, temps de
réponse
– Déploiement
• Répartition des modules sur un réseau
d’ordinateurs, installation

Module UV
Analyse et
Conception UML
Page 25 / 90
Diagrammes et vues
Utilisateur final
Fonctionnalités, aspects fonctionnels Programmeurs
du système Gestion du logiciel
Vue logique Vue d’implémentation
diagrammes de classes diagrammes de composants
diagrammes de collaborations

Vue des cas d’utilisation


diagrammes des cas d’utilisation
diagrammes de séquences
Vue des processus Vue de déploiement
diagrammes d’états diagrammes de déploiement
diagrammes d’activités

Intégrateurs système Ingénieurs système


Performance, Débit d’information Livraison, installation, communication
Module UV
Analyse et
du système Conception UML
Page 26 / 90
Guide méthodologique

 L’analyse objet:
– Saisir les besoins fonctionnels, afin de décrire les
fonctionnalités complètes du système.
– Identifier les classes des composants du système
• Donner un diagramme des classes d’analyse (concepts des
utilisateurs)
– Spécification de l’aspect dynamique du système
• Détailler les scenarii;
• Définir les états du système et les activités principales
• Essayer d’élaborer l’enchaînement des écrans (maquettes
jetables)

Module UV
Analyse et
Conception UML
Page 27 / 90
Diagramme des cas d’utilisation : objectifs

Cas d’utilisation  Description du système du point de vue


Séquences de l’utilisateur : ce qu’il attend du
Collaboration système.
Classes
 Pour mettre en évidence les services
rendus par le système
Objets
 Pour fixer le périmètre entre le système
États/transitions
et son environnement
Activités
=> très utile pour les spécifications
Composants fonctionnelles et l’élaboration des lots
Déploiement

Module UV
Analyse et
Conception UML
Page 28 / 90
Diagramme des cas d’utilisation : notation

Cas
 Cas d ’utilisation
d’utilisation
 séquences Cas
Séquences d'utilisation
 Collaboration
Collaboration Acteur
 Activités
Classes
 Classes
Objets
 Etats/transitions
États/transitions
 Objets Le diagramme est accompagné d’un
Activités
 Composants texte organisé décrivant le cas
Composants
 Déploiement d’utilisation et permettant de mettre en
Déploiement évidence les scénarii.

Module UV
Analyse et
Conception UML
Page 29 / 90
Diagramme des cas d’utilisation : notation

Cas d’utilisation
<<actor>>
Séquences
Collaboration Acteur
Acteur
Classes
• L’Acteur : indique un rôle joué par une
Objets
entité externe au système :
États/transitions
Activités • Acteur peut être un groupe de
personnes (rôles, stick man) ou
Composants d’autres systèmes (rectangle)
Déploiement
• L’acteur ne fait pas partie du système
en cours de modélisation (externe)

Module UV
Analyse et
Conception UML
Page 30 / 90
Diagramme des cas d’utilisation : notation

Cas
 Cas d ’utilisation
d’utilisation
 séquences Cas
Séquences d'utilisation
 Collaboration
Collaboration
 Activités
Classes
 Classes
Objets
 Etats/transitions
États/transitions
 Objets • Le cas d’utilisation représente le Quoi
Activités
 Composants • une fonctionnalité (pas une fonction!) du
Composants
 Déploiement système produisant un résultat satisfaisant
pour l’utilisateur.
Déploiement
• Séquence d’actions réalisées par le système,
suite à l’interaction de l’acteur

Module UV
Analyse et
Conception UML
Page 31 / 90
Exemple de cas d’utilisation

Module UV
Analyse et
Conception UML
Page 32 / 90
Description textuelle d’un cas d’utilisation
Titre : Retirer de l’argent avec une carte Visa
Résumé : ce cas permet à un porteur de carte, qui n’est pas client de la
banque, de retirer de l’argent, si son crédit hebdomadaire le permet.
Acteurs : Porteur de CB Visa (principal), SA Visa (secondaire)
Date de création : 09/03/2004 Date de mise à jour : 16/03/2004
Version : 2.0 Responsable : T. Membot
Description des scénarii :
Pré conditions :
La caisse du GAB est alimentée
Aucune carte bancaire n’est insérée
Scénario nominal
1. Le porteur de CB Visa introduit sa carte dans le lecteur du GAB
2. Le GAB vérifie que la carte est bien une carte VISA
3. Le GAB demande au porteur de saisir son code
4. Le GAB compare le code saisi avec celui dans la carte à puce
5. Le GAB demande l’autorisation au système VISA
6. Le système VISA donne son autorisation et indique le solde hebdomadaire
7. Le GAB demande au porteur de CB, le montant désiré du retrait
8. Le porteur saisit le montant désiré du retrait
9. Le GAB contrôle le montant demandé par rapport au solde hebdomadaire
Module UV
10. … Le cas d’utilisation se termine. Analyse et
Conception UML
Page 33 / 90
Enchaînements alternatifs du cas d’utilisation

A1: code d’identification erroné


L’enchaînement démarre au point 5 du scénario nominal.
6. Le GAB indique au porteur de CB Visa que le code est
erroné, pour la première ou la deuxième fois
7. Le GAB enregistre l’échec de la carte
Le scénario nominal reprend au point 3

Module UV
Analyse et
Conception UML
Page 34 / 90
Diagramme de séquences : objectifs

Cas d’utilisation  Compléter le diagramme des cas


Séquences d’utilisation :
Collaboration – en mettant en évidence les objets et
leurs interactions selon un scénario
Classes
– Les interactions sont séquentielles, selon
Objets l’axe du temps
États/transitions
Activités
Composants
Déploiement

Module UV
Analyse et
Conception UML
Page 35 / 90
Diagramme de séquences : notation

Cas d’utilisation Acteur Objet ou classe Autre objet ou

Séquences classe

Collaboration 1:Un message

Classes
Objets
États/transitions Ligne
Activités de temps
Composants
Déploiement

Module UV
Analyse et
Conception UML
Page 36 / 90
Diagramme de séquences : notation
messages

Synchrone
Cas d’utilisation
Séquences Asynchrone
Collaboration
Classes Réflexif
(événement)
Objets
États/transitions Récursivité
Activités TantQue cond
Composants Répétition Boucler ou * [cond] Message
Déploiement FinBoucle

Si cond [cond]
Condition Sinon ou
[not cond]
Module UV
FinSi Analyse et
Conception UML
Page 37 / 90
Diagramme de séquences : les contraintes
temporelles

 Les contraintes temporelles sont délimitées


Cas d’utilisation
par deux marqueurs, notés x et y.
Séquences
Collaboration
 Ils dénotent le temps à un instant tx et un
temps à un instant ty.
Classes
Objets  La période de temps entre x et y doit
satisfaire une contrainte de performance.
États/transitions
Activités
Composants x
Déploiement
{y-x<3s}
y

Module UV
Analyse et
Conception UML
Page 38 / 90
Exemple de diagramme de séquences

Module UV
Analyse et
Conception UML
Page 39 / 90
Evolution du diagramme de séquences

 Le diagramme de séquences doit évoluer pour faire


apparaître les objets au sein du système :
– Faire apparaître les objets IHM (Boundary Object)
– Faire apparaître les objets de communication avec les
systèmes externes (Boundary Object)
– Faire apparaître les objets de données (Entity Object)
– Le mapping DDL se construit progressivement
– Entre les objets IHM et les objets de données : objets
contrôleurs (Control Object)
 Les objets échangent des données avec l’extérieur,
plus particulièrement les requêtes et les réponses,
dans le cas de projet Web.
Module UV
Analyse et
Conception UML
Page 40 / 90
Diagramme d’états-transitions : objectifs

Cas d’utilisation  Permet de représenter le cycle de vie


Séquences des instances d’une classe
Collaboration
 Utilise un automate (abstraction des
comportements possibles) pour :
Classes
– spécifier les états,
Objets – Spécifier les transitions entre ces états
États/transitions et les actions associées aux
Activités transitions.
Composants  S’utilise pour la modélisation de
Déploiement certaines classes :
– Les classes d’objets réactifs
– Les traitements parallèles

classe automate
1 0..1 Module UV
Analyse et
Conception UML
Page 41 / 90
Diagramme d’états-transitions : notation

État initial
Le premier état
Cas d’utilisation Action en entrée (entry:action)
Action en sortie (exit:action)
Séquences
Collaboration Etat
Classes Nom événement
Objets
États/transitions Un événement/action^send clause
Activités Action à faire Un autre état
Composants Sur événement (on:E1)
Faire action dans état
Déploiement (Do:action)

Module UV
État final
Analyse et
Conception UML
Page 42 / 90
Exemple de diagramme d’états

Module UV
Analyse et
Conception UML
Page 43 / 90
Exemple de diagramme d’états

Au chômage

Embauche Perte d’emploi

En activité

Acquérir UML Do:travailler()


UML acquis > 65 ans
En formation
En retraite

Module UV
Analyse et
Conception UML
Page 44 / 90
Diagramme d’activités : objectifs

Cas d’utilisation  Plusieurs acceptions


Séquences – pour représenter le comportement
Collaboration d’opérations d’une classe
Classes – pour formaliser un processus d’une
Objets organisation, un cas d’utilisation
– Montrer les enchaînements des écrans
États/transitions
Activités
Composants
Déploiement

Module UV
Analyse et
Conception UML
Page 45 / 90
Diagramme d’activités : notation

Une activité Une activité


Cas d’utilisation
Séquences
Collaboration Une activité Une activité

Classes
Objets
États/transitions Une activité résultant
Activités d'une synchronisation
Composants
Une transition (activité finie)
Déploiement
Une activité

Module UV
Analyse et
Conception UML
Page 46 / 90
Exemple de diagramme d’activités

Module UV
Analyse et
Conception UML
Page 47 / 90
Guide méthodologique

 La conception de l’architecture technique


– Identifier les cas d’utilisation techniques
– Identifier les frameworks et classes techniques qui
répondent au contraintes opérationnelles du système
– Les designs patterns à mettre en place
– Spécifier le modèle logique de conception : conception
intégrant le modèle de classe d’analyse
– Prototypage

Module UV
Analyse et
Conception UML
Page 48 / 90
Identifier les cas d’utilisation techniques

 Les éléments techniques à considérer :


– Connaissance du matériel (machines + réseaux)
– Liste des progiciels à intégrer
– Outils retenus pour le développement et le travail en équipe
– Liste des contraintes non fonctionnelles
 Les diagrammes :
– Cas d’utilisation
– Composants
– Déploiement

Module UV
Analyse et
Conception UML
Page 49 / 90
Exemple de cas d’utilisation techniques

Module UV
Analyse et
Conception UML
Page 50 / 90
Diagramme des cas d’utilisations techniques

 De la même façon que pour la partie fonctionnelle, il


faut définir les scenarii pour chaque cas d’utilisation
technique.
 Les scenarii sont ensuite modélisés à l’aide de
diagrammes de séquence, puis affiner en indiquant
les objets internes.

Module UV
Analyse et
Conception UML
Page 51 / 90
Diagramme de collaboration : objectifs

Cas d’utilisation  Montrer les interactions entre objets


Séquences par leurs liens et les messages
Collaboration échangés
Classes  Spécifier de façon plus détaillée la
Objets manière d’échanger l’information.
États/transitions  Détecter les entités parallèles du
Activités système à modéliser.
Composants
Déploiement

Module UV
Analyse et
Conception UML
Page 52 / 90
Diagramme de collaboration : notation

Cas d’utilisation
Séquences Un acteur Un Objet
{nouveau}
Collaboration
Classes
void message()
Objets
États/transitions
Un lien {détruit}
Activités
Composants
Un Autre Objet
Déploiement
{transitoire}

Module UV
Analyse et
Conception UML
Page 53 / 90
Diagramme de collaboration notation des messages

Cas d’utilisation  Un lien sert de support de transmission


Séquences pour le message
Collaboration
 Le message déclenche une action dans
l’objet destinataire (modification d’état)
Classes  Il est possible de préciser pour un
Objets message ses arguments et valeurs de
États/transitions retour.
Activités
Composants
Déploiement

Module UV
Analyse et
Conception UML
Page 54 / 90
Diagramme de collaboration notation des messages

Cas d’utilisation  Spécification de contraintes sur les


Séquences messages
Collaboration *[i:=1..N] : la boucle pour
Classes [X>Y] : la condition Si
Objets
États/transitions  Récupération de résultat :
Activités result:= message()
Composants
Déploiement Le prof

*[to
us]
: deb :étudiant
o ut() Module UV
Analyse et
Conception UML
Page 55 / 90
Diagramme de collaboration notation des messages

Cas d’utilisation  Les objets actifs et parallèles (Thread) :


Séquences
Collaboration objet actif
Classes
Objets  Synchronisation entre entités actives :
États/transitions
Activités A1,B3 / Message
Composants
Déploiement
Les messages A1 et B3 doivent être envoyés
pour déclencher l’envoi de Message()

 Les diffusions (parallélisme) sont spécifiées :


* | | Message Module UV
Analyse et
Conception UML
Page 56 / 90
Comparaison séquence / collaboration

8: M8 A B C

M1
3: M3 M2
5: M5
C
A M3
1: M1
4: M4 M4
10: M10
2: M2 M5
6: M6
9: M9
7: M7 M6
M7 M8
B
M9

M10

Module UV
Analyse et
Conception UML
Page 57 / 90
Exemple de diagramme de collaborations

Module UV
Analyse et
Conception UML
Page 58 / 90
Diagramme de collaborations

 Le diagramme de collaboration propose une


représentation identique à celle fournie par le
diagramme de séquence.
 Seul le point de vue est différent :
– Mettre en avant les objets
– Vérifier la répartition des messages à destination des objets
– Dans le cas où un objet gère des messages non homogènes :
• il faut l’éclater en plusieurs objets
• chaque objet aura la responsabilité de gérer un sous ensemble
de messages de même nature.
– Les diagrammes de séquence et les scenarii doivent ensuite
être réactualisés !

Module UV
Analyse et
Conception UML
Page 59 / 90
Diagramme de collaborations

 Le diagramme de collaborations est affiné par


itérations successives pour faire apparaître :
– les objets du système et leurs interactions (liens)
– leurs compétences en termes de traitements (messages)

 Les objets issus de ce diagramme sont ensuite


classifiés pour fournir :
– un diagramme de classes d’analyse pour la branche
fonctionnelle
– Un diagramme de classes techniques pour la branche de
droite

Module UV
Analyse et
Conception UML
Page 60 / 90
Passage du diagramme de collaborations au
diagramme de classes

 Les objets classifiés dans le diagramme de


collaborations deviennent des classes dans le
diagramme de classes :
– Fournir la partie données
– Fournir la partie comportement/compétences
 Les liens entre objets dans le diagramme de
collaborations deviennent des associations entre les
classes des objets dans le diagramme de classes :
=> conditionne le développement

Module UV
Analyse et
Conception UML
Page 61 / 90
Diagramme de classes : objectifs

Cas d’utilisation  Dans le cadre de l’Object-Oriented design et


Séquences programming (OOD, OOP).
Collaboration  Les diagrammes de classes partitionnent le
Classes système en zone de responsabilité et
montre les associations entre elles.
Objets  Représentation de la structure statique du
États/transitions système d’information
Activités  Modélisation des classes et de leurs
Composants relations :
– Attributs (données), opérations (méthodes),
Déploiement
– contraintes,
– Les relations part-of (navigabilité) et type-of
(héritage) et cardinalité (1 to many)

Module UV
Analyse et
Conception UML
Page 62 / 90
Diagramme de classes : objectifs

Cas d’utilisation  Les diagrammes de classes sont


Séquences utilisés à trois niveaux d’abstraction :
Collaboration – Spécification : montre les interfaces
Classes entre les composants du logiciel. Les
Objets interfaces sont indépendantes du code.
– Conceptuel : les concepts dans le
États/transitions domaine du projet. Partition des rôles
Activités importants et des responsabilités dans le
Composants domaine.
Déploiement – Réalisation :montre les classes qui
correspondent directement au code Java
ou C++ (réalisation).

Module UV
Analyse et
Conception UML
Page 63 / 90
Diagramme de classes : notation

Cas d’utilisation  Les classes et les stéréotypes :


Séquences possibilité de création de nouveaux
Collaboration concepts
Classes
Objets Package
Name
États/transitions
Activités
Composants
Déploiement Class Name
<<Interface>>
Interface Name

Module UV
Analyse et
Conception UML
Page 64 / 90
Notion de paquetage

 Permet de regrouper des éléments de modélisation :


classes, cas d’utilisation ou autres diagrammes
 Plusieurs utilités
– obtenir une vision de plus haut niveau
– mettre en évidence des éléments réutilisables
– répartir le travail entre développeurs
– organiser la gestion de configuration (versionning)

Un paquetage

Module UV
Analyse et
Conception UML
Page 65 / 90
Exemple de paquetage

Module UV
Analyse et
Conception UML
Page 66 / 90
Diagramme de classes : notation

Cas d’utilisation  Les attributs peuvent avoir différents


Séquences types d’accès :
Collaboration – Public, Private, Protected.
Classes
NewClass
Objets Public attribute
Notation Rose
États/transitions Protected attribute
Private attribute
Activités
Composants
Déploiement
NewClass
+ Public attribute
# Protected attribute Notation UML
- Private attribute
Module UV
Analyse et
Conception UML
Page 67 / 90
Diagramme de classes : notation

Cas d’utilisation  Les relations entre paquetages, classes


Séquences et interfaces peuvent être :
Collaboration
Classes
Objets
Association Agrégation Dépendance
États/transitions (paquetage)
Activités
Composants Héritage Réalisation
Déploiement (classe) (interface)

Module UV
Analyse et
Conception UML
Page 68 / 90
Diagramme de classes : notation

<<Un stéréotype>>
Cas d’utilisation Une Classe
<<Un stéréotype>>
Une autre
+Un attribut public
Séquences -Un attribut privé * Une association *
classe
#Un attribut protégé
Collaboration +Une opération publique()
-Une opération privée()
Classes #Une opération protégée()
1-Une classe-association
Objets -Un attribut porté par l'association

États/transitions Une sous-classe

Activités Un attribut spécifique


Une opération spécifique()
Une classe
Composants agrégat

Déploiement <<Utilitaire>>
Une classe
utilitaire Une
association
navigable

Module UV
Analyse et
Conception UML
Page 69 / 90
Diagramme de classes : les associations

Cas d’utilisation  L’association exprime une connexion


Séquences sémantique bidirectionnelle entre
Collaboration classes
Classes
 Une association est une abstraction
des liens qui existent entre les objets
Objets instances des classes associées
États/transitions  Les associations se représentent de la
Activités même manière que les liens.
Composants – Distinction opérée en fonction du
Déploiement contexte

Module UV
Analyse et
Conception UML
Page 70 / 90
Diagramme de classes : caractéristiques d’un
rôle

Cas d’utilisation Chaque extrémité d’une association permet de préciser le


Rôle joué par chaque Classe dans l’Association. Pour
Séquences un rôle, il est possible de préciser
Collaboration  Nom du rôle
Classes  Multiplicité
Objets
 Navigabilité
 Agrégation
États/transitions
Activités 1
Exactement 1
Composants
0..* Zero ou plus
Déploiement
1..* Au minimum 1

0..1 Zero ou 1

Module UV
2..7 Plage de valeurs
Analyse et
Conception UML
Page 71 / 90
Nommage des rôles

 Le rôle décrit une extrémité d’une association

banque Client

Banque Personne

Employeur Employé

Module UV
Analyse et
Conception UML
Page 72 / 90
Diagramme de classes : les agrégations

Cas d’utilisation  Connexions bidirectionnelles


Séquences dissymétriques
Collaboration  Forme d’association qui exprime un
Classes couplage plus fort entre classes
Objets
 Représentation des relations
– maître et esclaves
États/transitions
– tout et parties
Activités
– composé et composants.
Composants
Déploiement

Module UV
Analyse et
Conception UML
Page 73 / 90
Exemples

Banque Client

1
Compte

N
1
GAB Cash
N

Module UV
Analyse et
Conception UML
Page 74 / 90
Hiérarchies de classes

 Gérer la complexité
– Arborescences de classes dont l’abstraction est croissante
 Généralisation (Rose)
– Super-classes
 Spécialisation Super-classe Classe plus
générale
– Sous-classes

Sous-classe Classe plus


spécialisée

Module UV
Analyse et
Conception UML
Page 75 / 90
Généralisation

 Factoriser les éléments communs


– attributs, opérations et contraintes

Abstraction plus générales

Véhicule

Véhicule terrestre Véhicule aérien

Voiture Camion Avion Hélicoptère

Module UV
Analyse et
Conception UML
Page 76 / 90
Spécialisation

 Extension cohérente d'un ensemble de classes

Transmission

Continue Discrète

Variateur Dérailleur Boîte de vitesses

Extension par spécialisation

Module UV
Analyse et
Conception UML
Page 77 / 90
Propriétés de la généralisation

 Signifie toujours : est un ou est une sorte de


Animal

Carnivore Herbivore

Lion Mouton Lapin

Module UV
Analyse et
Conception UML
Page 78 / 90
Les interfaces

 Une interface est une classe qui ne peut contenir que des
opérations : cahier des charges, spécification fonctionnelle.

 Elle ne véhicule que la sémantique de ses opérations et ne dit


rien sur la façon de les implémenter.

– On dit alors qu’une classe qui implémente les opérations,


implémente l’interface.

Module UV
Analyse et
Conception UML
Page 79 / 90
Diagramme d’objets : objectifs

Cas d’utilisation  Dit aussi diagramme d’instances, il


Séquences représente aussi la structure statique
Collaboration  S’utilise de manière ponctuelle pour
Classes – montrer l’effet d’une interaction,
Objets – représenter des structures complexes
États/transitions (récursives)
Activités
Composants
Déploiement

Module UV
Analyse et
Conception UML
Page 80 / 90
Diagramme d’objets : notation

Cas d’utilisation
Un objet : Une :Une classe
Séquences classe
Collaboration
Classes
Objets
États/transitions
Activités lien
Composants
Un Autre Objet
Déploiement

Module UV
Analyse et
Conception UML
Page 81 / 90
Diagramme de composants : objectifs

Cas d’utilisation
 Pour décrire les composants logiciels
et leurs dépendances
Séquences  On entend par composant un fichier
Collaboration de programme source, une
Classes bibliothèque, un programme
Objets exécutable
États/transitions  S’emploie en conception de logiciel
Activités pour allouer les classes et objets aux
Composants composants
Déploiement

Module UV
Analyse et
Conception UML
Page 82 / 90
Diagramme de composants : notation

Cas d’utilisation
Séquences
Collaboration
Classes Un composant

Objets
États/transitions Une dépendance fait référence aux services
offerts par un composant. La flèche va de
Activités l'utilisateur vers le fournisseur.

Composants Un autre
composant
Déploiement

Module UV
Analyse et
Conception UML
Page 83 / 90
Exemple de diagramme de composants

Module UV
Analyse et
Conception UML
Page 84 / 90
Guide méthodologique

 Conception objet préliminaire


– Développement des modèles de déploiement
– Construction des composants métiers et de leurs interfaces
– Développement des interfaces utilisateur
– Développement du modèle logique
– Organisation de la configuration logicielle

Module UV
Analyse et
Conception UML
Page 85 / 90
Guide méthodologique

 Conception détaillée en Java/J2EE


– Conception des classes, des EJB, des Servlets, etc.
– Mise en place des designs patterns
– Répartition dans les couches applicatives :
• Présentation
• Composants métiers
• Données
– Configuration logicielle détaillée

Module UV
Analyse et
Conception UML
Page 86 / 90
Diagramme de déploiement : objectifs

Cas d’utilisation  Permet la description de l’architecture


Séquences technique, les nœuds et leur
Collaboration interconnexion
Classes  Les nœuds de l’architecture sont des
Objets serveurs, des postes de travail et des
États/transitions périphériques
Activités  Les composants sont alloués aux
Composants différents nœuds
Déploiement

Module UV
Analyse et
Conception UML
Page 87 / 90
Diagramme de déploiement : notation

Cas d’utilisation
Un noeud
Séquences
Un composant
Collaboration
Classes
Objets
États/transitions Lien entre les nœuds

Activités
Composants Un autre noeud

Déploiement Un autre
composant

Module UV
Analyse et
Conception UML
Page 88 / 90
Exemple de déploiement

Module UV
Analyse et
Conception UML
Page 89 / 90
Extensions UML

Des extensions pour s’adapter aux contextes


d’utilisation :
 Valeur marquée : propriété spécifique associée à un élément de
modélisation
 Stéréotype : distinction d ’usage
 Contraintes : information sémantique rajoutée à un élément de
modélisation. OCL (Object Constraint Language) est le langage que UML
propose pour l’expression des contraintes.
 Profil : modèle d ’utilisation d ’UML

Module UV
Analyse et
Conception UML
Page 90 / 90