Vous êtes sur la page 1sur 4

Université

Universit Ré
é de la R éunion Gé
Cours de G énie Logiciel et approche Objet

Analyse et Conception objet du logiciel Analyse et Conception objet du logiciel 3. Les diagrammes de modélisation

Plan du cours Chapitre 3 : Les diagrammes de modélisation


MLL
UUM MLL
UUM
 Introduction au Génie Logiciel  Les diagrammes d’objets
 Les diagrammes de collaboration
 L’approche Orientée Objet et Notation UML
 Les diagrammes de classes
Moyens de
 Les diagrammes de modé
modélisation  Les diagrammes de cas d’utilisation visualiser et de
manipuler des
 Relations entre les différents diagrammes  Les diagrammes de séquence
éléments de
 De l’analyse à la conception  Les diagrammes d’états-transitions modélisation
 Les diagrammes d’activités
 Relation entre les notations OMT et UML
 Les digrammes de composants
 Les diagrammes de déploiement

© Rémy Courdier - V1.8 1 © Rémy Courdier - V1.8 2

Analyse et Conception objet du logiciel 3. Les diagrammes de modélisation Analyse et Conception objet du logiciel
3.1 Diagrammes d’objets, de collaboration et de classes

3.1Diagrammes objets, de collaboration et de classes Petits conseils pour un schéma UML efficace
MLL
UUM MLL
UUM
 Les diagrammes d’objets (ou d’instances)  Lorsque l'on passe à la conceptualisation d'une application de
 représenter les objets et leurs relations sans représenter les taille, on garde souvent les mauvaises habitudes datant de
envois de messages (représentation statique). diagrammes plus simples. Voici quelques rèrègles pour ré
réaliser
 permettre la compréhension générale du système des diagrammes clairs et lisibles par tous.
 faciliter la compréhension des structures complexes
(récursives)  Placer avant de relier
Les petits projets n'ont qu'un temps, et il faut rapidement perdre
l'habitude de construire son diagramme UML au fur et à mesure, à
 Les diagrammes de collaboration associer deux classes par une ligne dès que celles-ci sont créées. Bien
 correspondent à une extension des diagrammes d’objets. au contraire, l'utilité d'UML étant de vous permettre de réfléchir à votre
 représentation de la structure spatiale statique qui permet la application avant de vous lancer dans sa réalisation, il faut prendre (et
non "perdre") son temps à faire la liste de tous les éléments à placer
mise en relation d’un groupe d’objets
dans le diagramme, ensuite seulement les placer de manière logique
 représentation des interactions entre objets. dans le diagramme, et enfin, en tout dernier, associer les éléments
entre eux.
 Les diagrammes de classes
 représente la structure abstraite statique en terme de classe et
de relations
 description abstraite des liens potentiels d’un objet vers
© Rémy Courdier - V1.8 d’autres objets 3 © Rémy Courdier - V1.8 4

Analyse et Conception objet du logiciel Analyse et Conception objet du logiciel

Petits conseils pour un schéma UML efficace (2) Conseils Méthodologiques (suite)
MLL
UUM MLL
UUM
 Ne pas croiser les associations  Diviser pour mieux ré régner
L'association entre deux éléments est primordiale à la bonne Il faut savoir rester sobre : dès que vous vous apercevez que votre
compréhension d'un diagramme. Autant que faire se peut, il faut éviter diagramme a des grandes chances de contenir beaucoup d'éléments
de placer les éléments de telle sorte que leur association puisse se dans tous les sens, découpez-le en plusieurs sous-diagramme, auxquels
croiser : un ensemble d'associations clairement distinctes permet une le diagramme principal fera référence. La plupart des outils de
lecture beaucoup plus rapide de l'ensemble du diagramme.
Dans le cas où deux associations doivent se croiser, il faut bien conception UML vous permettent de lier deux fichiers UML directement
marquer la distinction entre celles-ci : au point de croisement, l'une depuis l'interface : n'hésitez pas à y faire appel !
d'entre elles doit faire un "saut" par-dessus l'autre, indiquant ainsi Accessoirement, cela vous permet de simplifier votre diagramme lors
qu'elle ne sont pas liées. de présentation à vos managers ou à d'autres groupes, probablement
peut intéressés par les détails...

 Mettre des codes couleurs  Mettre du sens


Même avec des éléments bien disposés et des associations distinctes, N'oubliez jamais d'utiliser des flèches là où elles sont requises, c'est-à-
le diagramme d'une grosse application peut facilement devenir illisible
à l'oeil humain (sans pour autant gêner sa lecture par un logiciel). Pour dire dans une association à sens unique, indiquant qu'un message ne
ne pas être le seul à savoir lire votre diagramme, prenez le temps de peut être transmis que dans un seul sens. Cela implique de nombreuses
marquer selon différentes couleurs les éléments d'une même catégorie, choses au niveau de développement, et savoir qu'un élément n'a pas
ou à marquer d'une couleur vive les éléments principaux de votre besoin d'émettre des messages, mais seulement d'en envoyer, peut
diagramme. Il deviendra ainsi un bien meilleur outil de travail de simplifier de beaucoup la réalisation de l'application.
groupe.

© Rémy Courdier - V1.8 5 © Rémy Courdier - V1.8 6

Iremia, R.Courdier 1
Université
Universit Ré
é de la R éunion Gé
Cours de G énie Logiciel et approche Objet

Analyse et Conception objet du logiciel 3. Les diagrammes de modélisation Analyse et Conception objet du logiciel 3. Les diagrammes de modélisation
3.2 Diagrammes de cas d’utilisation 3.2 Diagrammes de cas d’utilisation(2)

3.2 Les Diagrammes de cas d’utilisation Les acteurs


MLL
UUM MLL
UUM
 Définition  Quatre catégories d’acteurs
 Description sous forme d’actions et de réactions du  acteurs principaux : utilisent les fonctions principales du
comportement d’un système du point de vue de l’utilisateur système
 Objectif  acteurs secondaires : tâches administratives ou de
maintenance
 Définir les limites du système à concevoir
 matériel externe : dispositifs matériels incontournables utilisés
 Définir les relations entre le système et l’environnement
 autres systèmes : systèmes avec lesquels le système doit
 Partitionner l’ensemble des besoins d’un système
interagir
 Notation UML  Les 3 types de relations entre acteurs et cas
 Un utilisateur ou acteur est représenté par un petit personnage,
un cas d’utilisation ou fonctionnalité du système par un ovale,
d’utilisation
les flèches issues d’un personnage pointent vers les cas  relation de communication : Déclenche
d’utilisation.
système
 déclenchement d’un cas d'utilisation par un un acteur
 relation d’utilisation : Utilise
retrait  un cas d’utilisation comprend le comportement d’un autre cas
client virement d’utilisation
 relation d’extension : Etend
© Rémy Courdier - V1.8 7 © Rémy Courdier - V1.8  le cas d’utilisation source étend ou enrichi le comportement du 8
cas d’utilisation destination

Analyse et Conception objet du logiciel 3. Les diagrammes de modélisation Analyse et Conception objet du logiciel 3. Les diagrammes de modélisation
3.2 Diagrammes de cas d’utilisation(3) 3.3 Les diagrammes de séquence

Spécification d’un cas d’utilisation 3.3 Les diagrammes de séquence


MLL
UUM MLL
UUM
 Un diagramme de séquence montre des
La spécification d’un cas d’utilisation comprend : interactions entre objets selon un point de vue
temporel
 L’événement qui déclenche le cas d’utilisation  La représentation se concentre sur l’expression
 L’événement qui cause l’arrêt du cas d’utilisation des interactions
 L’interaction entre le cas d’utilisation et les acteurs  Notation
objet1
: objet2 objet3
 Les échanges d’informations
message 1
 La chronologie et l’origine des informations
message 2
 Les répétitions de comportements ex. Détruire

 Les situations optionnelles (Choix a, Choix b, Choix c) envoi synchrone (expéditeur bloqué jusqu’à acceptation du destinataire)

envoi réflexif (envoi d’un objet à soi-même)


envoi asynchrone (n’interrompt pas l’exécution de l’expéditeur)

© Rémy Courdier - V1.8 9 © Rémy Courdier - V1.8 10

Analyse et Conception objet du logiciel 3. Les diagrammes de modélisation Analyse et Conception objet du logiciel 3. Les diagrammes de modélisation
3.3 Les diagrammes de séquence(2) 3.4 Les diagrammes de d’états-transitions

Période d’activités 3.4 Les diagrammes d’états-transitions


MLL
UUM MLL
UUM
 Une période d’activité correspond au temps Un diagramme d’états-transitions est un automate
pendant lequel un objet effectue une action d’états fini déterministe associé à une classe
objet1 objet2
envois synchrone :
 Abstraction des comportements possibles
message 1 Le retour est implicite chaque objet suit le comportement décrit dans l’automate
associé à sa classe, son état caractérise ses conditions
dynamiques
 On associe un tel automate à toute classe qui
objet1 objet2 objet1 objet2 présente un comportement réactif marqué
message 1 message 1  Statecharts de D. Harel
D. Harel, “Statecharts : A Visual Formalisme for Complexe
Systems”, Science of Computer Programming, vol. 8, 1987.
Retour explicite d’envoi asynchrone Retour explicite avant suicide Automates hiérarchiques, possédant les concepts
d’orthogonalités, d’agrégation et de généralisation
© Rémy Courdier - V1.8 11 © Rémy Courdier - V1.8 12

Iremia, R.Courdier 2
Université
Universit Ré
é de la R éunion Gé
Cours de G énie Logiciel et approche Objet

Analyse et Conception objet du logiciel 3. Les diagrammes de modélisation Analyse et Conception objet du logiciel 3. Les diagrammes de modélisation
3.4 Les diagrammes de d’états-transitions(2) 3.4 Les diagrammes de d’états-transitions(3)

Notations Evénements & Opérations, Actions


MLL
UUM MLL
UUM
 Etat, Transition et Evénement  Le lien entre Evénements et Opération du
état final
état initial
Un état Evénement Un autre état diagramme de classe apparaît dans l’automate
 Chaque transition peut être décorée par le nom d’une action à
exécuter lorsque la transaction est déclenchée par un
la transition : passer Un événement déclenche la événement
d’un état à un autre transition qui lui est associée
 L’action correspond à une des opérations déclarées dans la
classe de l’objet destinataire de l’événement
 Les gardes  Les états peuvent contenir des actions
 Une garde est une condition qui valide ou non le déclenchement  exécutées à l’entrée ou à la sortie
d’une transition lors de l’occurence d’un événement
 exécutées lors de l'occurrence d’un événement pendant que
 Elles doivent être mutuellement exclusives (aspect l’objet est dans l’état Etat A
déterministe) entry:
A
Les mot-clés “entry:” et “exit:”
on UnEvénément:
Trop chaud [été] Trop chaud [hiver]
 indique les actions d’entrée et de sortie exit:
Le mot-clé “on” Un événement:
Climatiser Aérer  indique une action sur événement externe
Evénement[condition] Ev1 / UneAction
Une transition réflexive entraîne les
© Rémy Courdier - V1.8 13 © Rémy Courdier - V1.8 actions de sortie et d’entrée 14

Analyse et Conception objet du logiciel 3. Les diagrammes de modélisation Analyse et Conception objet du logiciel 3. Les diagrammes de modélisation
3.4 Les diagrammes de d’états-transitions(4) 3.4 Les diagrammes de d’états-transitions(5)

Actions et activités Notion avancée : Généralisation d’état


MLL
UUM MLL
UUM
 Définitions  Un état peut être décomposé en sous-états
 Une action correspond à une opération dont le temps disjoints
d’exécution est négligeable  états généraux = super-états, états spécialisés = sous-états
 Une activité est une opération qui prend du temps qui est  l’objet doit être dans un et un seul sous-état à la fois
exécutée pendant qu’un objet est dans un état donné. E2
C1
 Le mot-clé “do:” indique une activité
 Activité cyclique : s’arrête lorsqu’une transition de sortie est E1 C3
déclenchée. activité séquentielle : l’état peut être quitté si
lorsque l'activité parvient à son terme l’une des transitions est
C2
franchissable E2
C1

 Les 6 types d’Actions/Activités E1 E2


Etat A C3
/ Op1 / Op6 La transition E2 peut être factorisée
entry:Op2
on UnEvénément: Op3 C2
do: Op4
exit:Op5

© Rémy Courdier - V1.8 15 © Rémy Courdier - V1.8 16

Analyse et Conception objet du logiciel 3. Les diagrammes de modélisation Analyse et Conception objet du logiciel 3. Les diagrammes de modélisation
3.4 Les diagrammes de d’états-transitions(6) 3.5 Les diagrammes de d’activités

Notion avancée : Agrégation d’état 3.5 Les Diagrammes d’activités


MLL
UUM MLL
UUM
 Composition d’un état à partir de plusieurs autres  Variante des diagrammes d’états-transitions destinée à
états indépendants représenter le comportement interne d’une méthode
 on parle d’agrégation d’états et d’état composant  Ils représentent :
 l’objet doit être simultanément dans tous les états composant  le déroulement d’étapes regroupées séquentiellement
l’agrégation d’états  les synchronisations entre flots de contrôles
S  Notations :
T U
E3 Activité 1 Activité 1
C1 C1

E1 C3 E1
[cond1] [cond2]

C2 C2
E2 Activité 2 Activité 3 Activité 2 Activité 3

L’état S - produit cartésien des états T et U


© Rémy Courdier - V1.8 17 © Rémy Courdier - V1.8 18

Iremia, R.Courdier 3
Université
Universit Ré
é de la R éunion Gé
Cours de G énie Logiciel et approche Objet

Analyse et Conception objet du logiciel 3. Les diagrammes de modélisation Analyse et Conception objet du logiciel 3. Les diagrammes de modélisation
3.6 Les diagrammes de composants 3.7 Les diagrammes de déploiement

3.6 Les diagrammes de composants 3.7 Les diagrammes de déploiement


MLL
UUM MLL
UUM
Description des éléments physiques et leurs relations Ils montrent la disposition physique des matériels qui
dans l’environnement de réalisation composent le système ainsi que la répartition des
 Un composant exécutables sur ces matériels
 élément informatique qui entre dans la fabrication d’une
application.  Les nœuds
 ex : fichiers, paquetage ADA, bibliothèque chargée  un nœud est une ressource matérielle physique
dynamiquement,...  Dispositif (ex. Modem), Processeur (ex. PC), Mémoire (ex. Disque)
 On distingue 3 types de composants :
Spécification ou Interface, Corps , Spécification générique
 Liens entre nœuds
 lignes qui symbolisent un support de communication à priori
 Les dépendances entre composants bidirectionnel
 Les processus et tâches  connexion (ex. TCP-IP, RNIS,...) 1 1..10 Porte
PC sécurité
 Les programmes principaux
 Les sous-programmes * Serveur
<<RNIS>>
 Les
© Rémy Courdier - V1.8 sous-systèmes 19 © Rémy Courdier - V1.8 1 20

Analyse et Conception objet du logiciel

MLL
UUM

Fin du Chapitre 3

Les diagrammes de
modé
modélisation

© Rémy Courdier - V1.8 21

Iremia, R.Courdier 4