SlideShare une entreprise Scribd logo
1  sur  221
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
Méthode – Processus - Langage
Notation (Langage)
Outil
Processus
S. KOUSSOUBE 6
Méthode – Processus - Langage
 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
Développement - Modélisation
 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
Développement - Modélisation
 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 10
UML en Bref
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 14
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
 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
Modèle des Cas d’Utilisation
 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
Modèle des Cas d’Utilisation
 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
Modèle des Cas d’Utilisation
 Les Concepts:
 Acteur (Notation)
client
« actor »
Opérateur SYSCOMPTA
S. KOUSSOUBE 49
Modèle des Cas d’Utilisation
 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
Modèle des Cas d’Utilisation
 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
Modèle des Cas d’Utilisation
 Les Concepts:
 Cas d’Utilisation:
 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
Modèle des Cas d’Utilisation
 Les Concepts:
 Cas d’Utilisation:
 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
Relations des Acteurs et CU
C
B
Agent
« acteur »
SYSCOMPTA
A
Chef Service
S. KOUSSOUBE 56
Relations des Acteurs et CU
C
B
Agent
« acteur »
SYSCOMPTA
A
Chef Service
S. KOUSSOUBE 57
Relations des Acteurs et CU
C
B
Agent
D
« acteur »
SYSCOMPTA
E
A
Chef Service
S. KOUSSOUBE 58
Relations des Acteurs et CU
C
B
Agent
D
« acteur »
SYSCOMPTA
F
E
A
« include »
Chef Service
S. KOUSSOUBE 59
Relations des Acteurs et CU
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
Modèle des Cas d’Utilisation
 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
Modèle des Cas d’Utilisation
 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
Modèle des Cas d’Utilisation
 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
Modèle des Cas d’Utilisation
S. KOUSSOUBE 64
 Documentation des Cas d’Utilisation
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
Modèle des Cas d’Utilisation
S. KOUSSOUBE 65
Modèle des Cas d’Utilisation
 Documentation des Cas d’Utilisation
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
Modèle des Cas d’Utilisation
 Documentation des Cas d’Utilisation
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
Modèle des 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
Modèle des Cas d’Utilisation
 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 101
Interface
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
Classes Paramétrées (Templates)
 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
Classes Paramétrées (Templates)
 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
Autres catégories de Classe
 Enumération.
S. KOUSSOUBE 108
Autres catégories de Classe
 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
Associations Binaires
C1 C2
nom
C1
nom
Association
Réflexive
S. KOUSSOUBE 113
Associations Binaires
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
Classe - Association
Abonné Document
InfoPrêt
prête
datePrêt
S. KOUSSOUBE 117
Classe - Association
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
Associations particulières
 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
Associations particulières
 Composition vs Agrégation
Polygone Points
1 3..*
PptésGrahiques
Couleur
texture
S. KOUSSOUBE 126
Associations particulières
 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
Découverte des Classes
 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
Découverte des Classes
 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
Découverte des Classes
 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
Diagrammes de Séquence
 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
Diagrammes de Séquence
 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
Diagrammes de Séquence
 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
Diagrammes de Séquence
 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
Diagrammes de Séquence
 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
nom1 : Classe nom2 : Classe
Ligne de
vie
objet
S. KOUSSOUBE 149
nom1 : Classe nom2 : Classe
Activation
Ligne de
vie
objet
S. KOUSSOUBE 150
nom1 : Classe nom2 : Classe
Activation
Ligne de
vie Stimulus/message
nom(…)
objet
S. KOUSSOUBE 151
nom1 : Classe nom2 : Classe
Activation
Ligne de
vie Stimulus
Retour
nom(…)
Envoi réflexif
objet
S. KOUSSOUBE 152
nom1 : Classe nom2 : Classe
: Classe
Activation
Ligne de
vie Stimulus
Création
Retour
nouveau
nom(…)
Envoi réflexif
objet
S. KOUSSOUBE 153
nom1 : Classe nom2 : Classe
: Classe
Activation
Ligne de
vie Stimulus/message
Création
Retour
Destruction
nouveau
nom(…)
détruire
Envoi réflexif
objet
S. KOUSSOUBE 154
nom1 : Classe nom2 : Classe
: 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
Diagramme de Séquence
 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
Diagramme de Séquence
 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
Diagrammes de Communication
 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 164
S. KOUSSOUBE 165
S. KOUSSOUBE 166
Diagrammes de Communication
 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
Diagrammes de Communication
 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
Diagrammes d’Etats - Transitions
 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
Diagrammes d’Etats - Transitions
 Rappels sur les Automates Finis
 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
Diagrammes d’Etats - Transitions
 Rappels sur les Automates Finis
 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
Diagrammes d’Etats - Transitions
 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
Diagrammes d’Etats - Transitions
 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
Diagrammes d’Etats - Transitions
 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
Diagrammes d’Etats - Transitions
 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
Diagrammes d’Etats - Transitions
 Concepts
 Types d’Evénements
 Signaux
 Appels d’opérations
 Evénements temporels
 Evénements de changement
S. KOUSSOUBE 179
Diagrammes d’Etats - Transitions
 Concepts
 Types d’Evénements
 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
Diagrammes d’Etats - Transitions
 Concepts
 Types d’Evénements
 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
Diagrammes d’Etats - Transitions
 Concepts
 Types d’Evénements
 Evènement de changement: causé par la satisfaction d’une
expression booléenne(when)
 when (charge batterie < 15%)
 when(nombreInscrit  12)
S. KOUSSOUBE 182
Diagrammes d’Etats - Transitions
 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
Diagrammes d’Etats - Transitions
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
Diagrammes d’Etats - Transitions
S. KOUSSOUBE 191
A
B
entry : action1
on e : action2
exit : action3
e/action
Diagrammes d’Etats - Transitions
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
Diagrammes d’Etats - Transitions
S. KOUSSOUBE 193
 Généralisation d’Etats.
Diagrammes d’Etats - Transitions
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
Diagrammes d’Etats - Transitions
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.
Diagrammes d’Etats - Transitions
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.
Diagrammes d’Activité
S. KOUSSOUBE 201
 Activité = comportement qui peut être décomposé en plusieurs
actions.
 Action = étape simple (non décomposée) d’une activité
Diagrammes d’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
Diagrammes d’Activité
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
Diagrammes d’Activité
S. KOUSSOUBE 204
Diagrammes d’Activité
Facturer le Client Livrer le Produit
Traiter Commande « précondition » vente terminée
« postcondition » produit livré
Activité Action
S. KOUSSOUBE 205
Diagrammes d’Activité
S. KOUSSOUBE 206
Diagrammes d’Activité
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.
Diagrammes d’Activité
S. KOUSSOUBE 208
Diagramme de Paquetage
S. KOUSSOUBE 209
Diagramme de Paquetage
 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
Diagramme de Paquetage
 Notation : Dossier
Nom
S. KOUSSOUBE 211
Diagramme de Paquetage
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
Diagramme de Paquetage
 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
Structuration du Modèle
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
Structuration du Modèle
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 220
S. KOUSSOUBE 221
Structuration des Modèles
 Principes
 Cohérence
 Indépendance
 Un diagramme : 7 +/- 2 nœuds(classes, cu,
…)

Contenu connexe

Similaire à Présentation UML.ppt

Similaire à Présentation UML.ppt (20)

Splpv2 annexes-c
Splpv2 annexes-cSplpv2 annexes-c
Splpv2 annexes-c
 
UML3
UML3UML3
UML3
 
7 diagramme de cas d'utilisation
7 diagramme de cas d'utilisation7 diagramme de cas d'utilisation
7 diagramme de cas d'utilisation
 
diagramme de cas d'utilisation
diagramme de cas d'utilisationdiagramme de cas d'utilisation
diagramme de cas d'utilisation
 
cours2diagStatiq.pdf
cours2diagStatiq.pdfcours2diagStatiq.pdf
cours2diagStatiq.pdf
 
Definitiondesbesoinsuml
DefinitiondesbesoinsumlDefinitiondesbesoinsuml
Definitiondesbesoinsuml
 
SysML (Valtech Days 2008)
SysML (Valtech Days 2008)SysML (Valtech Days 2008)
SysML (Valtech Days 2008)
 
Introduction à Sysml
Introduction à SysmlIntroduction à Sysml
Introduction à Sysml
 
Chp1 - Introduction aux méthodologies de Conception
Chp1 - Introduction aux méthodologies de ConceptionChp1 - Introduction aux méthodologies de Conception
Chp1 - Introduction aux méthodologies de Conception
 
Cours Coosi
Cours CoosiCours Coosi
Cours Coosi
 
A SIMPLIFIED APPROACH FOR QUALITY.pdf
A SIMPLIFIED APPROACH FOR QUALITY.pdfA SIMPLIFIED APPROACH FOR QUALITY.pdf
A SIMPLIFIED APPROACH FOR QUALITY.pdf
 
Tp3 - UML
Tp3 - UMLTp3 - UML
Tp3 - UML
 
uml ikram elcaid.pdf
uml ikram elcaid.pdfuml ikram elcaid.pdf
uml ikram elcaid.pdf
 
Modelisation agile 03122011
Modelisation agile  03122011Modelisation agile  03122011
Modelisation agile 03122011
 
UML.pptx
UML.pptxUML.pptx
UML.pptx
 
Design patterns
Design patternsDesign patterns
Design patterns
 
Methodo support
Methodo supportMethodo support
Methodo support
 
srep_cours_06.pdf
srep_cours_06.pdfsrep_cours_06.pdf
srep_cours_06.pdf
 
Language de description d’architecture ACME
Language de description d’architecture ACMELanguage de description d’architecture ACME
Language de description d’architecture ACME
 
Manuel uml-poweramc
Manuel uml-poweramcManuel uml-poweramc
Manuel uml-poweramc
 

Dernier

Compersseur d'air a vis atlas copco avec huile
Compersseur d'air a vis atlas copco avec huileCompersseur d'air a vis atlas copco avec huile
Compersseur d'air a vis atlas copco avec huileMBouderbala
 
BOW 2024 - Logement des veaux laitiers en plein air
BOW 2024 - Logement des veaux laitiers en plein airBOW 2024 - Logement des veaux laitiers en plein air
BOW 2024 - Logement des veaux laitiers en plein airidelewebmestre
 
Agrivoltaïsme et filière ovine en Dordogne
Agrivoltaïsme et filière ovine en DordogneAgrivoltaïsme et filière ovine en Dordogne
Agrivoltaïsme et filière ovine en Dordogneidelewebmestre
 
BOW 2024 - 3-2 - Stress thermique impact vaches laitières
BOW 2024 - 3-2 - Stress thermique impact vaches laitièresBOW 2024 - 3-2 - Stress thermique impact vaches laitières
BOW 2024 - 3-2 - Stress thermique impact vaches laitièresidelewebmestre
 
Accompagnement de l'agrivoltaisme - Focus sur l'étude système en Merthe et Mo...
Accompagnement de l'agrivoltaisme - Focus sur l'étude système en Merthe et Mo...Accompagnement de l'agrivoltaisme - Focus sur l'étude système en Merthe et Mo...
Accompagnement de l'agrivoltaisme - Focus sur l'étude système en Merthe et Mo...idelewebmestre
 
Actions du vent sur les bâtiments selon lEurocode 1 – Partie 1-4.pdf
Actions du vent sur les bâtiments selon lEurocode 1 – Partie 1-4.pdfActions du vent sur les bâtiments selon lEurocode 1 – Partie 1-4.pdf
Actions du vent sur les bâtiments selon lEurocode 1 – Partie 1-4.pdfalainfahed961
 
Cours polymère presentation powerpoint 46 pages
Cours polymère presentation powerpoint 46 pagesCours polymère presentation powerpoint 46 pages
Cours polymère presentation powerpoint 46 pagesPierreFournier32
 
Cadre réglementaire et développement de l'agrivoltaïsme en France
Cadre réglementaire et développement de l'agrivoltaïsme en FranceCadre réglementaire et développement de l'agrivoltaïsme en France
Cadre réglementaire et développement de l'agrivoltaïsme en Franceidelewebmestre
 
BOW 2024 - 3-8 - Adaptation des bâtiments d'élevages de volailles au changeme...
BOW 2024 - 3-8 - Adaptation des bâtiments d'élevages de volailles au changeme...BOW 2024 - 3-8 - Adaptation des bâtiments d'élevages de volailles au changeme...
BOW 2024 - 3-8 - Adaptation des bâtiments d'élevages de volailles au changeme...idelewebmestre
 
BOW 2024 - 3-5 - Des solutions numériques pour se préparer aux pics de chaleur
BOW 2024 - 3-5 - Des solutions numériques pour se préparer aux pics de chaleurBOW 2024 - 3-5 - Des solutions numériques pour se préparer aux pics de chaleur
BOW 2024 - 3-5 - Des solutions numériques pour se préparer aux pics de chaleuridelewebmestre
 
SciencesPo_Aix_InnovationPédagogique_Atelier_APC.pdf
SciencesPo_Aix_InnovationPédagogique_Atelier_APC.pdfSciencesPo_Aix_InnovationPédagogique_Atelier_APC.pdf
SciencesPo_Aix_InnovationPédagogique_Atelier_APC.pdfSKennel
 
Bow 2024 - Plein air à l'intérieur des bâtiments d'élevage de ruminants
Bow 2024 - Plein air à l'intérieur des bâtiments d'élevage de ruminantsBow 2024 - Plein air à l'intérieur des bâtiments d'élevage de ruminants
Bow 2024 - Plein air à l'intérieur des bâtiments d'élevage de ruminantsidelewebmestre
 
BOW 2024 - L'enrichissement du milieu des chèvres laitières
BOW 2024 - L'enrichissement du milieu des chèvres laitièresBOW 2024 - L'enrichissement du milieu des chèvres laitières
BOW 2024 - L'enrichissement du milieu des chèvres laitièresidelewebmestre
 
BOW 2024 - Nouveaux modes de logement pour des veaux de boucherie avec accès ...
BOW 2024 - Nouveaux modes de logement pour des veaux de boucherie avec accès ...BOW 2024 - Nouveaux modes de logement pour des veaux de boucherie avec accès ...
BOW 2024 - Nouveaux modes de logement pour des veaux de boucherie avec accès ...idelewebmestre
 
BOW 2024 -3-9 - Matelas de logettes à eau refroidie VL
BOW 2024 -3-9 - Matelas de logettes à eau refroidie VLBOW 2024 -3-9 - Matelas de logettes à eau refroidie VL
BOW 2024 -3-9 - Matelas de logettes à eau refroidie VLidelewebmestre
 
BOW 2024 - Jardins d'hiver en poulets de chair
BOW 2024 - Jardins d'hiver en poulets de chairBOW 2024 - Jardins d'hiver en poulets de chair
BOW 2024 - Jardins d'hiver en poulets de chairidelewebmestre
 
BOW 2024 - L'écurie ouverte : un concept inspirant pour la filière équine
BOW 2024 - L'écurie ouverte : un concept inspirant pour la filière équineBOW 2024 - L'écurie ouverte : un concept inspirant pour la filière équine
BOW 2024 - L'écurie ouverte : un concept inspirant pour la filière équineidelewebmestre
 
BOW 24 - De la réflexion de groupe à l'immersion dans des bâtiments porcins
BOW 24 - De la réflexion de groupe à l'immersion dans des bâtiments porcinsBOW 24 - De la réflexion de groupe à l'immersion dans des bâtiments porcins
BOW 24 - De la réflexion de groupe à l'immersion dans des bâtiments porcinsidelewebmestre
 
BOW 2024 - Le bâtiment multicritère porcin
BOW 2024 - Le bâtiment multicritère porcinBOW 2024 - Le bâtiment multicritère porcin
BOW 2024 - Le bâtiment multicritère porcinidelewebmestre
 

Dernier (20)

Compersseur d'air a vis atlas copco avec huile
Compersseur d'air a vis atlas copco avec huileCompersseur d'air a vis atlas copco avec huile
Compersseur d'air a vis atlas copco avec huile
 
BOW 2024 - Logement des veaux laitiers en plein air
BOW 2024 - Logement des veaux laitiers en plein airBOW 2024 - Logement des veaux laitiers en plein air
BOW 2024 - Logement des veaux laitiers en plein air
 
Agrivoltaïsme et filière ovine en Dordogne
Agrivoltaïsme et filière ovine en DordogneAgrivoltaïsme et filière ovine en Dordogne
Agrivoltaïsme et filière ovine en Dordogne
 
BOW 2024 - 3-2 - Stress thermique impact vaches laitières
BOW 2024 - 3-2 - Stress thermique impact vaches laitièresBOW 2024 - 3-2 - Stress thermique impact vaches laitières
BOW 2024 - 3-2 - Stress thermique impact vaches laitières
 
Accompagnement de l'agrivoltaisme - Focus sur l'étude système en Merthe et Mo...
Accompagnement de l'agrivoltaisme - Focus sur l'étude système en Merthe et Mo...Accompagnement de l'agrivoltaisme - Focus sur l'étude système en Merthe et Mo...
Accompagnement de l'agrivoltaisme - Focus sur l'étude système en Merthe et Mo...
 
Actions du vent sur les bâtiments selon lEurocode 1 – Partie 1-4.pdf
Actions du vent sur les bâtiments selon lEurocode 1 – Partie 1-4.pdfActions du vent sur les bâtiments selon lEurocode 1 – Partie 1-4.pdf
Actions du vent sur les bâtiments selon lEurocode 1 – Partie 1-4.pdf
 
Cours polymère presentation powerpoint 46 pages
Cours polymère presentation powerpoint 46 pagesCours polymère presentation powerpoint 46 pages
Cours polymère presentation powerpoint 46 pages
 
Note agro-climatique n°2 - 17 Avril 2024
Note agro-climatique n°2 - 17 Avril 2024Note agro-climatique n°2 - 17 Avril 2024
Note agro-climatique n°2 - 17 Avril 2024
 
Cadre réglementaire et développement de l'agrivoltaïsme en France
Cadre réglementaire et développement de l'agrivoltaïsme en FranceCadre réglementaire et développement de l'agrivoltaïsme en France
Cadre réglementaire et développement de l'agrivoltaïsme en France
 
BOW 2024 - 3-8 - Adaptation des bâtiments d'élevages de volailles au changeme...
BOW 2024 - 3-8 - Adaptation des bâtiments d'élevages de volailles au changeme...BOW 2024 - 3-8 - Adaptation des bâtiments d'élevages de volailles au changeme...
BOW 2024 - 3-8 - Adaptation des bâtiments d'élevages de volailles au changeme...
 
BOW 2024 - 3-5 - Des solutions numériques pour se préparer aux pics de chaleur
BOW 2024 - 3-5 - Des solutions numériques pour se préparer aux pics de chaleurBOW 2024 - 3-5 - Des solutions numériques pour se préparer aux pics de chaleur
BOW 2024 - 3-5 - Des solutions numériques pour se préparer aux pics de chaleur
 
SciencesPo_Aix_InnovationPédagogique_Atelier_APC.pdf
SciencesPo_Aix_InnovationPédagogique_Atelier_APC.pdfSciencesPo_Aix_InnovationPédagogique_Atelier_APC.pdf
SciencesPo_Aix_InnovationPédagogique_Atelier_APC.pdf
 
Bow 2024 - Plein air à l'intérieur des bâtiments d'élevage de ruminants
Bow 2024 - Plein air à l'intérieur des bâtiments d'élevage de ruminantsBow 2024 - Plein air à l'intérieur des bâtiments d'élevage de ruminants
Bow 2024 - Plein air à l'intérieur des bâtiments d'élevage de ruminants
 
BOW 2024 - L'enrichissement du milieu des chèvres laitières
BOW 2024 - L'enrichissement du milieu des chèvres laitièresBOW 2024 - L'enrichissement du milieu des chèvres laitières
BOW 2024 - L'enrichissement du milieu des chèvres laitières
 
BOW 2024 - Nouveaux modes de logement pour des veaux de boucherie avec accès ...
BOW 2024 - Nouveaux modes de logement pour des veaux de boucherie avec accès ...BOW 2024 - Nouveaux modes de logement pour des veaux de boucherie avec accès ...
BOW 2024 - Nouveaux modes de logement pour des veaux de boucherie avec accès ...
 
BOW 2024 -3-9 - Matelas de logettes à eau refroidie VL
BOW 2024 -3-9 - Matelas de logettes à eau refroidie VLBOW 2024 -3-9 - Matelas de logettes à eau refroidie VL
BOW 2024 -3-9 - Matelas de logettes à eau refroidie VL
 
BOW 2024 - Jardins d'hiver en poulets de chair
BOW 2024 - Jardins d'hiver en poulets de chairBOW 2024 - Jardins d'hiver en poulets de chair
BOW 2024 - Jardins d'hiver en poulets de chair
 
BOW 2024 - L'écurie ouverte : un concept inspirant pour la filière équine
BOW 2024 - L'écurie ouverte : un concept inspirant pour la filière équineBOW 2024 - L'écurie ouverte : un concept inspirant pour la filière équine
BOW 2024 - L'écurie ouverte : un concept inspirant pour la filière équine
 
BOW 24 - De la réflexion de groupe à l'immersion dans des bâtiments porcins
BOW 24 - De la réflexion de groupe à l'immersion dans des bâtiments porcinsBOW 24 - De la réflexion de groupe à l'immersion dans des bâtiments porcins
BOW 24 - De la réflexion de groupe à l'immersion dans des bâtiments porcins
 
BOW 2024 - Le bâtiment multicritère porcin
BOW 2024 - Le bâtiment multicritère porcinBOW 2024 - Le bâtiment multicritère porcin
BOW 2024 - Le bâtiment multicritère porcin
 

Présentation UML.ppt

  • 1. S. KOUSSOUBE 1 Modélisation Objet avec UML (Unified Modeling Language)
  • 2. 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
  • 3. S. KOUSSOUBE 3 Méthodes – Processus- Langages.
  • 4. 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
  • 5. S. KOUSSOUBE 5 Méthode – Processus - Langage Notation (Langage) Outil Processus
  • 6. S. KOUSSOUBE 6 Méthode – Processus - Langage  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.
  • 7. 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.
  • 8. S. KOUSSOUBE 8 Développement - Modélisation  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é.
  • 9. S. KOUSSOUBE 9 Développement - Modélisation  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.
  • 11. S. KOUSSOUBE 11 UML en Bref  un langage pour :  spécifier,  visualiser,  construire,  et documenter les éléments d’un système logiciel.
  • 12. 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/)
  • 13. 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)
  • 15. 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)
  • 16. 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.)
  • 17. 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
  • 18. 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.
  • 19. 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.
  • 20. 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
  • 21. 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
  • 22. 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.
  • 23. 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
  • 24. 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
  • 25. S. KOUSSOUBE 25 Mécanismes Généraux d’Extension.
  • 26. S. KOUSSOUBE 26 Meta modèle UML
  • 29. S. KOUSSOUBE 29 Model Management Behavioral Elements Core Extension Mechanisms Data Types Foundation Meta modèle UML
  • 30. 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
  • 31. 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 }
  • 34. S. KOUSSOUBE 34 Personne Compagnie employé employeur chef agent
  • 35. S. KOUSSOUBE 35 Personne Compagnie employé employeur Il s’agit d’une personnalité morale chef agent
  • 36. S. KOUSSOUBE 36 Personne Compagnie employé employeur {Peronne.employeur = Personne.chef.employeur } chef agent Il s’agit d’une personnalité morale
  • 37. 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
  • 38. 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
  • 39. 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 .
  • 40. S. KOUSSOUBE 40 Élément de Modélisation Stéréotype Propriétés
  • 41. S. KOUSSOUBE 41 Élément de Modélisation Stéréotype Propriétés Classe ClassePersistente
  • 42. 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 »}
  • 43. S. KOUSSOUBE 43 Classes Stéréotypés « persistent » Compte « control » CompteManager
  • 44. S. KOUSSOUBE 44 Modèle des Cas d’Utilisation
  • 45. S. KOUSSOUBE 45 Modèle des Cas d’Utilisation  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.
  • 46. S. KOUSSOUBE 46 Modèle des Cas d’Utilisation  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
  • 47. S. KOUSSOUBE 47 Modèle des Cas d’Utilisation  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.
  • 48. S. KOUSSOUBE 48 Modèle des Cas d’Utilisation  Les Concepts:  Acteur (Notation) client « actor » Opérateur SYSCOMPTA
  • 49. S. KOUSSOUBE 49 Modèle des Cas d’Utilisation  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.
  • 50. S. KOUSSOUBE 50 Modèle des Cas d’Utilisation  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
  • 51. S. KOUSSOUBE 51 Cas d’Utilisation - Notation <nom> ouvrirCompte
  • 52. S. KOUSSOUBE 52 Modèle des Cas d’Utilisation  Les Concepts:  Cas d’Utilisation:  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.
  • 53. S. KOUSSOUBE 53 Modèle des Cas d’Utilisation  Les Concepts:  Cas d’Utilisation:  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?
  • 54. S. KOUSSOUBE 54 Relations des Acteurs et CU Agent « acteur » SYSCOMPTA Chef Service
  • 55. S. KOUSSOUBE 55 Relations des Acteurs et CU C B Agent « acteur » SYSCOMPTA A Chef Service
  • 56. S. KOUSSOUBE 56 Relations des Acteurs et CU C B Agent « acteur » SYSCOMPTA A Chef Service
  • 57. S. KOUSSOUBE 57 Relations des Acteurs et CU C B Agent D « acteur » SYSCOMPTA E A Chef Service
  • 58. S. KOUSSOUBE 58 Relations des Acteurs et CU C B Agent D « acteur » SYSCOMPTA F E A « include » Chef Service
  • 59. S. KOUSSOUBE 59 Relations des Acteurs et CU C B Agent D G « acteur » SYSCOMPTA F E A Points d’Extension : Infocomp, ExamenSupl « extend » (ExamSupl) « include » sémantique Chef Service
  • 60. S. KOUSSOUBE 60 Modèle des Cas d’Utilisation  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.
  • 61. S. KOUSSOUBE 61 Modèle des Cas d’Utilisation  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
  • 62. S. KOUSSOUBE 62 Modèle des Cas d’Utilisation  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.)
  • 63. 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 Modèle des Cas d’Utilisation
  • 64. S. KOUSSOUBE 64  Documentation des Cas d’Utilisation 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 Modèle des Cas d’Utilisation
  • 65. S. KOUSSOUBE 65 Modèle des Cas d’Utilisation  Documentation des Cas d’Utilisation 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.
  • 66. S. KOUSSOUBE 66 Modèle des Cas d’Utilisation  Documentation des Cas d’Utilisation 3- Diagramme de Séquence Système.  système = Une boîte noire ;  les éventuels acteurs secondaires sollicités  Acteur principal à gauche ;
  • 67. S. KOUSSOUBE 67 Cas d’Utilisation Modèle des Cas d’Utilisation Documentation des Cas d’Utilisation
  • 68. S. KOUSSOUBE 68 Texte Cas d’Utilisation
  • 69. S. KOUSSOUBE 69 Texte Cas d’Utilisation activité activité activité
  • 70. S. KOUSSOUBE 70 Texte Cas d’Utilisation Scénario activité activité activité
  • 71. S. KOUSSOUBE 71 Texte Cas d’Utilisation Scénario Syst activité activité activité
  • 72. S. KOUSSOUBE 72 Modèle des Cas d’Utilisation  Etapes:  Commence à l’étape de Pré étude (« Inception »)  Affiné et complété lors de l’étape d’Élaboration.
  • 73. S. KOUSSOUBE 73 Diagrammes de la structure Statique
  • 74. 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)
  • 75. 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.
  • 76. S. KOUSSOUBE 76 Le Diagramme des Classes  Exemple d’organisation en paquetages Gestion des Clients Gestion des Fournisseurs
  • 77. 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.
  • 78. 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
  • 79. 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
  • 81. 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}
  • 82. 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
  • 83. 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
  • 84. 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
  • 85. 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)
  • 86. 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)
  • 88. 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.
  • 89. 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.
  • 90. S. KOUSSOUBE 90 Classes  Stéréotypes Boundary « boundary » FenCréationCompte « boundary » Impression FenCréationCompte
  • 91. 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
  • 92. S. KOUSSOUBE 92  Stéréotypes Entity : « entity » Compte « entity » Catalogue Facture Classes
  • 93. 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
  • 94. S. KOUSSOUBE 94  Stéréotypes Control « control» CompteManager FactureManager Classes
  • 95. 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
  • 96. S. KOUSSOUBE 96 Stéréotype Utilité. « utility » FonctionMaths sin(Angle) :Real cosin(Angle) :Real sqrt(Real) : Real Classes
  • 97. 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
  • 98. 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.
  • 99. 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.
  • 100. 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)
  • 102. 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
  • 103. S. KOUSSOUBE 103 Classes Paramétrées (Templates)  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 
  • 104. S. KOUSSOUBE 104 Classes Paramétrées (Templates)  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>
  • 105. S. KOUSSOUBE 105 LARRAY T, K:integer StudentList « bind »(Student, 36) LARRAY<Point, 9> Exemple
  • 106. 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.
  • 107. S. KOUSSOUBE 107 Autres catégories de Classe  Enumération.
  • 108. S. KOUSSOUBE 108 Autres catégories de Classe  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}
  • 109. 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, …)
  • 110. 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)
  • 112. S. KOUSSOUBE 112 Associations Binaires C1 C2 nom C1 nom Association Réflexive
  • 113. S. KOUSSOUBE 113 Associations Binaires Personne Compagnie employé employeur agent chef
  • 114. S. KOUSSOUBE 114 Associations Ternaires Commande Produit Client commande
  • 115. S. KOUSSOUBE 115 Classe - Association Abonné Document InfoPrêt prête date • Association ayant des attributs et promue aussi en classe
  • 116. S. KOUSSOUBE 116 Classe - Association Abonné Document InfoPrêt prête datePrêt
  • 117. S. KOUSSOUBE 117 Classe - Association Abonné Document prête datePrêt
  • 118. 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
  • 119. 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é
  • 120. S. KOUSSOUBE 120 Association: Extrémités A B Multiplicité A Multiplicité B Rôle A Rôle B nom
  • 121. S. KOUSSOUBE 121 Exemples Fenêtre Ecran ordered visible sur 1 * Parcours Ville sequence * 1
  • 122. 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)
  • 123. 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..*
  • 124. S. KOUSSOUBE 124 Associations particulières  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).
  • 125. S. KOUSSOUBE 125 Associations particulières  Composition vs Agrégation Polygone Points 1 3..* PptésGrahiques Couleur texture
  • 126. S. KOUSSOUBE 126 Associations particulières  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.
  • 127. S. KOUSSOUBE 127 Généralisation Arbre Okoumé Ozigo {disjoint, incomplet}
  • 128. 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
  • 129. S. KOUSSOUBE 129 Découverte des Classes  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
  • 130. S. KOUSSOUBE 130 Découverte des Classes  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.
  • 131. S. KOUSSOUBE 131 Découverte des Classes  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)
  • 132. S. KOUSSOUBE 132 Niveaux de Détail des Classes  Différents modèles:  Classe d’Analyse  Classe de Conception  Classe d’Implémentation
  • 133. S. KOUSSOUBE 133 Structuration du Modèle Conceptuel.  Voir diagramme de Paquetage
  • 134. 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.
  • 135. 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
  • 136. S. KOUSSOUBE 136 Diagramme d’objet Points = ((0,0) , (4,0),(4,3)) Couleur = vert Couleurfond= rouge triangle1: Polygone : Polygone triangle1: Polygone
  • 137. S. KOUSSOUBE 137 Diagramme d’objet : C t1: C r1 r2
  • 138. 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.
  • 139. S. KOUSSOUBE 139 Diagrammes d’interactions
  • 140. 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)
  • 141. 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 )
  • 142. S. KOUSSOUBE 142 Diagrammes de Séquence  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, …)
  • 143. S. KOUSSOUBE 143 Diagrammes de Séquence  Plusieurs niveaux de détail:  Niveau système : interaction entre les acteurs et le système;  Niveau objet (plus détaillé)  Niveau méthode;
  • 144. S. KOUSSOUBE 144 Diagrammes de Séquence  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
  • 145. S. KOUSSOUBE 145 Diagrammes de Séquence  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
  • 146. S. KOUSSOUBE 146 Diagrammes de Séquence  Constituants:  stéréotypes  Classifieurs: « acteur », « contrôleur », « UI » etc.  Messages : « créer », « détruire »  Stéréotypes visuels
  • 147. S. KOUSSOUBE 147 nom1 : Classe nom2 : Classe objet
  • 148. S. KOUSSOUBE 148 nom1 : Classe nom2 : Classe Ligne de vie objet
  • 149. S. KOUSSOUBE 149 nom1 : Classe nom2 : Classe Activation Ligne de vie objet
  • 150. S. KOUSSOUBE 150 nom1 : Classe nom2 : Classe Activation Ligne de vie Stimulus/message nom(…) objet
  • 151. S. KOUSSOUBE 151 nom1 : Classe nom2 : Classe Activation Ligne de vie Stimulus Retour nom(…) Envoi réflexif objet
  • 152. S. KOUSSOUBE 152 nom1 : Classe nom2 : Classe : Classe Activation Ligne de vie Stimulus Création Retour nouveau nom(…) Envoi réflexif objet
  • 153. S. KOUSSOUBE 153 nom1 : Classe nom2 : Classe : Classe Activation Ligne de vie Stimulus/message Création Retour Destruction nouveau nom(…) détruire Envoi réflexif objet
  • 154. S. KOUSSOUBE 154 nom1 : Classe nom2 : Classe : Classe Activation Ligne de vie Stimulus Création Retour Destruction nouveau nom(…) détruire Envoi réflexif objet : Classe Message asynchrone
  • 155. 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
  • 156. 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
  • 157. S. KOUSSOUBE 157 Diagramme de Séquence  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 »
  • 158. S. KOUSSOUBE 158 Diagramme de Séquence  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
  • 159. 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
  • 160. S. KOUSSOUBE 160 Diagrammes de Communication  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
  • 161. 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
  • 162. S. KOUSSOUBE 162 : Cabine : Ascenseur : Porte : Lumière 1 : monter 3 : fermer 2 : allumer
  • 166. S. KOUSSOUBE 166 Diagrammes de Communication  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
  • 167. S. KOUSSOUBE 167 Diagrammes de Communication  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
  • 168. S. KOUSSOUBE 168 Diagrammes d’États - Transitions
  • 169. 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)
  • 170. S. KOUSSOUBE 170 Diagrammes d’Etats - Transitions  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
  • 171. S. KOUSSOUBE 171 Diagrammes d’Etats - Transitions  Rappels sur les Automates Finis  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
  • 172. S. KOUSSOUBE 172 Diagrammes d’Etats - Transitions  Rappels sur les Automates Finis  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
  • 173. S. KOUSSOUBE 173 Diagrammes d’Etats - Transitions  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
  • 174. S. KOUSSOUBE 174 Diagrammes d’Etats - Transitions  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..
  • 175. 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é
  • 176. S. KOUSSOUBE 176 Diagrammes d’Etats - Transitions  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.
  • 177. S. KOUSSOUBE 177 Diagrammes d’Etats - Transitions  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.
  • 178. S. KOUSSOUBE 178 Diagrammes d’Etats - Transitions  Concepts  Types d’Evénements  Signaux  Appels d’opérations  Evénements temporels  Evénements de changement
  • 179. S. KOUSSOUBE 179 Diagrammes d’Etats - Transitions  Concepts  Types d’Evénements  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
  • 180. S. KOUSSOUBE 180 Diagrammes d’Etats - Transitions  Concepts  Types d’Evénements  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)
  • 181. S. KOUSSOUBE 181 Diagrammes d’Etats - Transitions  Concepts  Types d’Evénements  Evènement de changement: causé par la satisfaction d’une expression booléenne(when)  when (charge batterie < 15%)  when(nombreInscrit  12)
  • 182. S. KOUSSOUBE 182 Diagrammes d’Etats - Transitions  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.
  • 184. S. KOUSSOUBE 184 état [garde] événement état
  • 185. 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.
  • 186. S. KOUSSOUBE 186 A [C1] e Remarques: C1, C2 et C3 doivent être mutuellement exclusives. B C D [C2] e [C3] e
  • 188. S. KOUSSOUBE 188 Perte Emploi embauche atteinte age limite atteinte age retraite enActivité auChomage àlaRetraite
  • 189. 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 Diagrammes d’Etats - Transitions
  • 190. 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 Diagrammes d’Etats - Transitions
  • 191. S. KOUSSOUBE 191 A B entry : action1 on e : action2 exit : action3 e/action Diagrammes d’Etats - Transitions
  • 192. 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 Diagrammes d’Etats - Transitions
  • 193. S. KOUSSOUBE 193  Généralisation d’Etats. Diagrammes d’Etats - Transitions E1 E2 E2 A E1 AB E2 C B A B C
  • 195. 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 Diagrammes d’Etats - Transitions
  • 196. 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).
  • 197. 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. Diagrammes d’Etats - Transitions
  • 198. S. KOUSSOUBE 198 Diagramme d’Activités
  • 199. 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é
  • 200. 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. Diagrammes d’Activité
  • 201. S. KOUSSOUBE 201  Activité = comportement qui peut être décomposé en plusieurs actions.  Action = étape simple (non décomposée) d’une activité Diagrammes d’Activité
  • 202. 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 Diagrammes d’Activité
  • 203. 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 Diagrammes d’Activité
  • 204. S. KOUSSOUBE 204 Diagrammes d’Activité Facturer le Client Livrer le Produit Traiter Commande « précondition » vente terminée « postcondition » produit livré Activité Action
  • 205. S. KOUSSOUBE 205 Diagrammes d’Activité
  • 206. S. KOUSSOUBE 206 Diagrammes d’Activité
  • 207. 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. Diagrammes d’Activité
  • 208. S. KOUSSOUBE 208 Diagramme de Paquetage
  • 209. S. KOUSSOUBE 209 Diagramme de Paquetage  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
  • 210. S. KOUSSOUBE 210 Diagramme de Paquetage  Notation : Dossier Nom
  • 211. S. KOUSSOUBE 211 Diagramme de Paquetage 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»
  • 212. S. KOUSSOUBE 212 Diagramme de Paquetage  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
  • 213. S. KOUSSOUBE 213 Diagramme de Paquetage.
  • 214. 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.
  • 215. 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.
  • 216. S. KOUSSOUBE 216 Structuration du Modèle 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
  • 217. S. KOUSSOUBE 217 Structuration du Modèle 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
  • 218. 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
  • 219. 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)
  • 221. S. KOUSSOUBE 221 Structuration des Modèles  Principes  Cohérence  Indépendance  Un diagramme : 7 +/- 2 nœuds(classes, cu, …)