Présentation UML.ppt

S. KOUSSOUBE 1
Modélisation Objet avec UML
(Unified Modeling Language)

S. KOUSSOUBE 2
Objectifs du Cours
 Savoir Modéliser avant d’entreprendre la
construction d’un Système
 Connaitre le langage de modélisation UML
 Savoir faire le lien entre les modèles et les
codes

S. KOUSSOUBE 3
Méthodes – Processus- Langages.

S. KOUSSOUBE 4
Méthode – Processus - Langage
 Méthode:
 Moyen pour réaliser un artéfact (Logiciel)
 Procédures, Techniques et Outils support
 Langage, Processus, Outils

S. KOUSSOUBE 5
Notation (Langage)
Outil
Processus

S. KOUSSOUBE 6
 Processus de Développement :
 Un ensemble d’étapes à exécuter selon un
ordonnancement permettant d’analyser, et/ou
de concevoir, et/ou d’implémenter des
systèmes logiciels
 Un ordonnancement d’étapes peut être en
tout ou partie séquentiel, et/ou parallèle et/ou
itératif.

S. KOUSSOUBE 7
Développement - Modélisation
 Le développement d’un système logiciel
industriel nécessite la création de modèles
 Modèle : Vue abstraite (Simplifiée) d’un
système, d’un problème. Il décrit le système par
rapport à un point de vue spécifique et à un certain
niveau d’abstraction .
 Gérer la complexité;
 Assurer une cohérence architecturale
 Faciliter la communication entre membres du
Projet.

S. KOUSSOUBE 8
 Un système complexe s’appréhende mieux
à travers un petit ensemble de vues
indépendantes.
 Chaque modèle peut être représenté à
différents niveaux de fidélité ;
 Un modèles doit être connecté à la réalité.

S. KOUSSOUBE 9
 Un langage de modélisation rigoureux
comporte:
 des éléments de modélisation : les concepts
de modélisation fondamentaux et leur
sémantique ;
 Une Notation : le rendu visuel des éléments
de modélisation ;
 Des directives : des idiomes pour le bon
usage du langage.

S. KOUSSOUBE 11
UML en Bref
 un langage pour :
 spécifier,
 visualiser,
 construire,
 et documenter les éléments d’un système
logiciel.

S. KOUSSOUBE 12
UML en Bref
 langage de modélisation visuel le plus
utilisé pour construire les systèmes OO
 Fusion des Concepts de trois méthodes
Phares : OMT, BOOCH et OOSE
 Standardisé par l’OMG (adoption en
1997; http://www.omg.org/)

S. KOUSSOUBE 13
UML en Bref
UML
Booch Rumbaugh Jacobson
Meyer
(pré-post conditions)
Harel
(State charts)
Fusion
(description des opérations)
Wirfs-Brock
(responsabilités)
Odell
(classification)
Shlaer-Mellor
(Cycle de vie des objets)
Gamma et al
(Framework, patterns, notes)

S. KOUSSOUBE 15
UML en Bref
 Contenu
 La Sémantique UML
 Le Guide Notation UML
 Profils :
 Processus de Développement,
 Modélisation Métier,…
 Object Constraint Language (OCL)

S. KOUSSOUBE 16
UML en Bref
 Éléments Basiques de UML
 Éléments de Modélisation:
 classes, interfaces, cas d’utilisation, etc.
 Relations :
 association, généralisation, dépendances, etc.
 Diagrammes
 diagramme des cas d’utilisation, des classes,
d’interaction, etc.)

S. KOUSSOUBE 17
Analyse &
Conception
Implémentation
Structure Statique Comportementale
Cas d’utilisation
Classes
Objets
Packages
Structure composite
Activités
Séquence
Communication
Global d’Interaction
Temps
États/Transitions
Composants
Déploiement

S. KOUSSOUBE 18
UML en Bref
 Les Diagrammes
 Le diagramme de classe.
 Montre les classes du système avec leurs attributs
et méthodes ainsi que les relations et dépendances
 Le diagramme d’objets.
 Montre des graphes d’instances (objets) qui
peuvent exister pendant l’exécution du système.
Sert à Illustrer des structures de classes
compliquées.

S. KOUSSOUBE 19
UML en Bref
 Les diagrammes
 Les diagrammes de Package.
 Organisent les éléments de modélisation en
groupes avec pour objectif de rendre les
diagrammes plus simples et plus faciles à
comprendre.
 Les diagrammes de Structure Composite
 Explorent les instances des classes collaborant à
travers des liens de communications.

S. KOUSSOUBE 20
 Les diagrammes
 Les diagrammes de cas d’utilisation
 Montrent les utilisateurs et leurs interactions avec
le système. Structurent les fonctionnalités offertes
par le système.
UML en Bref

S. KOUSSOUBE 21
 Les Diagrammes
 Les diagrammes de séquence.
 Montrent des exemples d’historique de communication
entre les objets ou les utilisateurs.
 Les diagrammes de Communication (collaboration)
 sont une forme spéciale de diagramme d’objets enrichis
avec des informations sur le flot des messages entre
objets et sur la création/destruction des objets.
UML en Bref

S. KOUSSOUBE 22
UML en Bref
 Les Diagrammes
 Diagramme Global d’Interaction
(Overview Interaction)
 Une variante du diagramme d’activité qui donne
une vue globale d’un flot de contrôle.
 Diagramme de Temps (Timing Diagram)
 Explore le comportement d’un ou plusieurs objets
pendant une période de temps donnée.

S. KOUSSOUBE 23
 Les Diagrammes
 Les diagrammes d’états des classes
 Utilisés pour modéliser l’état des données et leurs
changements durant le cycle de vie des objets
instances des classes du diagramme de classe.
 Les diagrammes d’activité
 Une forme spéciale de diagramme de transition
d’états utilisé pour modéliser l’état du contrôle
UML en Bref

S. KOUSSOUBE 24
 Les Diagrammes
 Les diagrammes des composants.
 Montrent la structure du code et son partitionnement
en composants.
 Les diagrammes de déploiement
 Montrent la structure de l’implémentation en
Exécution et la distribution des objets et composants
sur les nœuds physiques .
UML en Bref

S. KOUSSOUBE 25
Mécanismes Généraux
d’Extension.

S. KOUSSOUBE 26
Meta modèle UML

S. KOUSSOUBE 27
Model
Management
Behavioral
Elements
Foundation
Meta modèle UML

S. KOUSSOUBE 28
Model
Management
Behavioral
Elements
Core
Data
Types
Foundation
Meta modèle UML

S. KOUSSOUBE 29
Model
Management
Behavioral
Elements
Core Extension
Mechanisms
Data
Types
Foundation
Meta modèle UML

S. KOUSSOUBE 30
Mécanismes d’Extension
 Mécanismes :
 Contraintes,
 Stéréotypes,
 Étiquettes/propriétés.
 s’appliquent à n’importe quel élément de
modélisation
 Permettent de spécialiser et d’étendre un
élément de modélisation avec une
nouvelle sémantique

S. KOUSSOUBE 31
Contraintes
 Une contrainte est une relation sémantique qui
doit être maintenue entre des éléments de
modèle
 Certains types de contraintes sont prédéfinis:
{frozen}, {subset}, etc.
 L’utilisateur peut définir de nouvelles contraintes
dans un langage libre ou en OCL.
 Notation : { contrainte }

S. KOUSSOUBE 32
Personne
Comité
dirige
membre de

S. KOUSSOUBE 33
Personne
Comité
dirige
est membre de
{subset}

S. KOUSSOUBE 34
Personne Compagnie
employé
employeur
chef agent

S. KOUSSOUBE 35
Personne Compagnie
employé
employeur
Il s’agit d’une personnalité
morale
chef agent

S. KOUSSOUBE 36
Personne Compagnie
employé
employeur
{Peronne.employeur =
Personne.chef.employeur }
chef agent
Il s’agit d’une personnalité
morale

S. KOUSSOUBE 37
Propriétés
 Propriétés, Valeur étiquetée : Valeur attachée à un
élément de modélisation.
 Une extension des propriétés d’un élément UML qui
permet d’apporter de nouvelles informations de
spécification
 Peut ne pas avoir de notation visuelle.
 l’Utilisateurs peut définir de nouvelles propriétés en
utilisant le mécanisme d’étiquetage (Valeur
étiquetée, « tagged value »): Paire (Étiquette,
Valeur)
 Permet d’alléger les diagrammes des détails
d’implémentation

S. KOUSSOUBE 38
Propriétés
 Propriétés, Valeur étiquetée :
 Ex: {estAbstrait = vrai}, {abstrait}
{ auteur = “Jean Bosco”, deadline =
31/10/04, phase = analyse}
Document
{serialized}
Document
{serialized}
« interface »
Serializable

S. KOUSSOUBE 39
Stéréotypes
 Stereotype: Une nouvelle classe du méta modèle
introduit au moment de la modélisation.
 sous-classe d’une classe existant dans le méta modèle
avec la même forme mais avec une intention différente.
 Un élément stéréotypé peut avoir :
 des contraintes additionnelles,
 des étiquettes supplémentaires,
 et éventuellement une notation graphique différente.
 Notation usuelle: mot clé entre guillemets placé au
dessus du nom de l’élément .

S. KOUSSOUBE 40
Élément de
Modélisation
Stéréotype
Propriétés

S. KOUSSOUBE 41
Élément de
Modélisation
Stéréotype
Propriétés
Classe
ClassePersistente

S. KOUSSOUBE 42
<<metaclass>>
Class
<<metaclass>>
Attribut
<<stereotype>>
persistent
ModeStaokage :TypeStockage
<< stereotype>>
identifier
<<stereotype>>
<<stereotype>>
{une classe persistente ou un
de ses parents doit avoir au
moins un attribut
« identifier »}

S. KOUSSOUBE 43
Classes Stéréotypés
« persistent »
Compte
« control »
CompteManager

S. KOUSSOUBE 44
Modèle des Cas d’Utilisation

S. KOUSSOUBE 45
 Modèle des Cas d’Utilisation :
 Une Vue du Système qui montre le comportement du
système tel qu’il est perçu par les utilisateurs
externes.
 Partitionne les fonctionnalités du système en
transactions (cas d’utilisation) significatives pour les
utilisateurs.
 Vecteur de communication entre clients, utilisateurs
finals et développeurs sur les fonctionnalités et
comportement du système.

S. KOUSSOUBE 46
 Les Concepts:
 Acteur
 Un ensemble cohérent de rôles qu’un utilisateur ou
une entité externe peut jouer en interagissant
avec le système
 peut consulter et/ou modifier directement l’état du
système

S. KOUSSOUBE 47
 Les Concepts:
 Acteur
 Utilisateurs humains directs : Identifier tous les
profils (administrateur, l’opérateur,…)
 les autres systèmes connexes qui interagissent
directement avec le système étudié, souvent par le
biais de protocoles bidirectionnels.

S. KOUSSOUBE 48
 Les Concepts:
 Acteur (Notation)
client
« actor »
Opérateur SYSCOMPTA

S. KOUSSOUBE 49
 Les Concepts:
 Acteur
 Découverte des Acteurs:
 Qui s’intéresse à tel besoin ?
 Dans quelle partie de l’organisation le système sera utilisé?
 Qui doit profiter de l’utilisation du système?
 Qui va fournir telle information au système?
 Qui utilise, ou supprime telle information?
 Qui va maintenir le système?
 Le système utilise-il une ressource externe?
 Une personne joue t-elle plusieurs rôles?
 Plusieurs personnes jouent-elle le même rôle?
 Le système doit-il interagir avec une ancienne application?
 etc.

S. KOUSSOUBE 50
 Les Concepts:
 Cas d’Utilisation:
 unité cohérente de fonctionnalité offerte par le
système;
 Modélise un service rendu par le système
 Comprend :
 séquence de messages échangés entre le système et des
agents externes aux systèmes (acteurs),
 un ensemble d’actions réalisées par le système

S. KOUSSOUBE 51
Cas d’Utilisation - Notation
<nom>
ouvrirCompte

S. KOUSSOUBE 52
 Les Concepts:
 Qu’est-ce qu’un Bon Cas d’Utilisation?
 Problème: Quel niveau de détail dans un Cas
d’Utilisation?
 Un Cas d’utilisation: une séquence de transactions
réalisées par le système et qui a un résultat significatif et
mesurable pour un acteur particulier.
 Un Cas d’Utilisation représente une unité majeure de
fonctionnalité qui est complète.
 Un cas d’utilisation est constitué de plusieurs scénarii.

S. KOUSSOUBE 53
 Les Concepts:
 Questions
 Quelles sont les tâches de chaque acteur ?
 Tel acteur va-t-il créer, stocker, modifier ou supprimer
des informations dans le système?
 Quel cas d’utilisation va créer, stocker, modifier ou
supprimer des informations dans le système?
 Un certain acteur doit-il informer le système des
changements externes?
 Le système doit-il informer un certain acteur des
changements internes?
 Quels cas d’utilisations doivent maintenir le système?
 Tous les besoins fonctionnels sont-ils pris en compte par
les cas d’utilisation?

S. KOUSSOUBE 54
Relations des Acteurs et CU
Agent
« acteur »
SYSCOMPTA
Chef Service

S. KOUSSOUBE 55
C
B
Agent
« acteur »
SYSCOMPTA
A
Chef Service

S. KOUSSOUBE 56
C
B
Agent
« acteur »
SYSCOMPTA
A
Chef Service

S. KOUSSOUBE 57
C
B
Agent
D
« acteur »
SYSCOMPTA
E
A
Chef Service

S. KOUSSOUBE 58
C
B
Agent
D
« acteur »
SYSCOMPTA
F
E
A
« include »
Chef Service

S. KOUSSOUBE 59
C
B
Agent
D
G
« acteur »
SYSCOMPTA
F
E
A
Points d’Extension :
Infocomp, ExamenSupl
« extend »
(ExamSupl)
« include »
sémantique
Chef Service

S. KOUSSOUBE 60
 Relations des Cas d’Utilisation
 Association(Communication) : Participation d’un acteur à
un C.U. La navigation (si elle existe) indique qui de l’acteur
ou du C.U. initie la communication
 Extend. A étend B : une instance de B peut être
augmentée (sous certaines conditions spécifiques) par le
comportement de A.
 Include. A inclut B : une instance de A contient le
comportement spécifié par B.
 Généralisation. Une généralisation de A vers B: A est une
spécialisation de B.

S. KOUSSOUBE 61
 Relations des Acteurs
 Généralisation. Une généralisation de A vers B :
l’acteur A est une spécialisation de l’acteur B.
 une instance de A peut communiquer avec les mêmes C.U.
que les instance de B.
 Association(Communication) : Participation d’un
acteur à un CU

S. KOUSSOUBE 62
 Diagramme des Cas d’Utilisation
 Une vue graphique de tout ou partie des acteurs, des
cas d’utilisations et de leurs interactions.
 Plusieurs diagrammes de C.U. :
 DCU principal: montre les acteurs et les principales
fonctionnalités du système.
 Des DCU particuliers (par acteur, un CU et ses relations etc.)

S. KOUSSOUBE 63
 Documentation des Cas d’Utilisation
 Description Textuelle
 Sommaire d’Identification (obligatoire) :
 titre du CU, acteurs, date de création etc.
 Description des Enchaînements (obligatoire) :
 scénarii nominaux, alternatifs, d’exception
 Besoins en IHM (Optionnel)
 Contraintes non fonctionnelles (optionnel) :
 fréquence, volumétrie, disponibilité, fiabilité, intégrité,
confidentialité, performance
 Pré/Post Conditions

S. KOUSSOUBE 64
1- Description Textuelle
 Description des Enchaînements:
 Ce que le système doit faire, pas comment il doit
le faire
 Quand et comment le C.U. commence?
 Quelles interactions le C.U. a avec les acteurs?
 Quelles données requiert le C.U.?
 Scénario nominal (séquence normale)
 Flots alternatifs et d’exception

S. KOUSSOUBE 65
2- diagramme d’activité du CU
 décrit l’ensemble de l’activité réalisée par le CU
 graphe constitué d’activités, d’actions et de
transitions
 Contient les branchements conditionnels et
toutes les boucles possibles.

S. KOUSSOUBE 66
3- Diagramme de Séquence Système.
 système = Une boîte noire ;
 les éventuels acteurs secondaires sollicités
 Acteur principal à gauche ;

S. KOUSSOUBE 67
Cas d’Utilisation
Documentation des Cas d’Utilisation

S. KOUSSOUBE 68
Texte
Cas d’Utilisation

S. KOUSSOUBE 69
Texte
Cas d’Utilisation activité activité
activité

S. KOUSSOUBE 70
Texte
Cas d’Utilisation
Scénario
activité activité
activité

S. KOUSSOUBE 71
Texte
Cas d’Utilisation
Scénario Syst
activité activité
activité

S. KOUSSOUBE 72
 Etapes:
 Commence à l’étape de Pré étude (« Inception »)
 Affiné et complété lors de l’étape d’Élaboration.

S. KOUSSOUBE 73
Diagrammes de la structure
Statique

S. KOUSSOUBE 74
Diagrammes de structure Statique
 Modèle structurel: Une vue du système
qui montre la structure des objets (et
leurs classes), leurs relations, attributs et
opérations.
 Deux types de Diagrammes Statiques:
 Diagrammes des Classes (vue des classes),
 Diagrammes d’Objets (vue des instances)

S. KOUSSOUBE 75
Le Diagramme des Classes
 Un graphe qui montre les classes du système les
relations entre elles ainsi que les attributs et les
opérations de ces classes.
 Utilisé généralement pour:
 Explorer les concepts du domaine (modèle du domaine)
 Analyser les besoins (modèle d’analyse conceptuel)
 Définir la conception détaillée d’un système.
 peut être organisé en paquetage.

S. KOUSSOUBE 76
Le Diagramme des Classes
 Exemple d’organisation en paquetages
Gestion des
Clients
Gestion des
Fournisseurs

S. KOUSSOUBE 77
Les Concepts
 Classe :
 un concept dans le système.
 personne, place, chose, concept, événement, écran,
ou rapport, etc.
 descripteur d’un ensemble d’objets ayant une
structure, un comportement et des relations
similaires.
 Un moule (template) à partir duquel des objets
sont créés.
 Les blocs constitutifs d’une application POO.

S. KOUSSOUBE 78
Classes
Notation : Rectangle à trois compartiments
Nom + propriétés générales
Attributs
Opérations
Note : les Deux derniers compartiments sont optionnels

S. KOUSSOUBE 79
Classes
Fenêtre
{abstrait, auteur= SK, status = testé }
+taille : Zone = (100, 100)
#visibilité :Booléen= invisible
+taillepardéfaut : Rectangle
#taille_max : Rectangle
-xptr : XWindow*
+afficher()
+cacher()
+créer()
-attacherXWindow(xw :XWindow*)
Noms +
[propriétés Générales]
Attributs
Méthodes

S. KOUSSOUBE 80
Classes
Fenêtre

S. KOUSSOUBE 81
Classes
Les objets détiennent de l’information (Attributs) et savent faire des choses
(Méthodes, Opérations)
Attributs :
 Information relative à un objet stockée par l’objet
ou au moins temporairement maintenue.
 Syntaxe
visibilité nom [multiplicité] : Type = val initiale
{propriétés}

S. KOUSSOUBE 82
Classes
Attributs :
 visibilité nom [multiplicité] : Type = val initiale
{propriétés}
 Visibilité:
 + (public), # (protected), - (private)
 Peut être omise. Pas de valeur par défaut.
 Multiplicité:
 Valeur par défaut : [1..1]
 Exemple :
 coul[3] : Couleur
 points[2..*] : Point
 adr: Adresse

S. KOUSSOUBE 83
Classes
Attributs :
 Visibilité
:
Visibilité symbole Accessible à :
Public + Tout Objet du Système
Protégé # Toute instance de la classe
et ses sous-classes
Privé - Toute instance de la classe
Paquetage ~ Toute Instance de toute
classe du même paquetage

S. KOUSSOUBE 84
Classes
Attributs :
 Attribut de classe : Souligner
 : +taillepardéfaut : Rectangle
 Attribut dérivé(calculé) : préfixe (/)
 : /age
 Propriété
 {frozen} : attribut non modifiable

S. KOUSSOUBE 85
Classes
 Opération.
 Les opérations qu’une classes sait réaliser.
 visibilité nom(liste de paramètres) : type de retour
{propriétés}
 Visibilité: idem que pour les attributs
 paramètres formels:
 séparés par des virgules.
 syntaxe : Sorte nom : type = valeur par défaut
 sorte : in(valeur utilisée pour traitement) , out(valeur retournée par le traitement ),
inout(valeur utilisée en entrée et modifiée en sortie du traitement)

S. KOUSSOUBE 86
Classes
 Opération.
 opération de classe : Soulignée
 Propriétés :
 {query} : méthode ne modifiant pas l’état du système
 {update} : modifie l’état du système
 {abstract} : méthode non implémentée (ou en italique)
 {concurrency = séquential/guarded/concurrent}
 Documentation : note attachée à l’opération (ex.
algorithme)

S. KOUSSOUBE 87
Classes
 Exemple

S. KOUSSOUBE 88
Classes
Stéréotypes.
 Chaque classe peut avoir un stéréotype.
 Les stéréotypes usuels :
 boundary, classe à la limite du système donc devra permettre la communication avec
l’extérieur ex: les formulaires
 entity, classe ayant vocation à être sauvegardée
 control,
 exception,
 metaclass,
 utility.

S. KOUSSOUBE 89
Classes
 Stéréotypes Boundary (frontière) :
 classe modélisant la communication entre le système et
son environnement. Classe se trouvant à la périphérie du
système tout en étant à l’intérieur du système. Interagit
avec les acteurs et les objets:
 Fenêtre (interface utilisateur),
 Protocole de Communication (interface système),
 Interface Imprimantes
 etc.

S. KOUSSOUBE 90
Classes
 Stéréotypes Boundary
« boundary »
FenCréationCompte
« boundary »
Impression
FenCréationCompte

S. KOUSSOUBE 91
 Stéréotypes Entity :
 Classe généralement persistante modélisant une
information (avec le comportement associé).
 Classe Passive (non initiatrice d’interactions). Peut
participer à la réalisation de plusieurs cas d’utilisation.
Classes

S. KOUSSOUBE 92
 Stéréotypes Entity :
« entity »
Compte
« entity »
Catalogue
Facture
Classes

S. KOUSSOUBE 93
 Stéréotypes Control :
 Contrôle les interaction d’une collection d’objets. Classe
qui modélise le comportement spécifique d’un (ou
plusieurs) cas d’utilisation. Contient la logique
applicative :
 Crée, initialise et détruit les objets contrôlés ;
 Contrôle le séquencement et la coordination des opérations
exécutées par les objets contrôlés ;
 Gèrent les aspects « concurrence ».
 Est généralement l’implémentation d’un objet intangible.
 Est généralement détruit à la fin de la réalisation du CU
Classes

S. KOUSSOUBE 94
 Stéréotypes Control
« control»
CompteManager FactureManager
Classes

S. KOUSSOUBE 95
 Stéréotype Utilité
 Classe contenant une collection de sous-programmes
libres (fonctions non membres)
 fournit des services algorithmiques communs,
(re)utilisables dans divers contextes ou
 « transcrit » une librairie ou une application non orienté-
objet dans un formalisme objet
Classes

S. KOUSSOUBE 96
Stéréotype Utilité.
« utility »
FonctionMaths
sin(Angle) :Real
cosin(Angle) :Real
sqrt(Real) : Real
Classes

S. KOUSSOUBE 97
Stéréotypes.
Autres : « type », « implementationClass »
« type »
Object
« type »
Set
«implementationClass»
HashTab
« implementationClass»
HashTabSet
addElt(Object)
removeElt(Object)
testElt(Object):Boolean
elements
*
addElt(Object)
removeElt(Object)
testElt(Object):Boolean
setTabSize(Integer)
body
1
Relation de réalisation

S. KOUSSOUBE 98
Interface
 spécifie un ensembles d’opérations visibles d’une
classe ou d’un composant sans spécification de la
structure interne
 Spécifie en général une partie limitée du
comportement d’une classe.
 Pas d’implémentation, pas d’attributs (pas d’états), pas
d’associations.
 ≡ classe abstraites ne contenant ni attributs ni
méthodes et ne contenant que des opérations
abstraites.

S. KOUSSOUBE 99
Interface
 Notations:
 rectangle à compartiments avec le mot clé
« interface ». Le compartiment des attributs
peut être omis car étant toujours vide
 petit cercle sous lequel on place le nom de
l’interface. Le cercle est relié à la classe qui
supporte l’interface par une ligne continue.

S. KOUSSOUBE 100
Interface
 Il peut exister la relation de généralisation entre
interface.
 Une classe qui utilise ou requière les opérations
d’une interface peut être reliée au cercle par une
flèche pointillée pointant vers le cercle.
 La relation de réalisation d’une classe vers une
interface supportée est représentée par une trait
discontinu avec une flèche en forme de triangle
(symbole de généralisation discontinu)

S. KOUSSOUBE 102
Classes Paramétrées (Templates)
 Un template est le descripteur d’une classe
ayant un ou plusieurs paramètres formels.
Il définit une famille de classes
 Template non directement utilisable
 Une liaison des paramètres à des valeurs
particulières génère une classe particulière

S. KOUSSOUBE 103
 Paramètres typiques : types (ou classe) des
attributs
 Mais peuvent être de type: entier, type
quelconques ou même des opérations
 ne peut pas être une superclasse ou la cible d’une
association
 une association unidirectionnelle du template
vers une autre classe est permise
 peut être une sous-classe d’une classe ordinaire C
 toute classe obtenue à partir du template est sous
classe de la superclasse C


S. KOUSSOUBE 104
 Notation: un petit rectangle en pointillé est superposé
sur le coin supérieur droit du rectangle de la classe
C
P1, …,Pk
Pi : <Nom> : [type = Valeur par Défaut]
Liaison : C <V1, …, Vk>

S. KOUSSOUBE 105
LARRAY
T, K:integer
StudentList
« bind »(Student, 36)
LARRAY<Point, 9>
Exemple

S. KOUSSOUBE 106
Autres catégories de Classe
 Métaclasse
classe dont les instances sont des classes.
stéréotype « métaclasse »
 Enumération. type défini par l’utilisateur sous la
forme d’un ensemble de littéraux avec un ordre.
stéréotype « enumeration ».
 Une liste de littéraux peut être placés dans le
compartiments des attributs. Les opérations définis
sur les littéraux peuvent être indiqués dans le
compartiment opérations.

S. KOUSSOUBE 107
 Enumération.

S. KOUSSOUBE 108
 Stéréotype
 métaélement défini par l’utilisateur et dont la
structure correspond à celle d’un métaélement de
UML.
 Notation : classe stéréotypée : « stéréotype ».
 Les contraintes sur les éléments décrits par le
stéréotype peuvent apparaître dans un compartiment
nommé appelé Constraints.
 Les tags requis peuvent être placés dans un
compartiment nommé Tags.
 L’élément de base peut être spécifié à travers la
propriété {élément de base = nom}

S. KOUSSOUBE 109
Relations entre Classes
 Plusieurs Catégories:
 Association (binaire, n-aire)
 Agrégation (non supportée par UML 2),
 composition,
 généralisation, héritage
 Relation (dépendance, …)

S. KOUSSOUBE 110
Associations
 Une association définit une relation sémantique
pluridirectionnelle entre des classes.
 association binaire : Association mettant en relation
deux classes
 Association n-aire : Association mettant en relation plus
de deux classes.
 Classe association : association qui a des propriétés
similaires à celles d’une classe (attributs, opérations,
autres associations)
 Lien: connexion physique on conceptuelle entre
objets (instance d’une association)

S. KOUSSOUBE 111
Associations Binaires

S. KOUSSOUBE 112
C1 C2
nom
C1
nom
Association
Réflexive

S. KOUSSOUBE 113
Personne Compagnie
employé
employeur
agent
chef

S. KOUSSOUBE 114
Associations Ternaires
Commande Produit
Client
commande

S. KOUSSOUBE 115
Classe - Association
Abonné Document
InfoPrêt
prête
date
• Association ayant des attributs et promue aussi en classe

S. KOUSSOUBE 116
Abonné Document
InfoPrêt
prête
datePrêt

S. KOUSSOUBE 117
Abonné Document
prête
datePrêt

S. KOUSSOUBE 118
Association qualifiée
 Une association dans laquelle un attribut nommé
qualificateur désambiguïse les objets situé à l’extrémité
plusieurs
Banque
Personne
*
*
Possède cpte
Personne
*
0..1
numCpt
Banque

S. KOUSSOUBE 119
Association: Informations
 Nom de rôle
 Nécessaire pour les associations réflexives
 Navigation
 Indicateur de d’agrégation
 Multiplicité : chaîne comprenant une
 Modifiabilité : {frozen} , {addOnly}
 Autres propriétés:
 {ordered}: ensemble ordonné d’objets liés (sans doublon)
 {sequence}: ordonné, doublon autorisé
 {bag} : non ordonné

S. KOUSSOUBE 120
Association: Extrémités
A B
Multiplicité A Multiplicité B
Rôle A Rôle B
nom

S. KOUSSOUBE 121
Exemples
Fenêtre Ecran
ordered
visible sur 1
*
Parcours Ville
sequence
*
1

S. KOUSSOUBE 122
Association: Extrémités
 Multiplicité : nombre
d’éléments de la classe
pouvant être en relation
avec une instance de
l’autre classe
 chaîne comprenant une
séquence d’intervalles
d’entiers
Indicateur Signification
0..1 Zéro ou un
1 Un seul
0..* Zéro ou plus
1..* 1 ou plus
n N seulement
(n > 1)
0..n 0 à n (n > 1)
1..n 1 à n (n > 1)

S. KOUSSOUBE 123
Associations particulières
 Agrégation : association non symétrique
dans laquelle une des extrémités joue un
rôle prédominant par rapport à l’autre
Formation Cours
1 1..*

S. KOUSSOUBE 124
 Composition : Agrégation forte
 coïncidence du cycle de vie d’une partie
avec celle d’un tout, contenance physique
 multiplicité de l’agrégat <= 1 (Non partage).

S. KOUSSOUBE 125
 Composition vs Agrégation
Polygone Points
1 3..*
PptésGrahiques
Couleur
texture

S. KOUSSOUBE 126
 Généralisation . Relation taxonomique entre un
élément plus général (le parent, la superclasse) et
un élément plus spécifique (le fils, la sous-classe)
 Représente la relation conceptuelle « est une sorte
de »
 Contraintes:
 overlapping
 Disjoint : Aucun ancêtre ne peut avoir deux fils.
 Complet : tous les fils ont été spécifiés
 Incomplet : la liste des fils est incomplète.

S. KOUSSOUBE 127
Généralisation
Arbre
Okoumé Ozigo
{disjoint, incomplet}

S. KOUSSOUBE 128
Découverte des Classes
 Pas de Recettes miracles
 Grady Booch: « This is hard »
 On peut se baser la distinction des
catégories de classes: « boundary »,
« control » et « entity » Conformément au
point de vue model-view-controller

S. KOUSSOUBE 129
 Classes Entity:
 Peuvent se trouver généralement en phase
« Élaboration » (classes du Domaine)
 Typiquement classe accomplissant une certaine
responsabilité
 Examiner les responsabilités découlant des flots
d’événements des Cas d’Utilisation
 Candidats: Noms et groupes nominaux
 Filtrage: noms hors du domaine, de simples
expressions du langage, noms redondants, noms
décrivant la structure des classes

S. KOUSSOUBE 130
 Classes Boundary:
 Modélisent l’interface du système
 Examiner chaque paire « acteur-scénario » pour
découvrir ces classes
 En phase « Elaboration » : classes de haut niveau
(ex.: Fenêtre mais pas les détails, boutons de ces
fenêtres)
 En Phase de Conception: affinage des classes pour
prendre en compte les mécanismes UI ou les
protocoles de communication choisis.

S. KOUSSOUBE 131
 Classes Control:
 Modélisent le séquencement spécifique d’un ou
plusieurs cas d’utilisation
 Utilisation subjective
 En début d’ Elaboration: une classe control pour
chaque pair « acteur - cas d’utilisation » qui sera
responsable du flot associé au C.U.
 A Affiner en phases d’analyse et conception
(suppression, fusion, division des classes control)

S. KOUSSOUBE 132
Niveaux de Détail des Classes
 Différents modèles:
 Classe d’Analyse
 Classe de Conception
 Classe d’Implémentation

S. KOUSSOUBE 133
Structuration du Modèle
Conceptuel.
 Voir diagramme de Paquetage

S. KOUSSOUBE 134
Diagramme d’objet
 Graphe d’instances, comportant des objets et des
valeurs.
 instance d’un diagramme de classe qui montre
l’état du système à un instant donné.
 Utile pour explorer des exemples « réels » d’objets
et leurs relations. Certaines classes et leurs
associations sont jugées trop abstraites/trop
complexes.

S. KOUSSOUBE 135
Diagramme d’objet
 Objet :
 un rectangle à deux compartiments.
 Le premier contient le nom et la classe de l’objet soulignés :
nom-objet : classe
 Le second, les valeurs des attributs
 Liens : instances des associations du
diagramme des classes

S. KOUSSOUBE 136
Diagramme d’objet
Points = ((0,0) ,
(4,0),(4,3))
Couleur = vert
Couleurfond= rouge
triangle1: Polygone
: Polygone
triangle1: Polygone

S. KOUSSOUBE 137
Diagramme d’objet
: C
t1: C
r1 r2

S. KOUSSOUBE 138
Diagramme d’objet
 du point de vue notationnel, sous-ensemble du
diagramme de communication
 Mais explore la structure des objets alors que le DC
explore le comportement
 Peut évoluer vers un DC par ajout de messages
 Souvent, modèle temporaire. Détruit après màj
du diagramme de classe/du code.
 Valeur ajoutée dans l’acte de modélisation et non
dans le modèle lui même.

S. KOUSSOUBE 139
Diagrammes d’interactions

S. KOUSSOUBE 140
Diagrammes d’interactions
 Montrent les interactions entre les instances du
modèle
 graphe d’instances (incluant éventuellement les liens) et
les stimulus
 Instances existantes
 Création et destruction d’instance
 Deux sortes de diagrammes
 diagrammes de séquence ( temporel)
 diagrammes de communication ( contexte structurel)

S. KOUSSOUBE 141
Diagrammes de Séquence
 montrent les interactions entre les objets
en mettant l’accent sur l’aspect temporel
(la chronologie des envois de messages )

S. KOUSSOUBE 142
 Utilisé pour modéliser:
 Scénarii d’utilisation : une façon d’utiliser le système;
tout ou partie d’un CU, ou une combinaison de
plusieurs CU
 Logique des méthodes : en particulier pour les
opérations complexes ( code objet visuel)
 Logique des services. Méthodes de haut niveau
invocables par plusieurs variétés de clients (ex:
services web, services CORBA, …)

S. KOUSSOUBE 143
 Plusieurs niveaux de détail:
 Niveau système : interaction entre les acteurs et le
système;
 Niveau objet (plus détaillé)
 Niveau méthode;

S. KOUSSOUBE 144
 Constituants:
 classifieur et instances : classes, objets, acteurs
 Ligne de vie
 La période de vie de l’objet durant le scénario
modélisé
 Boîte (période) d’activation

S. KOUSSOUBE 145
 Constituants:
 Messages:
 Flèche étiquetée
 Étiquette = signature de la méthode invoquée en
réponse du message ou texte décrivant l’information
transmise si acteur;
 Méthode statique si cible = classe
 Valeur retournée (optionnelle):
 flèche discontinue étiquetée avec la valeur
retournée
 ou message : valeur retournée

S. KOUSSOUBE 146
 Constituants:
 stéréotypes
 Classifieurs: « acteur », « contrôleur », « UI »
etc.
 Messages : « créer », « détruire »
 Stéréotypes visuels

S. KOUSSOUBE 147
nom1 : Classe nom2 : Classe
objet

S. KOUSSOUBE 148
Ligne de
vie
objet

S. KOUSSOUBE 149
Activation
Ligne de
vie
objet

S. KOUSSOUBE 150
Activation
Ligne de
vie Stimulus/message
nom(…)
objet

S. KOUSSOUBE 151
Activation
Ligne de
vie Stimulus
Retour
nom(…)
Envoi réflexif
objet

S. KOUSSOUBE 152
: Classe
Activation
Ligne de
vie Stimulus
Création
Retour
nouveau
nom(…)
Envoi réflexif
objet

S. KOUSSOUBE 153
: Classe
Activation
Ligne de
vie Stimulus/message
Création
Retour
Destruction
nouveau
nom(…)
détruire
Envoi réflexif
objet

S. KOUSSOUBE 154
: Classe
Activation
Ligne de
vie Stimulus
Création
Retour
Destruction
nouveau
nom(…)
détruire
Envoi réflexif
objet
: Classe
Message asynchrone

S. KOUSSOUBE 155
:A :B :C :D
x
y
{y-x < 3 s}
t
t’
{t’-t < 3 s}
While C loop
end loop
if C
else
endif
*[C] m5
m1
m2
m3
m4
m6
m7
[C] m8
[non C] m

S. KOUSSOUBE 156
Diagramme de Séquence
 Le placements des objets peut être calqué sur le
découpage par niveau du système (acteur humain puis
contrôleur, puis classes UI, classes métiers, classes
techniques permettant l’accès à la BD ou aux ressources
du système
 Nommer les acteurs de façon cohérente / DCU
 Nommer les classes de façon cohérente / Diag. Classe
 Un acteur peut porter le même nom qu’une classe
 Inclure une description « textuelle » de la logique du
diagramme, à gauche

S. KOUSSOUBE 157
 Placer les acteurs humains ou organisationnels à
l’extrême gauche du DS (habituellement initiateur
d’interaction)
 Placer les acteurs systèmes réactifs à l’extrême droite
(systèmes avec lesquels une interaction est initialisée
par le système en construction)
 Placer les acteurs systèmes proactifs à gauche
(systèmes qui initialise une interaction avec le système
en construction)
 Ne modéliser la destruction des objets que si « critique »

S. KOUSSOUBE 158
 Sur les Classifieurs:
 Nommer les objets si on les référencie dans les
messages (nom:classe)
 Ou si il en existe plusieurs de même nom
 source:Compte destination: Compte

S. KOUSSOUBE 159
Diagrammes de Communication
 montrent les interactions entre objets, en mettant
l’accent sur la structure spatiale statique qui
permet la mise en collaboration d’un groupe
d’objet, pour répondre à un besoin donné.
 Une interaction est réalisée par un groupe d’objets qui
collaborent en échangeant des messages. Ces messages
sont représentés le long des liens qui relient les objets.
 Un message correspond généralement à une opération
de l’objet destinataire

S. KOUSSOUBE 160
 Constituants:
 Objets;
 Liens (associations, composition, dépendance, héritage)
 Messages
 [SéquenceNombre:] NomMéthode (paramètres) [:
valeurRetournée]
 Les Diagrammes de séquence sont adaptés pour montrer la
logique séquentielle mais pas pour donner une vue globale
des interactions. C’est l’inverse pour les Diagrammes de
communication

S. KOUSSOUBE 161
Prédécesseur Condition-de-garde expression-de-séquence : valeur-de-
retour := nom-message(liste arguments)
3.7.4 : move(5,2)
A3, B4/ [x<1] C3.1 : res := getPosition (fig)
Pred. Garde Seq. Résultat Message Paramètre
3.7.4 : move(5,2)
3.5 *[1..5] : move(5,2) Itération
3.5 [X >0] :move(5,2) Condition
Label des Messages

S. KOUSSOUBE 162
: Cabine
: Ascenseur
: Porte
: Lumière
1 : monter
3 : fermer
2 : allumer

S. KOUSSOUBE 163
:ZonedeDessin
:Figure
*[tous] :dessiner

S. KOUSSOUBE 166
 Utilisation:
 Utiliser des diagrammes de communication de niveau objet
(habituel) pour explorer la conception interne du système.
 Utiliser des diagrammes de niveau spécification pour explorer les
rôles joués par les classes du domaine dans le système.
 Les DC ne modélisent pas les flots des processus. Pour modéliser
les processus, utiliser les diagrammes d’activité.
 Si le séquençage est important (beaucoup) de numéro de
séquence, préférer le diagramme de séquence

S. KOUSSOUBE 167
 Appliquer les règles vues sur les DS:
 nommer les objets s’ils sont référencés dans les
messages
 Nommer les objets s’il en existe plusieurs du même
type
 Appliquer les stéréotypes textuels de façon cohérente

S. KOUSSOUBE 168
Diagrammes d’États - Transitions

S. KOUSSOUBE 169
Diagrammes d’Etats - Transitions
 permettent de décrire précisément le comportement d’une instance
d’une classe en terme d’états et d’événements au moyen d’un
automate (stateschart) associé à la classe de l’objet.
 Intéressant pour les objets qui ont un comportement réactif
marqué.
 Cycle de vie d’un objet
 Évolution de l'état d’un objet
 Comportement face à l’arrivée d’evènément
 Une forme spéciale du DET est utilisée pour modéliser les processus
métiers et opérations complexes (DA)

S. KOUSSOUBE 170
 Rappels sur les Automates Finis
 Automate fini:
 Un ensemble de symboles A
 Un ensemble fini d'états Q
 Un ensemble d'états initiaux I  Q et d'états terminaux T  Q
 Une relation de transition R  Q × A × Q
 (qi, s, qj)  R  passer de qi à qj quand on lit s
 Representation sous forme de graphe:
 Chaque état = un sommet
 Une transition (qi, s, qj) = un arc étiqueté qi s qj
 Automate déterministe : R est une fonction de Q × A dans Q
 Automate complet: R est une fonction totale
 On peut (tjrs) rendre un automate déterministe, complet

S. KOUSSOUBE 171
 Utilisation d'un Automate fini:
 procédure de reconnaissance de mots (suite de symboles de A)
 Un mot s1, …, sn est reconnu s’il existe q0, q1,…, qn tel que q0  I, qn  T et
 i  1, n (qi-1, si, qi)  R (il y a un chemin partant d’un état I à un état T)
 Les automates finis déterministes sont efficaces
 Complexité en temps linéaire/taille du mot
 Mais pouvoir expressif limité
 Ne peuvent pas reconnaitre par exemple les expressions bien parenthésées

S. KOUSSOUBE 172
 Automates plus expressifs
 Automate à pile :
 À chaque transition, on empile/dépile des symboles
 Reconnait tous les langages « hors contexte » (lges de
programmation)
 Mais certains langages sont hors de portée
 Machine de Turing (encore plus puissant)
 À chaque transition, on peut lire ou écrire sur un ruban
 Reconnait tous les langages décidables
 Pouvoir de calcul équivalent à un ordinateur
 Langages indécidables hors portée

S. KOUSSOUBE 173
 Pouvoir expressif variable:
 Pas d’action ni de garde  automate finis
 Pas de garde + actions limité à l’utilisation d’une pile
 automate à pile
 Dans le cas général, machines de Turing

S. KOUSSOUBE 174
 Concepts
 Etat:
 Condition durant la vie d’un objet pendant laquelle il satisfait
une certaine condition, réalise certaines action ou est en
attente d’un événement.
 image de la conjonction des valeurs de tout ou partie des
attributs de l’objet et de la présence ou non de liens entre
l’objet et d’autres objets.
 Un objet est toujours dans un état donné pour un temps
donné (durée et stabilité).
 Un état porte un nom et est représenté par un rectangle
arrondi..

S. KOUSSOUBE 175
rouge
orange
vert
enActivité
àlaRetraite
auChomage
FeuTricolore
Personne 0..1
1..*
âge
 société
Age >60
non ( société) et
âge <= 60
étatInitial (unique) unEtatfinal (éventuellement multiple)
Société

S. KOUSSOUBE 176
 Concepts
 Transitions.
 changements (instantané) d’états
 provoquées par des événements qui surviennent dans le
domaine du problème.
 représentées par des connexions unidirectionnelles entre
états.

S. KOUSSOUBE 177
 Concepts
 Evénements
 survenu d’une situation remarquable dans le domaine du
problème: réception d’un signal, d’un message, expriration
d’une temporisation, etc.
 Un événement est instantané (contrairement à l’état)
 La description d’un évènement comprend :
 nom de l’événement,
 liste des paramètres,
 objet expéditeur (déclencheur),
 objet destinataire,
 description de la signification des l’événement.

S. KOUSSOUBE 178
 Concepts
 Types d’Evénements
 Signaux
 Appels d’opérations
 Evénements temporels
 Evénements de changement

S. KOUSSOUBE 179
 Concepts
 Evènement de Signal: Evènement qui consiste à émettre ou
à recevoir un signal. Un signal = message entre objet
« signal »
ArrivéeDeVol
compagnie
numéroVol
provenance
« signal »
BoutonSourisEnfoncé
bouton
position

S. KOUSSOUBE 180
 Concepts
 Evènement temporel: causé par l’occurrence d’un temps
absolu (when) ou l’écoulement d’une durée (after)
 when (date = 01/04/2017)
 after (2 minutes)

S. KOUSSOUBE 181
 Concepts
 Evènement de changement: causé par la satisfaction d’une
expression booléenne(when)
 when (charge batterie < 15%)
 when(nombreInscrit  12)

S. KOUSSOUBE 182
 Concepts
 Garde (Condition de franchissement)
 Une condition qui valide ou non le déclenchement d’une
transition lors de la survenue d’un événement.
 Lorsque plusieurs transitions peuvent être déclenchées par
le même événement, les gardes permettent de maintenir le
caractère déterministe de l’automate
 Une condition de franchissement est évaluée une seule fois,
un événement de changement est évalué en permanence.
 Nom événement en italique, garde entre crochets.

S. KOUSSOUBE 183
état1
nomSignal
état2
nomOp(params)
after qtité temps
when(cond)

S. KOUSSOUBE 184
état
[garde] événement
état

S. KOUSSOUBE 185
état
[garde] événement
état
Transition d’achèvement: transition sans événement, transition
automatique, franchie dès que l’activité associée à l’état source est
achevée.

S. KOUSSOUBE 186
A
[C1] e
Remarques: C1,
C2 et C3 doivent
être
mutuellement
exclusives.
B
C
D
[C2] e
[C3] e

S. KOUSSOUBE 187
A
[C1]
B
C
D
[C2]
[C3]
e

S. KOUSSOUBE 188
Perte
Emploi
embauche
atteinte age limite
atteinte age retraite
enActivité
auChomage
àlaRetraite

S. KOUSSOUBE 189
 Concepts
 Opérations, Actions, Activités.
 Opérations des Classe  Actions ou Activités dans le DET
 Action:
 opération dont le temps d’exécution est négligeable par
rapport à la dynamique du système.
 peut être exécutée lorsque une transition est déclenchée par
un événement
 peut être exécutée à l’entrée, à la sortie, ou à l’intérieur d’un
état

S. KOUSSOUBE 190
 Concepts
 Opérations, Actions, Activités.
 Opérations des Classe  Actions ou Activités
 Activité
 opération dont le temps d’exécution n’est pas négligeable par
rapport à la dynamique du système.
 Exécutable dans un état

S. KOUSSOUBE 191
A
B
entry : action1
on e : action2
exit : action3
e/action

S. KOUSSOUBE 192
 Généralisation d’Etats.
 Principe d’abstraction qui permet de définir des états
généraux appelés super - états et des états plus
spécifiques (sous - états).
 approche permettant une maîtrise de la complexité des DET. La
généralisation simplifie par factorisation.
 Un Etat peut être décomposé en plusieurs sous - états disjoints.
Ces sous – états héritent des caractéristiques de leurs super –
états, en particulier les variables d’états et les transitions
externes.
 Un objet doit être dans un seul sous - état à un instant donné.
 Les transitions d’entrée ne sont pas héritées par tous les états.
Seul un état (le super-état ou un de ses sous-états) peut être
cible de la transition

S. KOUSSOUBE 193
 Généralisation d’Etats.
E1
E2
E2
A E1
AB
E2
C
B
A B
C

S. KOUSSOUBE 194
A
B
A
B
A
B1
B2
B1
B2

S. KOUSSOUBE 195
 Agrégation d’Etat.
 Composition d’un état à partir de plusieurs autres états
indépendants (conjonction d’états).
 L’objet doit être simultanément dans tous les états de la
conjonction
 L’agrégation simplifie par segmentation

S. KOUSSOUBE 196
X
e1
e2
e4 [in Z]
U
T
S
Z
Y
A
B
e3 e1
S = T x U. Une transition entrante dans S entraîne l’activation simultanée des
automates T et U ; l’objet est alors placé dans l’état (Z,A). Quand e3 survient l’objet
passe à l’état (X,A).

S. KOUSSOUBE 197
 Relation avec le Modèle des Classes
 Les états sont des classes d’équivalence des valeurs et des liens des
objets.
 Le modèle d’Etats spécifie les séquences possibles de modification
des objets du modèle de classe.
 Le diagramme d’Etats décrit tout ou partie du comportement des
objets d’une classe donnée.

S. KOUSSOUBE 198
Diagramme d’Activités

S. KOUSSOUBE 199
 Un diagramme d'activités représente la suite d’étapes qui constituent un
processus complexe (processus métier, algorithme, méthode, etc.) et les
contraintes de séquencement.
 Il exprime le flux de contrôle en se concentrant sur les opérations plutôt
que sur les objets.
 Les nœuds sont principalement les activités
 Certaines activités de déroulent en continu jusqu’à ce qu’un évènement
extérieur ne les interrompe, mais la plupart finissent par achever leur
travail et s’interrompent d’elles mêmes
Diagrammes d’Activité

S. KOUSSOUBE 200
 En UML 1.5, diagramme d’activité = DET simplifié dans lequel les
états se réduisent à des actions ou des activités avec des transitions
automatiques ou gardées
 En UML 2, le DET a un formalisme spécifique, plus détaillé, avec des
nœuds et des arcs de différentes natures.
 Le diagramme d’activités permet de décrire une séquence d’activités à
travers des décisions (branchement), des bifurcations (fork), des
jointures (join), des boucles (loop) jusqu’à ce que toutes les tâches
(actions) du comportement soient terminées ou qu’une exception
termine abruptement la séquence.

S. KOUSSOUBE 201
 Activité = comportement qui peut être décomposé en plusieurs
actions.
 Action = étape simple (non décomposée) d’une activité

S. KOUSSOUBE 202
 Nœuds de Contrôle
 Nœud initial : départ d’une activité
 Nœuds finaux:
 Nœud final d’activité : termine l’ensemble de l’activité
 Noeud final de flux : termine un chemin partiel d’exécution dans une activité
 Noeud de jonction (union) : synchronise plusieurs flux en un seul
 Noeud de débranchement (fourche) : scinde un flux en plusieurs flux
concurrentiels
 Noeud de décision : permet de sélectionner un flux de sortie en
fonction d’une expression
 Noeud de fusion (confluence) : permet de rassembler plusieurs flux
au sein d’un même flux de sortie

S. KOUSSOUBE 203
 Nœuds de Contrôle
 Nœud de « Temps » :
 Nœud d’action: représente un calcul ou une transformation
 Accepter un événement
 Envoyer un signal

S. KOUSSOUBE 204
Facturer le Client Livrer le Produit
Traiter Commande « précondition » vente terminée
« postcondition » produit livré
Activité Action

S. KOUSSOUBE 205

S. KOUSSOUBE 206

S. KOUSSOUBE 207
 Couloir d’Activité: sert à préciser dans le modèles, les entités
responsable de l’exécution d’une activité
 Si une activité a plus d’un successeur, chaque flèche sortante porte une
étiquette avec une condition entre crochets.

S. KOUSSOUBE 208
Diagramme de Paquetage

S. KOUSSOUBE 209
 Les Paquetages servent à organiser les éléments de
modélisation en groupes avec pour objectif de rendre les
diagrammes plus simples et faciles à comprendre.
 Utilisés principalement sur les diagrammes de classe et
les diagrammes de CU.
 Peuvent structurer n’importe quel type de diagramme

S. KOUSSOUBE 210
 Notation : Dossier
Nom

S. KOUSSOUBE 211
Construction description Syntaxe
Paquetage Un regroupement d’éléments
de modélisation
Import
Une dépendance indiquant que le
contenu public du paquetage
cible est ajouté dans l’espace de
nommage du source
Accès
Une dépendance indiquant que le
contenu public du paquetage
cible est disponible dans l’espace
de nommage du source
Nom
«import»
«access»

S. KOUSSOUBE 212
 Utilité:
 Créer une vue générale d’un grand ensemble
d’éléments de modélisation
 Organiser un modèle large
 Grouper des éléments liés
 Séparer les espaces de nommage

S. KOUSSOUBE 213
Diagramme de Paquetage.

S. KOUSSOUBE 214
Structuration du Modèle Conceptuel.
 Le diagramme de Paquetage des classes
organise de façon logique la conception.
 La structuration s’appuie sur deux principes
fondamentaux :
 cohérence ;
 indépendance.

S. KOUSSOUBE 215
Structuration du Modèle Conceptuel.
 Principe de Cohérence :
 Regrouper les classes proches d’un point de vue sémantique.
 Critères de cohérence :
 finalité : les classes doivent rendre des services de même nature
aux utilisateurs ;
 Cycle de vie des objets : distinguer les classes dont les objets ont
des durées de vie très différentes.
 évolution : isoler les classes réellement stables de celles qui vont
vraisemblablement évoluer au cours du projet, ou même par la
suite. On distingue notamment les classes métiers des classes
applicatives.
 Test: être capable de donner au paquetage un nom descriptif court.

S. KOUSSOUBE 216
Conceptuel.
 Principe d’ indépendance:
 Renforcer le découpage initial en s’efforçant de minimiser les
dépendances entre paquetages.
 lutter en particulier contre les dépendances cycliques

S. KOUSSOUBE 217
Conceptuel.
 Ainsi:
 les classes d’une même hiérarchie d’héritage appartiennent
(typiquement) au même paquetage
 Les classes liées par une relation d’agrégation/composition sont
souvent dans le même paquetage
 Les classes qui communiquent beaucoup entre elles – visible
sur le diagramme de séquence ou de communication –
appartiennent souvent au même paquetage
 Les classes d’un même Framework devraient être placées dans
un même paquetage

S. KOUSSOUBE 218
 Diagramme des composants vs
diagrammes des paquetages/classes
 Si on adopte une approche composant
(EJB, composant .Net, …), le diagramme
des composants permet de mieux
décrire la conception physique

S. KOUSSOUBE 219
Structuration du Modèle des
CU.
 Quelques Règles:
 CU inclus ou étendant sont souvent
regroupés
 CU base/parent appartiennent au même
paquetage
 Considérer les « objectifs fonctionnels » des
principaux acteurs comme des paquetages.
(avoir en tête le principe de cohérence)

S. KOUSSOUBE 221
Structuration des Modèles
 Principes
 Cohérence
 Indépendance
 Un diagramme : 7 +/- 2 nœuds(classes, cu,
…)

Présentation UML.ppt

Recommandé

Recommandé

Contenu connexe

Similaire à Présentation UML.ppt

Similaire à Présentation UML.ppt (20)

Dernier

Dernier (11)

Présentation UML.ppt