Vous êtes sur la page 1sur 40
Unified Modeling Language Langage unifié pour la modélisation objet INTRODUCTION USTHB – Cycle Ingénieur Cours
Unified Modeling Language
Langage unifié pour la modélisation objet
INTRODUCTION
USTHB – Cycle Ingénieur
Cours 5 ème Année 2010-2011
Présenté par
Dr. Kamel Boukhalfa
Dr. Latifa Mahdaoui
11
22
Des Modèles plutôt que du Code Comment Modéliser ?  Un modèle est la simplification/abstraction
Des Modèles plutôt que du Code
Comment Modéliser ?
 Un modèle est la simplification/abstraction de la
réalité
 Le choix de quel modèle faut-il créer a une profonde
influence sur quelle manière le problème est traité et la
solution obtenue
 Nous construisons donc des modèles afin de mieux
comprendre les systèmes que nous développons
 Chaque model doit être exprimé à différents niveaux de
précision
 Nous modélisons des systèmes complexes parce que
nous somme incapables de les comprendre dans leur
totalité
 Les meilleurs modèles sont ceux qui sont connecté à la
réalité
 Le code ne permet pas de simplifier/abstraire la réalité
 Un seul modèle est souvent insuffisant. Un système
complexe est représenté par un ensemble de petits
modèles.
Notation & Méthode
33
44
Des Méthodes de modélisation Trop de Méthodes  L’apparition du paradigme objet à permis la
Des Méthodes de modélisation
Trop de Méthodes
 L’apparition du paradigme objet à permis
la naissance de plusieurs méthodes de
modélisation
 Entre 89 et 94 : le nombre de méthodes orientées
objet est passé de 10 à plus de 50
 Toutes les méthodes avaient pourtant d’énormes
points communs (objets, méthode, paramètres, …)
◦ OMT, OOSE, Booch, Fusion, …
 Chacune de ces méthodes fournie une
notation graphique et des règles pour
élaborer les modèles
 Au milieu des années 90, G. Booch, I. Jacobson et J.
Rumbaugh ont chacun commencé à adopter les
idées des autres. Les 3 auteurs ont souhaité créer
un langage de modélisation unifié
 Certaines méthodes sont outillées
55
66
Principales étapes de la définition d’UML Principales influences  Booch - catégories et sous-systèmes UML
Principales étapes de la définition d’UML
Principales influences
 Booch - catégories et sous-systèmes
UML 2
 Embley - classes singletons et objets composites
Soumission OMG
UML 1.3
juin 1999
 Fusion - description des opérations, numérotation des messages
UML 1.2
juin 1998
 Gamma - frameworks, patterns et notes
Standardisation OMG
Soumission OMG
UML 1.1
Novembre 1997
 Harel - automates (statecharts)
Septembre 1997
Soumission OMG
 Jacobson - cas d’utilisation (use cases)
UML 1.0
Janvier 1997
 Meyer - pré et post conditions
OOPSLA ‘ 96
UML 0.9
Juin 1996
 Odell - classification dynamique, éclairage sur les événements
OOPSLA ‘ 95
Méthode Unifiée 0.8
Octobre 1995
 OMT - associations
 Shlear-Mellor - cycle de vie des objets
Booch ’93
OMT-2
 Wirfs-Brock - responsabilités (CRC)
Autres
Booch ’91
OMT-1
Objectory
Partenaires
méthodes
77
88
UML ? Objectifs d’UML  Proposer un langage visuel de modélisation  C’est:  Utilisable
UML ?
Objectifs d’UML
 Proposer un langage visuel de modélisation
 C’est:
 Utilisable par toutes les méthodes
◦ Une notation, un langage de modélisation
objet
 Adapté à toutes les phases du développement
 Compatible avec toutes les techniques de réalisation
◦ Une description complète, évolutive, publique
 Proposer des mécanismes d’extension et de spécialisation pour pouvoir
étendre les concepts de base
 Être indépendant des langages particuliers de programmation
◦ Un standard, utilisé par des AGL
 Proposer une base formelle pour comprendre le langage de modélisation
 Ce n’est pas :
 Encourager l’application des outils OO
◦ Une méthodologie
 Supporter les concepts de développement de haut-niveau tels que les
frameworks, les patterns et les composants
◦ Un langage de programmation
 Intégrer les résultats de la pratique
99
1010
Diagrammes d’UML Diagrammes UML et vues Diagramme Diagrammes de classes Diagrammes d'objets Diagrammes de
Diagrammes d’UML
Diagrammes UML et vues
Diagramme
Diagrammes de classes
Diagrammes d'objets
Diagrammes de composantes
Composants
Classes
Séquence
Activités
Objets
Diagrammes d'états
Diagramme des cas
Diagrammes de déploiement
Déploiement
Cas d’utilisation
Etats-Transitions
Collaboration
Diagrammes d'activités
Diagrammes de séquence
Diagrammes de collaboration
1111
1212
Processus d'ingénierie sous-jacent Relations entre diagrammes et étapes du processus Découverte des besoins
Processus d'ingénierie sous-jacent
Relations entre diagrammes et étapes du processus
Découverte des besoins
Modèle
des cas
d’utilisation
 Diagramme de cas d’utilisation: décrit les fonctions du
spécialisé par
Modèle
réalisé par
système selon le point de vue de ses utilisateurs futurs
d’Analyse
Modèle de
distribué par
 Diagramme de séquence: représentation des
Conception
réalisé par
Modèle de
interactions temporelles entre objets dans la réalisation
Déploiement
vérifié par
Modèle de
Réalisation
d'une interaction homme-système
Modèle de
Test
1313
1414
Relations entre diagrammes et étapes du processus Relations entre diagrammes et étapes du processus Analyse
Relations entre diagrammes et étapes du processus
Relations entre diagrammes et étapes du processus
Analyse
Conception :
 Diagramme de classes : structure des données du système
définie comme un ensemble de relations entre classes
 Diagramme d’objets : illustration des objets et de leurs
relations
 Diagramme de séquence: représentation des
interactions temporelles entre objets dans la
réalisation d'une opération
 Diagramme de collaboration : représentation des interactions
entre objets
 Diagramme d’états-transitions : représentation du
comportement des objets d'une classe en termes d’états et de
transitions d'états
 Diagramme de déploiement : description du
déploiement des composants sur les dispositifs
matériels
 Diagrammes de composants : architecture des
composants physiques d'une application
 Diagramme d’activités : structure d'une opération en actions
1515
1616
Définition  Un diagramme de cas présente un ensemble d'acteurs et de cas d'utilisation avec
Définition
 Un diagramme de cas présente un
ensemble d'acteurs et de cas d'utilisation
avec leurs relations.
DIAGRAMMES DES CAS
D’UTILISATION
1
8
1717
1818
Acteur Représentation graphique d'un acteur  Un acteur est la description d'un ensemble cohérent de
Acteur
Représentation graphique d'un acteur
 Un acteur est la description d'un ensemble
cohérent de rôles qu'un utilisateur
(personne ou système) joue lorsqu'il
interagit avec le système.
Un acteur est une classe stéréotypée
représentée par un rectangle avec le
stéréotype «acteur» ou par une icône.
 Exemple :
<<acteur>>
Bibliothéquaire
Client
<<acteur>>
Bibliothéquaire
Client
1919
2020
Nommer un acteur Généralisation entre acteurs  Chaque acteur doit avoir un nom qui le
Nommer un acteur
Généralisation entre acteurs
 Chaque acteur doit avoir un nom qui le distingue des
autres acteurs.
 Les acteurs peuvent avoir des associations
de généralisation
 En pratique les noms de acteurs sont des noms pris dans
 Exemple :
le vocabulaire du domaine.
Client
 Il est d'usage de capitaliser la première lettre de chaque
mot.
<<acteur>>
ClientBanque
PréposéBanque
Particulier
Entreprise
2121
2222
Cas d'utilisation Représentation graphique d'un cas  Un cas est est une classe qui représente
Cas d'utilisation
Représentation graphique d'un cas
 Un cas est est une classe qui représente un
ensemble de fonctions ou de
comportements fournis par un système à
un ou des acteurs.
 Un cas est représenté par une ellipse
 un ensemble de cas peut être placé dans
un rectangle qui symbolise le système
 Exemple :
Signer Contrat Assurance
Acheter Automobile
2323
2424
Nommer un cas Généralisation  Chaque cas doit avoir un nom qui le distingue des
Nommer un cas
Généralisation
 Chaque cas doit avoir un nom qui le distingue
des autres cas - Unicité du nom complet (noms
des packages englobant + le nom du cas).
 L'association de généralisation entre cas
d'utilisation a la même sémantique que
pour les classes
 En pratique les noms de cas sont des verbes pris
dans le vocabulaire du domaine.
Valider usager
Emprunter Livre
Vérifier
mot de passe
Scanner
Accorder Crédit
rétine
2525
2626
« communique » « étend »  La relation communique permet de modéliser les échanges
« communique »
« étend »
 La relation communique permet de
modéliser les échanges de messages entre
acteurs et cas d'utilisation
La relation étend permet de modéliser un
comportement exceptionnel d'un cas
d'utilisation
<<étend>>
Traiter une
Traiter une
<<communique>>
commande
commande
Cas
urgente
Acteur
2727
2828
« inclut »  La relation inclut permet de modéliser l'inclusion de cas d'utilisation pour
« inclut »
 La relation inclut permet de modéliser
l'inclusion de cas d'utilisation pour éviter
les répétitions
DIAGRAMMES DE CLASSES
ET DIAGRAMMES D'OBJETS
<<inclut>>
Valider
Traiter une
Utilisateur
commande
2929
3030
Diagrammes de classes et d'objets Classe Une classe est une description abstraite d’un ensemble Un
Diagrammes de classes et d'objets
Classe
Une classe est une description abstraite d’un ensemble
Un diagramme de classes représente la structure du système
d’objets ayant des propriétés similaires, un comportement
en termes de classes et de relations entre ces classes; Un
commun, des relations communes avec d’autres objets et
diagramme d'objets illustre les objets et leurs relations
des sémantiques communes
Instance de
Classe
Objet
*
*
Nom de classe
Nom de classe
attributs
Relie
Relie
opérations
Exemples:
Personne
*
*
Personne
Relation
Lien
Instance de
Nom
Poste de travail
Prénom
Date naissance
Diagramme d’objets
Département
Diagramme de classes
Age()
3131
3232
Attributs de classe Opérations de classe Un attribut définit une propriété commune aux objets d’une
Attributs de classe
Opérations de classe
Un attribut définit une propriété commune aux
objets d’une classe
Une opération définit une fonction appliquée à des objets d’une
classe
Nom de classe
Nom de classe
Nom d’attribut: type = valeur initiale
Nom d’opération( liste_arguments) : type_retour
Personne
Objet Géométrique
Personne
Film
nom
: string
Personne
nom : string
prénom : string
date_naiss : date
titre : string
réalisateur : string
date_production : date
date_sortie : date
Id_pers : integer
nom : string
prénom : string
date_naiss : date
adresse : string
date_naiss : date
couleur : string
position : integer
déplacer (deltat:Vecteur)
age ()
sélectionner (p:Point):Booléen
change_adresse ()
La syntaxe de description d'une opération est la suivante:
 Les noms d'attributs d' une classe sont uniques
 Chaque objet, instance d'une classe a sa propre identité indépendante des
valeurs de ses attributs. L'identification d'un objet est donc facultative
Nom_opération (Nom_Argument : Type_Argument =
Valeur_Par_Défaut, …): Type_Retourné
3333
3434
Attributs dérivés Association Une association représente une classe de Les attributs dérivés ont des valeurs
Attributs dérivés
Association
Une association représente une classe de
Les attributs dérivés ont des valeurs calculées à partir de celles d’autres
propriétés
relations structurelles entre classes d’objets
Exemple:
Classe A
Classe B
Rectangle
Rectangle
Longueur
Longueur
Société
Personne
En conception
Largeur
Largeur
/Surface
Surface( )
Voiture
Personne
Analyse
3535
3636
Classe association Association n-aire  Une association peut être représentée ( réifiée) par une Salle
Classe association
Association n-aire
 Une association peut être représentée ( réifiée) par une
Salle
classe appelée classe associative ou classe-association.
Utile par exemple, lorsuqe l'association a des attributs ou
Étudiant
Enseignant
bien qu'on souhaite lui attacher des opérations. La
notation utilise une ligne pointillée pour attacher une
Cours
classe à une association
Début
Fin
A
B
L' association ternaire entre salle, étudiant et enseignant est
D
C
attributs
réifiée comme une classe cours ayant deux attributs, Début
et Fin
opérations()
3737
3838
Nommage des associations Nommage des rôles  Le nom d’une association apparaît en Italique au
Nommage des associations
Nommage des rôles
 Le nom d’une association apparaît en Italique au milieu
 Chaque association binaire possède 2 rôles
de la ligne qui symbolise l’association
 L’usage recommande de nommer les associations par une
 Le rôle décrit comment une classe
intervient dans une association
forme verbale, soit active, soit passive
Nom
A
B
Travaille pour >
Personne
Société
 Le nommage des associations et le
nommage des rôles ne sont pas exclusifs
l’un de l’autre
Employé
Personne
Société
Est employée par >
Employeur
Personne
Société
3939
4040
* Nommage des rôles Association réflexive  Le nommage des rôles prend tout son intérêt
*
Nommage des rôles
Association réflexive
 Le nommage des rôles prend tout son intérêt lorsque il y
a plusieurs associations entre les deux mêmes classes.
Personne
Parents
Pilote
Personne
2
* Enfants
Passagers
 La
présence d’un grand nombre d’associations entre 2 classes est
suspecte. Est souvent le signe d’une mauvaise modélisation
Le nommage des rôles est indispensable
à la clarté du diagramme
Exemple :
Personne
Conduire
Voiture
Démarrer
Laver
Arrêter
4141
4242
Multiplicité des associations Multiplicité des associations  La multiplicité est une information portée par le
Multiplicité des associations
Multiplicité des associations
 La multiplicité est une information portée par le
rôle, qui quantifie le nombre de fois où un objet
participe à une instance de relation
 Les valeurs de multiplicité expriment des
contraintes à un instant donné
1
Un et un seul
Employé
1
Personne
Société
Employeur
0
*
0
1
Zéro ou un
De M à N (entiers naturels)
M
N
Chaque personne travaille pour une seule société,
chaque société emploie zéro ou plusieurs personnes
*
De zéro à plusieurs
0
*
De zéro à plusieurs
1
*
De un à plusieurs
4343
4444
Contraintes sur les associations Contraintes sur les associations  Les contraintes sont représentées sur les
Contraintes sur les associations
Contraintes sur les associations
 Les contraintes sont représentées sur les
diagrammes par des expressions placées
entre accolades
 La contrainte {Sous-ensemble} indique qu’une
collection est incluse dans une autre collection
Parents d’élèves
Personne
{Sous-ensemble}
*
 La contrainte {ordonnée} placée sur le rôle
définit une relation d’ordre sur les objets
de la collection
Délégués
*
 La contrainte {Ou-exclusif} précise que, pour un objet donné,
une seule association parmi un groupe d’associations est valide
Enseignants
Personne
Université
Personne
Compte
{Ou-exclusif}
0
*
1
Étudiants
{Ordonnée}
4545
4646
Restriction des associations Restriction des associations  La restriction (qualification pour UML) d’une
Restriction des associations
Restriction des associations
 La restriction (qualification pour UML) d’une association consiste à
 Une restriction réduit le nombre d’instances qui
sélectionner un sous-ensemble d’objets parmi l’ensemble des objets
participent à une association
qui participent à une association
:B
 Réalisée au moyen d’une clé, ensemble d’attributs particuliers et
:B
:B
:B
utilisé avec un objet de la classe de départ. La clé appartient à
Sans clé
:B
:B
l’association et non aux classes associées
:A
 Chaque instance de la classe A accompagnée de la valeur de la clé,
 La restriction peut être opérée en combinant les valeurs
identifie un sous-ensemble des instances de B qui participent à
Avec clé
des différents attributs qui forment la clé
l’association
A
Clé
B
Ligne
Case
Échiquier
Université
Etudiant
Colonne
N°Etudiant
1
4747
4848
Agrégation Agrégation Une agrégation représente une association non symétrique dans laquelle une des extrémités
Agrégation
Agrégation
Une agrégation représente une association non symétrique dans
laquelle une des extrémités joue un rôle prédominant par rapport à
l’autre
 L’agrégation peut être multiple, comme
l’association
1
*
 Les propriétés suivantes suggèrent une agrégation:
Personne
Immeuble
Propriétaire
0
*
◦ une classe B 'fait partie' d’une classe A
◦ les valeurs d’attributs de la classe B se propagent dans les valeurs
d’attributs de la classe A
◦ une action sur la classe A implique une action sur une la classe B;
En tant que 'propriétaire' une personne est un agrégat d'immeubles!
Les immeubles dont elle est propriétaire font 'partie de' la description
d'une personne
◦ les objets de la classe B sont subordonnés aux objets de la classe
A
Une agrégation
A
B
4949
5050
Composition Composition La composition est une forme particulière d'agrégation  La composition peut être
Composition
Composition
La composition est une forme particulière d'agrégation
 La composition peut être modélisée au moyen d'
attributs
Le composant est physiquement contenu dans l’agrégat
 La composition implique une contrainte sur la valeur de
la multiplicité du côté de l’agrégat: elle ne peut prendre
que les valeurs 0 ou 1
 La notation par composition doit être retenue lorsqu’un
attribut participe à d’autres relations dans le modèle
Voiture
Voiture
Moteur
 La valeur 0 du côté du composant correspond à un
attribut non renseigné
Moteur
0
1
Agrégat
Composant
Cylindre
Carburateur
*
5151
5252
Généralisation Généralisation multiple  Dans le cas des classes, la relation de généralisation signifie est
Généralisation
Généralisation multiple
 Dans le cas des classes, la relation de
généralisation signifie est un ou est une
sorte de
Véhicule
Tapis
X
Terrestre
Aérien
Animal
A
B C
Tapis volant
Chat
Chien
Vache
5353
5454
Généralisation Contraintes de généralisation  Une classe peut être spécialisée selon plusieurs critères 
Généralisation
Contraintes de généralisation
 Une classe peut être spécialisée selon plusieurs critères
 La contrainte {Disjoint} ou {Exclusif} indique la
 Différentes contraintes peuvent être appliquées aux
relations de généralisation
participation exclusive d'un objet à l'une des collections
spécialisées
Champignon
 Par défaut, la généralisation symbolise une
décomposition exclusive
{Exclusif}
Véhicule
Agaricus
Boletus
Motorisation
Milieu
Pied bleu
Bolet de
loup
A voile
A moteur
Terrestre
Marin
5555
5656
Contraintes de généralisation Contraintes de généralisation  La contrainte {Chevauchement} ou {Inclusif} indique
Contraintes de généralisation
Contraintes de généralisation
 La contrainte {Chevauchement} ou {Inclusif} indique
qu'un objet peut appartenir à plusieurs collections
spécialisées .
Véhicule
 La contrainte {Complète} indique que la généralisation
est terminée et qu'il n'est pas possible de rajouter des
sous-classes. Inversement, la contrainte {Incomplète}
désigne une généralisation extensible
{Inclusif}
Motorisation
Milieu
Cours
A voile
A moteur
Terrestre
Marin
{Incomplète}
Maths
Français
Géographie
Pétrolette
5757
5858
Diagramme d'objets Diagramme d'objets  Permet de visualiser la structure du système au niveau des
Diagramme d'objets
Diagramme d'objets
 Permet de visualiser la structure du système au niveau
des instances
 On peut faire apparaître des valeurs d'attributs dans un
objet
 Facilite la compréhension des structures de données
complexes
 ainsi que les liens entre objets
:Voiture
 Trois possibilités de représentation :
Couleur = rouge
Voiture
Moteur
:Voiture
:Moteur
1
1
:Roue
Nom de l'objet
Nom de l'objet : Classe
: Classe
1
:Roue
:Roue
:Roue
4
Roue
5959
6060
Liens entre les objets Liens entre les objets  On peut illustrer les liens d'arité
Liens entre les objets
Liens entre les objets
 On peut illustrer les liens d'arité supérieure à 2 et la
muliplicité *
 Les liens instances des associations réflexives peuvent relier un
objet à lui-même
Professeur
1
*
1
*
1
*
Salle
Etudiant
Collaborateur
Patron
*
Jean-Luc: Personne
Pierre: Personne
Personne
1
Patron
: Professeur
Patron
: Salle
: Etudiant
6161
6262
Objet composite Illustration de structures complexes  Les objets composés de sous-objets peuvent être visualisés
Objet composite
Illustration de structures complexes
Les objets composés de sous-objets peuvent être
visualisés
 Les diagrammes d'objets facilitent la
compréhension des diagrammes de classes
Un composite
: Partie
: Partie
:
Partie
Passagers
*
Passagers
Bus
Personne
:
Personne
Les objets composites sont instances de classes composites:
:
Bus
Conducteur
1
Conducteur
Ascenseur
Fenêtre
: Fenêtre
:
Personne
1
1
2
Destination
:
Zone de dessin
: Ascenseur
1
:
Destination
1
: Ascenseur
Zone
de dessin
6363
6464
Illustration de structures complexes Packages Parent Prénom  Un package permet de grouper des éléments
Illustration de structures complexes
Packages
Parent
Prénom
 Un package permet de grouper des
éléments
Personne
1
Mère/Père
 Un package sert d’espace de désignation
Enfant
0
1
 Un package peut inclure d’autres package
Jonathan
Lara
Roxane
Mère
Père
Mère
Père
Mère
Père
 Un package peut importer d’autres
package
Anne
Pierre-Alain
 L’héritage entre package est possible
6565
6666
Packages Diagramme de Classe - Fin  Les diagrammes de classes sont les diagrammes les
Packages
Diagramme de Classe - Fin
 Les diagrammes de classes sont les
diagrammes les plus utilisés
◦ Ils permettent la décrire des programmes objet
◦ Ils permettent de décrire le schéma logique de
bases de données
◦ Ils permettent de décrire des relations de concepts
(modèle métier)
 Les diagrammes de classes peuvent être de
différents niveaux d’abstraction
6767
6868
Diagramme de collaboration Il décrit le comportement collectif d'un ensemble d'objets dans le cadre d'une
Diagramme de collaboration
Il décrit le comportement collectif d'un ensemble d'objets dans le cadre d'une
opération en illustrant leurs interactions par des envois de messages
Collaboration
0
1
DIAGRAMMES DE
COLLABORATION D'OBJETS
*
Interaction
Modèle : Booléen
0
1
*
Opération
Représente
Résultat
Ordre
Contrainte
Message
Objet
6969
7070
Envoi de message dans un diagramme de collaboration  Une interaction est réalisée par un
Envoi de message dans un diagramme de
collaboration
 Une interaction est réalisée par un groupe d'objets qui
collaborent en échangeant des messages
Le temps dans un diagramme de
collaboration
 Le temps peut être introduit par le biais de
la numérotation des envois de messages
 Extension des diagrammes d'objets
(ordre)
 Un message est représenté par une flèche labellée par le
nom de l'opération
: Ascenseur
1:Monter
: Cabine
Message
Ouvrir
3:Fermer
2:Mettre en marche
: Porte
: ClasseA
: ClasseB
: Cabine
: Porte
: Cabine
7171
7272
Contraintes associées aux envois de messages Itération dans un diagramme de collaboration  Les objets
Contraintes associées aux envois de
messages
Itération dans un diagramme de
collaboration
 Les objets et les liens créés ou détruits au cours d'une
interaction peuvent respectivement porter les
contraintes {nouveau} ou {détruit}
 La notation permet d'introduire un envoi répétitif de
messages (événtuellement en parallèle) sur une
collection d'objets d'une classe
 Les objets créés, puis détruits au sein de la même
interaction, sont associés à la contrainte {transitoire}
Instituteur
Élève
1
*
B
*[tous] : Debout
{nouveau})
:Instituteur
: Élève
A
C
D {transitoire}
{détruit}
7373
7474
Introduction d'un acteur extérieur Objets actifs  La notation permet de faire figurer un acteur
Introduction d'un acteur extérieur
Objets actifs
La notation permet de faire figurer un acteur dans un
diagramme de collaboration afin de représenter le
déclenchement des interactions par un élément externe
au système
Les objets qui contôlent le flot sont dits actifs. Un objet
actif peut activer un objet passif en lui envoyant un
message. Une fois le message traité, le flot de contrôle
est restitué à l'objet actif
1:Appeler
2:Écrire
: Imprimante
: Traitement de texte
: Ascenseur
: Scanner
:Personne
1:Lire
2:Selectionner l'étage
: Cabine
7575
7676
Envois conditionnels de messages Envoi de message avec résultat  L'envoi d'un message peut être
Envois conditionnels de messages
Envoi de message avec résultat
 L'envoi d'un message peut être assorti d'une condition
 Le résultat d’un message peut être
visualisé sous la forme d'une liste de
[condition] : Message
valeurs retournées par le message.
A
B
Message
A
B
[poids>=300] : Sonner
valeurs retournées
: Cabine
: Alarme
Afficher âge
: Université
: Etudiant
* || [âge>=18] : Voter
âge
: Mairie
:
Personne
7777
7878
Exemple Demande d’une boisson disponible avec introduction du montant exact de la boisson : Utilisateur
Exemple
Demande d’une boisson disponible avec introduction du montant exact de la
boisson
: Utilisateur
1: Introduire
2: boisson := Choisir
DIAGRAMMES DE SÉQUENCE
: Pièce
Café : Boisson
1.1: Comptabiliser(valeur)
2.3: FinOpération
: Gestionnaire
1.1.1: Afficher
2.1: réponse:= VérifierPrix(prix)
de pièces
SommeVersée
2.2: réponse:= Disponibilité
: Gobelet
2.2.1: gobelet
7979
8080
Diagramme de séquence Représentation des interactions entre objets  Modélisation des interactions entre objets
Diagramme de séquence
Représentation des interactions entre
objets
 Modélisation des interactions entre objets
suite à un événement externe
 Le concept de message unifie toutes les formes de communication
entre objets (appel de procédure, événement discret, signal entre
flots d'exécution ou interruption matérielle)
 2 catégories d'envois de message :
 Les interactions entre objets selon un
point de vue temporel
 Les envois synchrones pour lesquels l'émetteur est bloqué et attend que
l'appelé ait fini de traiter le message
 Les envois asynchrones pour lesquels l'émetteur n' est pas bloqué et
peut continuer son exécution
Nom : Classe
Nom : Classe
Nom : Classe
Message
A
B
Message
Message synchrone
Message
Message asynchrone
8181
8282
Message réflexif Création et destruction d' objet  La création d'un objet se représente par
Message réflexif
Création et destruction d' objet
 La création d'un objet se représente par un
Un objet peut s'envoyer un message à lui-même
message pointant sur l'objet crée
Un objet
 La destruction est indiquée par la fin de la
Message réflexif
ligne de vie et par la lettre X
: Bibliothécaire
Composant a
Composant b
Objet composite
Point d'entrée
Créer
: Livre
Détruire
X
8383
8484
Périodes d’activité des objets Envoi conditionnel de message Message synchrone B B C A Un
Périodes d’activité des objets
Envoi conditionnel de message
Message synchrone
B
B C
A
Un objet
A
Activation
[condition] Message
[non condition] Message
Retour implicite
Message asynchrone
: Livre
: Livre
: Abonné
A
B
Un objet
Récursion
[disponible] Emprunter
[non disponible] Réserver
Retour explicite
8585
8686
Contraintes temporelles Traitement conditionnel d’un message reçu B A : Ligne Appelant : Client Appelé
Contraintes temporelles
Traitement conditionnel d’un message reçu
B
A
: Ligne
Appelant : Client
Appelé : Client
téléphonique
Décroche
Message [condition]
Tonalité
[non condition]
x
{y-x < 10s}
Numérotation
y
Indication de sonnerie
Sonnerie
z
{w-z < 20s}
: Livre
: Abonné
Décroche
w
Retourner [en bon état]
[en mauvais état]
8787
8888
Diagramme d'états-transitions  Décrit le comportement des objets d'une classe au moyen d'un automate
Diagramme d'états-transitions
 Décrit le comportement des objets d'une classe au moyen d'un
automate d'états associé à la classe
DIAGRAMMES D'ÉTATS-
TRANSITIONS
 Le comportement est modélisé dans un graphe dont les nœuds
sont les états possibles des objets de la classe et les arcs sont
les transitions d'état à état. Chaque transition résulte de
l'exécution d'une action et représente la réaction des objets
aux événements qui surviennent
 Les objets qui n'ont pas un comportement réactif très
important peuvent être considérés comme des objets qui
restent toujours dans le même état: leurs classes ne possèdent
alors pas d'automate
1
Classe
Automate
8989
9090
0
1
La notion d'état Notion d'état  Un état est un étape dans le cycle de
La notion d'état
Notion d'état
 Un état est un étape dans le cycle de vie d’un objet durant lequel l’objet
satisfait certaines conditions, réalise certaines actions ou attend
certains évènements
 Un état est l'image de la conjonction instantanée des
valeurs des attributs de l'objet, et de la présence ou non
de ses liens à d'autres objets
 Chaque objet est à un moment donné, dans un état particulier
Exemple: L'état d'une personne résulte de la conjonction suivante :
 Chaque état possède un nom qui l'identifie
◦ âge de la personne,
 Un état est stable et durable
◦ présence d'un lien vers une société
Au chômage
Personne
Société
Laurent
Age: 30 ans
0
1
1
*
Age
Bruno
: Société
En activité
Age: 40 ans
A la retraite
En activité
André
9191
9292
Au chômage
Age: 75 ans
A la retraite
Notion d'état Notion de transition  Chaque diagramme d’états-transition contient un état initial 
Notion d'état
Notion de transition
 Chaque diagramme d’états-transition contient un état initial
 Lorsque des événements se produisent, les objets changent d'état en
respectant les règles décrites dans l'automate associé à leur classe
 Pour un niveau hiérarchique donné, il y a un et un seul état
initial mais il est possible qu'il y ait plusieurs états finaux qui
correspondent chacun à une fin de vie d'objet différente
 Les diagrammes d'états-transitions sont des graphes dirigés
 Les états sont reliés par des connexions unidirectionnelles, appelées
transitions
 Il est également possible de n'avoir aucun état final (par
exemple, un système qui ne s'arrête jamais)
Etat A
Etat B
Disponible
Emprunté
État intermédiaire
État initial
État final
Classe : Exemplaire
Réservé
Acheté
Classe : Article
9393
9494
Notion d'événement Notion d'événément  Un événement correspond à l'occurrence d'une situation
Notion d'événement
Notion d'événément
 Un événement correspond à l'occurrence d'une situation
 La syntaxe générale d'un événement est la suivante:
Nom de l’événement (Nom de paramètre : Type, …)
donnée dans le domaine du problème
 La spécification complète d'un événement comprend:
 Un événement est par nature une information
◦ le nom de l'événement
instantanée qui doit être traitée sans plus attendre.
◦ la liste des paramètres
 L'événement est le déclencheur de la transition d' état à
◦ l'objet expéditeur
◦ l'objet destinataire
état Un objet, placé dans un état donné, attend
◦ sa description
l'occurrence d'un événement pour passer dans un autre
Plus de 60 ans
En activité
état
Emprunt
Perte d'emploi
Événement
A la retraite
Etat A
Etat B
Disponible
Emprunté
Embauche
Classe : Exemplaire
Au chômage
9595
Plus de 60 ans
9696
Communication entre objets par événement  La communication par événement est de type Communication entre
Communication entre objets par
événement
 La communication par événement est de type
Communication entre objets par
événement
 L'objet émetteur de la requête se met en
asynchrone, atomique, et unidirectionnelle. Un objet
attente de la réponse de l’objet récepteur
peut envoyer un événement à un autre objet qui doit
de la requête
toujours être à même de l'interpréter
Un événement
Un objet
Un autre objet
A
 Les besoins de communication par événements synchrones ou
les échanges bidirectionnels peuvent se représenter au moyen de
deux échanges asynchrones de directions opposées
Question posée à l’objet X
Attente réponse
Réponse reçue de la part de l’objet X
Une question
Un objet
Un autre objet
B
9797
9898
La réponse
Notion de garde Notions d'opération et d'action  Une garde est une condition booléenne qui
Notion de garde
Notions d'opération et d'action
 Une garde est une condition booléenne qui permet ou
non le déclenchement d'une transition lors de
l'occurrence d'un événement
 Le lien entre les opérations définies dans la spécification d'une classe
et les événements apparaissant dans le diagramme d'états-
transitions de cette classe est assuré par le biais des actions et des
activités
Événement [Condition]
A
B
 Les gardes permettent de maintenir l'aspect déterministe d'un
automate d'états finis. Lorsque l'événement a lieu, les gardes -
qui doivent être mutuellement exclusives - sont évaluées et une
transition est validée puis déclenchée
 Chaque transition peut avoir une action à exécuter lorsque la
transition est déclenchée par un événement
 L'action est considérée comme instantanée et atomique
Événement / Action
A
B
Exemple : Livre
Emprunté
Retour [bon état]
Retour [mauvais état]
 L'action correspond à une des opérations déclarées dans la
classe de l'objet destinataire de l'événement. L'action a accès
aux paramètres de l'événement, ainsi qu'aux attributs de l'objet
Disponible
En réparation
9999
100100
Actions dans un état Opération, action, activité  Les états peuvent également contenir des actions;
Actions dans un état
Opération, action, activité
 Les états peuvent également contenir des actions; elles sont
exécutées à l'entrée ou à la sortie de l'état ou lors de l'occurrence
d'un événement pendant que l'objet est dans l'état :
 Un événement interne n’entraîne pas l’exécution des
actions de sortie et d’entrée, contrairement au
déclenchement d’une transition réflexive
◦ L'action d'entrée (entry:) est exécutée de manière instantanée et
atomique dès l'entrée dans l'état
E1 / Action
A
◦ L'action de sortie (exit:) est exécutée à la sortie de l'état
B
◦ L'action sur événement interne (on:) est exécutée lors de
l'occurrence d'un événement qui ne conduit pas un à un autre
état
entry: Action d'entrée
on E1: Action
exit: Action de sortie
entry: Action d'entrée
exit: Action de sortie
Nom d’un état
entry : Action d'entrée
on Nom d’un événement : Action
exit : Action de sortie
 Les actions correspondent à des opérations dont le temps
d'exécution est négligeable. Une opération qui prend du temps
correspond à un état plutôt qu'à une action (sic!!)
101101
102102
Opération et activité Notion d'activité  Une opération qui prend un temps non négligeable et
Opération et activité
Notion d'activité
 Une opération qui prend un temps non négligeable et qui est exécutée
pendant que l'objet est dans un état donné est appelée une activité
 Le mot-clé do: indique une activité
 Contrairement aux actions, les activités peuvent être interrompues à tout
moment, dès qu'une transition de sortie de l'état est déclenchée
 Lorsque l'activité se termine, les transitions
automatiques, sans événements, mais
éventuellement protégées par des gardes, sont
déclenchées
 Activité cyclique: elle ne s'arrête que lorsqu'une transition de sortie est
A
déclenchée
B
Do: Activité séquentielle
 Activité séquentielle: elle démarre à l'entrée dans l'état Lorsqu'elle
parvient à son terme, l'état peut être quitté si une des transitions est
A
[ X ]
franchissable. C'est une transition automatique
B
Do: Activité séquentielle
Etat A
C
Do: Une opération
103103
104104
Points d’exécution des opérations Diagramme E/T du distributeur automatique des boissons 6 façons d'associer
Points d’exécution des opérations
Diagramme E/T du distributeur automatique des
boissons
6 façons d'associer une
opération à une transition:
Pièces insérées (montant) / régler montant
Encaissement d’argent
/ Op1
En attente
◦ l'action associée à la transition
do : augmenter le montant
d'entrée (Op1)
Un état
[montant <
entry: Op2
[article vide]
Article sélectionné
◦ l'action d'entrée de l'état (Op2)
prix article]
do: Op3
◦ l'activité dans l'état (Op3)
exit: Op4
on UnEvénement: Op5
Test d’article
◦ l'action de sortie de l'état (Op4)
do : tester article et calculer
la monnaie à rendre
/ Op6
◦ l'action associée aux événements
[montant = prix article]
[montant > prix article]
internes (Op5)
◦ l'action associée à la transition de
Distribution
Encaissement
sortie de l'état (Op6)
do : distribuer article
do : rendre monnaie
105105
106106
Généralisation d’états Généralisation d’états  Un état peut être décomposé en plusieurs sous-états
Généralisation d’états
Généralisation d’états
 Un état peut être décomposé en plusieurs sous-états
disjoints; les sous-états héritent des caractéristiques de
leur super-état
 Les transitions d'entrée ne sont pas
héritées par tous les états, seul un état
peut être cible de la transition
 Décomposition disjonctive: l'objet doit être dans un seul
B
sous-état à la fois
B1
AB
E1
A
B
A
A
B
E1
A
B
E2
B2
E2
E2
C
C
L'état B
est divisé en deux sous-états B1 et B2. La transition d'entrée dans l'état B doit être
AB est
un super état dont A et B sont des sous-états
reportée directement sur un des sous états.
Cette généralisation permet de factoriser la transition E2
107107
108108
Généralisation d’états Généralisation d’états  Il est préférable de limiter les liens entre niveaux
Généralisation d’états
Généralisation d’états
 Il est préférable de limiter les liens entre
niveaux hiérarchiques d'un automate en
définissant systématiquement en état
initial pour chaque niveau
Exemple: boîte automatique de transmission
passer à M
Point mort
Marche arrière
passer à Avant
passer à P
passer à Point mort
Marche Avant
augmentation vitesse
augmentation vitesse
stop
Première
Deuxième
Troisième
B
réduction vitesse
réduction vitesse
A
B1
La
généralisation d'état permet de mettre en facteur les deux transitions
B2
'passer à Avant' et 'passer à Point mort'
109109
110110
Agrégation d’états Agrégation d’états  L'agrégation d'états est la composition d'un état à
Agrégation d’états
Agrégation d’états
 L'agrégation d'états est la composition d'un état à partir de plusieurs
autres états indépendants
 La composition est de type conjonctive ce qui implique que l'objet
Exemple: activité d’émission des billets
doit être simultanément dans tous les états composant l'agrégation
d'états
 Forme de parallélisme entre automates
Emission
S
T
U
do : distribuer billets
billets pris
prêt
E1
X
Préparation
Accueille
do : éjecter carte
carte prise
A
E3
Y
E2
E1
E4[ in Z ]
Z
B
111111
112112
Diagramme d'activités Gardes  Variante des diagrammes d'états- transitions, ce diagramme met l'accent
Diagramme d'activités
Gardes
 Variante des diagrammes d'états-
transitions, ce diagramme met l'accent sur
les activités, leurs relations et leurs
impacts sur les objets
 Les transitions entre activités peuvent être gardées par des
conditions booléennes, mutuellement exclusives. Les gardes sont
des labels des transitions dont elles valident le déclenchement
Mesurer la
[trop chaud]
[trop froid]
température
Chauffer
Refroidir
Activité
Activité finie
 Une condition peut être matérialisée par un losange d'où
sortent plusieurs transitions
Mesurer la
température
[trop froid]
[trop chaud]
113113
Chauffer
Refroidir
114114
Synchronisation Diagramme d'activités  Les diagrammes d'activités représentent les synchronisations
Synchronisation
Diagramme d'activités
 Les diagrammes d'activités représentent
les synchronisations d'activités au moyen
de barres de synchronisation
 Les diagrammes d'activités peuvent être découpés en couloirs
d'activités pour montrer les différentes responsabilités au sein d'un
mécanisme logiciel ou d'une organisation. Chaque responsabilité est
assurée par un ou plusieurs objets et chaque activité est allouée à un
couloir donné
Enseignant
Étudiant
Jury
Arrêter le
Refroidir
Aérer
chauffage
Enseigner
Apprendre
Arrêter le
Mesurer la
Contrôler les
Composer
Aérer
chauffage
température
connaissances
Évaluer
115115
116116
Objets dans un diagramme d'activités Etats et événements  Il est possible de faire apparaître
Objets dans un diagramme d'activités
Etats et événements
 Il est possible de faire apparaître des objets dans un diagramme
d'activités, soit au sein des couloirs d'activités, soit ien dehors de ces
couloirs
 Les diagrammes d'activités peuvent faire
référence à des états et à des événements
Client
Vendeur
Expédition
Ouvrir la
Se renseigner
Établir un devis
fenêtre
^Thermostat.DonnerUneConsigne
Commande
Commander
[passée]
Aérer
Bon de
Facturer
Consigne atteinte
livraison
Fermer la
Commande
fenêtre
Payer
Livrer
[payée]
117117
118118
Diagramme de composants  Un diagramme de composantes présente la vue statique de l'implémentation d'un
Diagramme de composants
 Un diagramme de composantes présente
la vue statique de l'implémentation d'un
système
DIAGRAMME DE
COMPOSANTS
119119
120120
Composante Nommer une composante  Une composante est une partie physique et remplaçable d'un système
Composante
Nommer une composante
 Une composante est une partie physique
et remplaçable d'un système qui se
conforme et réalise un ensemble
 Chaque composante doit avoir un nom qui le
distingue des autres composantes - Unicité du
nom complet (noms des packages englobant
+ le nom de la composante).
d'interfaces.
 En pratique les noms de composantes sont
des noms pris dans le vocabulaire de
l'implémentation et dépendant du ou des
systèmes d'exploitation utilisés.
121121
122122
Représentation graphique d'une composante Composantes et classes  Une composante est l'implémentation
Représentation graphique d'une
composante
Composantes et classes
 Une composante est l'implémentation
compartiment extra
composante
physique de classes.
agentfraude.dll
agent.java
Réalise
AgentFraude
PolitiqueFraude
Recherche
valeur étiquetée
system::dialog.dll
{version = 4.1}
123123
124124
Composantes et classes - Représentation graphique Composantes et interfaces  Une interface est une collection
Composantes et classes - Représentation
graphique
Composantes et interfaces
 Une interface est une collection de
composante
spécifications d'opérations qui définissent
relation de réalisation
agentfraude.dll
le service rendu par une classe ou une
composante.
 Les interfaces représentent le ciment qui
AgentFraude
Recherche
lie les composantes entre elles
PolitiqueFraude
classe
125125
126126
Composantes et interfaces - Représentation graphique Remplacement de composantes composante interface
Composantes et interfaces - Représentation
graphique
Remplacement de composantes
composante
interface
component.javacomponent.java
 L'intention de base des composantes est
d'être capable d'assembler un système à
partir d'éléments remplaçables.
image.javaimage.java
 Une composante est physique.
ImageObserver
dépendance
réalisation
 Une composante est une partie d'un système.
«interface»
ImageObserver
component.javacomponent.java
image.javaimage.java
abort: int {static}
error: int {static}
 Une composante se conforme et réalise un
ensemble d'interfaces.
imageUpdate()
127127
128128
Types de composantes Stéréotypes standards UML distingue trois types de composantes : UML définit cinq
Types de composantes
Stéréotypes standards
UML distingue trois types de composantes :
UML définit cinq stéréotypes pour les composantes :
 exécutable
 Composante de déploiement
spécifie une composante exécutable sur un nœud
Ce sont les composantes nécessaires et suffisantes pour
construire un système exécutable.
 librairie
spécifie un objet de type librairie statique ou dynamique
 Composante de réalisation
 table
Ce sont les composantes résultats du travail de
développement (code source, fichier,
spécifie une table d'une base de données
)
 fichier
 Composante d'exécution
spécifie un fichier qui contient du code source ou des données
Ce sont les composantes qui sont créées lors de l'exécution
d'un système
 document
spécifie une composante qui représente un document
129129
130130
Pour modéliser le code source Pour modéliser un exécutable  Pour représenter la gestion de
Pour modéliser le code source
Pour modéliser un exécutable
 Pour représenter la gestion de
configuration des fichiers sources.
 Pour représenter la composition d'un
exécutable.
chemin.dll
collision.dll
signal.h
signal.h
signal.h
{version = 3.5}
{version = 4.0}
{version = 4.1}
«parent»
«parent»
driver.dll
{version = 4.3.5}
Idrive
signal.c
interrupt.c
{version = 4.1}
ISelfTest
131131
132132
Pour modéliser une base de données Pour modéliser un système dynamique  Pour représenter le
Pour modéliser une base de données
Pour modéliser un système dynamique
 Pour représenter le schéma physique
d'une base de données.
 Pour représenter le comportement
physique d'un système dynamique.
université.db
La base de données est
répliquée sur le serveur
B
professeur
département
cours
étudiant
:université.db
:université.db
{localisation = serveur A}
{localisation = serveur B}
«copier»
133133
134134
Diagramme de dépoilement DIAGRAMME DE DÉPOILEMENT  Un diagramme de déploiement présente la configuration
Diagramme de dépoilement
DIAGRAMME DE
DÉPOILEMENT
 Un diagramme de déploiement présente la
configuration physique des ordinateurs et
périphériques ainsi que les composantes
qui s'exécutent.
135135
136136
Nœud Nommer un nœud  Un nœud est un élément physique qui existe au moment
Nœud
Nommer un nœud
 Un nœud est un élément physique qui
existe au moment de l'exécution et qui
représente une ressource ayant des
possibilités d'exécution .
 Chaque nœud doit avoir un nom qui le
distingue des autres nœud - Unicité du
nom complet (noms des packages
englobant + le nom du nœud).
 En pratique les noms de nœuds sont des
noms pris dans le vocabulaire de
l'implémentation
137137
138138
Représentation graphique d'un nœud Nœud et composante compartiment extra nœud  Un nœud représente le
Représentation graphique d'un nœud
Nœud et composante
compartiment extra
nœud
 Un nœud représente le déploiement
physique des composantes.
kiosque_2kiosque_2
ventesventes
 Un nœud exécute des composantes.
DéploieDéploie
stock.exe
stock.exe
région.exe
région.exe
valeur étiquetée
serveur::sauvegardeserveur::sauvegarde
{réservéAdministration}
139139
140140
Nœuds et composantes - Représentation graphique Connexion  Les associations entre nœuds représentent nœud les
Nœuds et composantes - Représentation
graphique
Connexion
 Les associations entre nœuds représentent
nœud
les connections physiques tels une
ventes
connexion Ethernet, un câble série, ou
relation de dépendance
encore un bus commun.
stock.exestock.exe
région.exerégion.exe
composante
141141
142142
Nœud et connexions - Représentation graphique Pour modéliser les systèmes embarqués  Pour modéliser la
Nœud et connexions - Représentation
graphique
Pour modéliser les systèmes
embarqués
 Pour modéliser la partie matérielle d'un
stéréotype
système.
port série
kiosquekiosque
«10-T Ethernet»
«processeur»
sonar
«RS232»
serveurserveur
carte mère
4
«RS232»
consoleconsole
moteur
moteur
connexion
mouvement
direction
M
M
~
~
143143
144144
Pour modéliser les systèmes client- Pour modéliser les systèmes distribués serveur  Pour modéliser
Pour modéliser les systèmes client-
Pour modéliser les systèmes distribués
serveur
 Pour modéliser l'implémentation de
 Pour modéliser la topologie de systèmes
système client-serveur.
distribués.
serveurs
:console:console
clients
:serveur
:serveur
2
*
4
*
«processeur»
«processeur»
régional
régional
cache
serveur
:Internet
kiosquekiosque
Déploie
Déploie
http.exe
db.exe
:console:console
log.exe
console
:serveur
:serveur
régional
régional
:serveur
:serveur
:serveur
:serveur
régional
régional
national
national
145145
146146
Standard UML et Éditeur Le standard UML …  Le standard UML définit ce qu’est
Standard UML et Éditeur
Le standard UML …
 Le standard UML définit ce qu’est UML
 définit précisément tous les éléments UML
 Les éditeurs doivent être conformes au
standard
et leurs relations : sémantique
 définit précisément une notation
 Pas de procédure de conformité
 Forte évolution des standards sans
compatibilité ascendante
graphique pour chaque éléments :
notation
Qu’est ce qu’un outil UML standard ?
147147
148148
Modéliser la sémantique Le méta-modèle UML  Pourquoi ne pas faire un modèle représentant les
Modéliser la sémantique
Le méta-modèle UML
 Pourquoi ne pas faire un modèle représentant les éléments UML :
Un méta-modèle
generalization
 Le standard UML définit de manière
pseudo formelle la sémantique des
concepts UML en fournissant le méta-
*
modèle UML
Package
Class
Opération
0
1
*
0
1
*
◦ Plus de 50 concepts (méta-classes)
0 1
*
Attribut
◦ Structuration en package (core, common
behavior, …)
◦ Aucune présence des diagrammes
149149
150150
Le méta-modèle UML … Notation  La notation est la partie visible du standard 
Le méta-modèle UML …
Notation
 La notation est la partie visible du standard
 La sémantique des utilisateurs se base sur
la notation
 Le standard n’établit pas un lien précis
entre la notation et la sémantique
151151
152152
Outil UML standard Objecteering  Il est communément établie qu’un outil UML standard est un
Outil UML standard
Objecteering
 Il est communément établie qu’un outil
UML standard est un outil qui
◦ Respecte intégralement la notation UML
 Objecteering (version 5.2.2) est un outil
UML standard créé par la société
SOFTEAM
 Même si tous les diagrammes ne sont pas supportés
◦ Dispose d’un format de représentation interne
compatible avec le méta-modèle UML standard
◦ Il permet l’élaboration de tous les diagrammes
UML
 Le difficulté de ce point s’illustre avec XMI
◦ Il dispose de son propre méta-modèle
compatible avec le méta-modèle UML
153153
154154
Objecteering Le méta-modèle Objecteering Explorateur de modèles Explorateur de Zone d’élaboration diagrammes
Objecteering
Le méta-modèle Objecteering
Explorateur
de modèles
Explorateur de
Zone d’élaboration
diagrammes
des modèles
155155
156156
 ◦ ◦ ◦

Autres outils standards

Rational Rose

Outil de plus important du marché

http://www.rational.com

Racheté par IBM

Together

Outil fortement couplé avec Java

http://www.togethersoft.com

Racheté par Borland

ArgoUML

Outil Open Source

http://argouml.tigris.org

Visio

Outil non complet de microsoft

http://www.microsoft.com/office/visio

157157
157157