3 Coursomt Uml

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.
Iremia, R.Courdier 1
Université
Universit Ré
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
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)
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
Université
Universit Ré
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
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
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

Université
Universit Ré
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

3 Coursomt Uml

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

3 Coursomt Uml

Transféré par

Droits d'auteur :

Formats disponibles

Université

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

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

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

Mettre des codes couleurs Mettre du sens

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

3.2 Les Diagrammes de cas d’utilisation Les acteurs

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

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

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

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

Notations Evénements & Opérations, Actions

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

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

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

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

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

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

Analyse et Conception objet du logiciel

© Rémy Courdier - V1.8 21

Vous aimerez peut-être aussi