0% ont trouvé ce document utile (0 vote)
29 vues31 pages

La Notation UML Full

Transféré par

ramanitrarivo.patrick
Copyright
© © All Rights Reserved
Nous prenons très au sérieux les droits relatifs au contenu. Si vous pensez qu’il s’agit de votre contenu, signalez une atteinte au droit d’auteur ici.
Formats disponibles
Téléchargez aux formats PDF, TXT ou lisez en ligne sur Scribd
0% ont trouvé ce document utile (0 vote)
29 vues31 pages

La Notation UML Full

Transféré par

ramanitrarivo.patrick
Copyright
© © All Rights Reserved
Nous prenons très au sérieux les droits relatifs au contenu. Si vous pensez qu’il s’agit de votre contenu, signalez une atteinte au droit d’auteur ici.
Formats disponibles
Téléchargez aux formats PDF, TXT ou lisez en ligne sur Scribd
Vous êtes sur la page 1/ 31

ENI - L3

Qu'est-ce qu'UML ?
 UML = Unified Modeling Language ;
 UML = Langage unifié pour la modélisation objet ;
 UML est un langage universel de modélisation objet ;
 UML est une notation, un outil de communication
La notation UML visuelle (diagrammes) ;
 UML est un langage de modélisation des applications
construites à l'aide d'objets ;
 UML n’est pas une méthode ;
 UML n'est pas un langage de programmation ;
 UML n'est pas un processus de développement ;
 UML est une norme maintenue par l'OMG.

RAZAFIMAHATRATRA Hajarisena
Docteur en Informatique Année : 2023
2

Historique d’UML (1/2) Historique d’UML (2/2)


 Issu en 1996 de la pratique industrielle et de la modélisation des
systèmes logiciels ;

 Unification des méthodes objets dont les auteurs sont :


 Ivar Jacobson (OOSE),
 Grady Booch (BOOCH'93),
 James Rumbaugh(OMT).

 Normalisation OMG en 1997 ;

 En 2005 : UML 2.0 ;


 En 2007 : UML 2.1.1 ;
 En 2009 : UML 2.2 ;
 En 2010 : UML 2.3 ;
 En 2011 : UML 2.4.

3 4

Objectifs d’UML UML est un langage pour…


 Proposer un langage visuel de modélisation :  Visualiser
 utilisable par toutes les méthodes ;  chaque symbole graphique a une sémantique ;
 adapté à toutes les phases du développement ;
 compatible avec toutes les techniques de réalisation.
 Spécifier
 Proposer des mécanismes d’extension et de spécialisation pour  de manière précise et complète, sans ambiguïté ;
pouvoir étendre les concepts de base ;
 Construire
 Être indépendant des langages particuliers de programmation ;
 les classes, les relations, …
 Proposer une base formelle pour comprendre le langage de
modélisation.  Documenter
 les diagrammes, notes, contraintes, exigences.

5 6

1
ENI - L3

Les auteurs d’UML préconisent … Les « 4 + 1 » vues (1/6)


Trois types de démarches :  Modèle d'architecture de Philippe Kruchten :
 Itérative et incrémentale ;
 Guidée par les besoins des utilisateurs du
système ;
 Centrée sur l'architecture logicielle.

7 8

Les « 4 + 1 » vues (2/6) Les « 4 + 1 » vues (3/6)


Vue des cas d'utilisation : Vue logique :
 Concerne l’intégrité de conception ;
 Guide toutes les autres ;
 Se concentre sur l'abstraction et
 Permet : l'encapsulation ;
 de trouver le bon modèle ;  Modélise les éléments et mécanismes
principaux du système ;
 d’expliquer et de justifier les choix qui  Identifie les éléments du domaine, les
ont guidé sa conception et son relations, et les interactions entre ces
fonctionnement pour pouvoir le éléments ;
 Organise les éléments du domaine en
construire, le maintenir et le tester.
catégories.

9 10

Les « 4 + 1 » vues (4/6) Les « 4 + 1 » vues (5/6)


Vue de réalisation : Vue des processus :
 Concerne l’intégrité de gestion ;  Concerne l’intégrité d’exécution ;
 Exprime la perspective physique de  Très importante dans les environnements
l’organisation du code en termes de multitâches ;
modules, de composants, et des concepts  Exprime la perspective sur les activités
du langage ou de l’environnement concurrentes et parallèles.
d’implémentation.

11 12

2
ENI - L3

Les « 4 + 1 » vues (6/6) Briques de base d’UML


Vue de déploiement :  Les éléments :
 ce sont les abstractions essentielles à un
 Concerne l’intégrité de performance ; modèle ;
 Exprime la répartition du système à
travers un réseau des calculateurs et des  Les relations :
nœuds logiques de traitements ;  elles constituent des liens entre ces
éléments ;
 Utile pour décrire la distribution d’un
système réparti.  Les diagrammes :
 ils regroupent deséléments et des liens au
sein de divers ensembles.
13 14

Diagrammes d’UML (1/2) Diagrammes d’UML (2/2)


 Diagrammes structurels / statiques (UML Structure) :
 diagramme de classes (Class diagram)
 diagramme d’objets (Object diagram)
 diagramme de composants (Component diagram)
 diagramme de déploiement (Deployment diagram)
 diagramme de paquetages (Package diagram)
 diagramme de structures composites (Composite structure diagram)

 Diagrammes comportementaux / dynamiques (UML Behavior) :


 diagramme des cas d’utilisation (Use case diagram)
 diagramme d’activités (Activity diagram)
 diagramme d’états-transitions (State machine diagram)
 diagrammes d’interaction (Interaction diagram):
- diagramme de séquence (Sequence diagram)
- diagramme de communication (Communication diagram)
- diagramme global d’interaction (Interaction overview diagram)
- diagramme de temps (Timing diagram)

15 16

DIAGRAMMES DIAGRAMMES
COMPORTEMENTAUX COMPORTEMENTAUX
DIAGRAMME DES CAS D'UTILISATION

3
ENI - L3

Diagramme des cas d'utilisation…? Système


 Décrit les fonctionnalités d’un système d’un point de  Permet de délimiter le sujet de l’étude ;
vue utilisateur, sous la forme d’actions et de réactions ;  Possède :
 les cas d'utilisation,
 Permet de définir les limites du système et ses relations  mais pas les acteurs.
avec l’environnement ;
Nom du système

 Comprendre les besoins de l’utilisateur ;

 Sert à modéliser les aspects dynamiques d’un système ;

 Fait ressortir les acteurs et les fonctions offertes par le


système.

19 20

Acteur (1/3) Acteur (2/3)


 Un rôle joué par une entité extérieure au système ;  Trois types d’acteurs :
 Interactions directes avec le système ;  Humain : utilisateur du système à travers son interface graphique
 Humain, matériel externe, autre système ; (client, guichetier, vendeur..) ;

 Comment identifier les acteurs ?  Matériel : entité matérielle qui exploite les données du système ou
qui est piloté par le système (imprimante, robots, automates,…) ;
 Qui ont besoins le système pour réaliser le travail ?
 Qui vont exécuter les fonctions principales du système
(maintenance et administration) ?  Logiciel : entité logicielle existante et fonctionnelle qui communique
avec le système grâce à une interface logicielle (application de gestion,
 Est-ce que le système interagit avec le matériel ou autre système ? base de données,…).
 …
 Du point de vue système :
 Les acteurs principaux : pour lesquels l’objectif du cas d’utilisation est
essentiel ;
 Les acteurs secondaires : interagissent avec le cas d’utilisation mais
dont l’objectif n’est pas essentiel.

21 22

Acteur (3/3) Cas d'utilisation


Un moyen de représenter les différentes possibilités d'utiliser un système ;
 Relation entre acteurs : généralisation/spécialisation 
 Exprime toujours une suite d'interactions entre un acteur et l'application ;
 Dans le cas qu’un acteur peut être une spécialisation  Définit une fonctionnalité utilisable par un acteur ;
d’un autre acteur déjà défini.  Décrit par une forme verbale (Verbe à l’infinitif) ;

 Comment identifier les cas d'utilisation ?


 Qu’est ce que l’acteur attend de l’application ?
 Quelles informations l'acteur doit-il créer, sauvegarder, consulter, modifier,
détruire ?
 Y-a-t-il des événements externes que l’application doit connaître ? Quels
acteurs l’en informent ?
 …

23 24

4
ENI - L3

Exemple d’un diagramme Relation entre


des cas d'utilisation acteur et cas d'utilisation
Relation d’association :
 Représente l’interaction du système avec l’extérieur.

25 26

Relations entre cas d'utilisation Relations entre cas d'utilisation


(1/4) (2/4)
Relation d'inclusion (include) : Relation d‘extension (extend) :
 Le cas d’utilisation de base en incorpore  Le cas d’utilisation de base en incorpore
explicitement un autre, de façon obligatoire. implicitement un autre, de façon optionnelle.

27 28

Relations entre cas d'utilisation


Relations entre cas d'utilisation
(3/4)
(4/4)
Relation d‘extension (extend) :(suite)
 Condition d'extension nécessaire ; Relation de généralisation/spécialisation :
 Pour un cas particulier, la relation se traduit
soit par la généralisation/spécialisation.

 Liste éventuelle des points d'extension pour


préciser le moment auquel intervient
l’extension.

29 30

5
ENI - L3

Description textuelle Description textuelle


d’un cas d’utilisation (1/4) d’un cas d’utilisation (2/4)
 Permet de : Les informations à décrire :
 Précondition : quand et comment le cas d’utilisation débute ;
 clarifier le déroulement de la fonctionnalité ;
 Postcondition : quand et comment le cas d’utilisation se termine ;
 décrire la chronologie des actions qui devront
être réalisées.  Scénario nominal : description du fonctionnement du cas
d’utilisation dans le cas du scenario le plus probable ;
 Scénario alternatif : description du fonctionnement du cas
 Pas normalisée par UML ; d’utilisation pour une partie de scenario différente du scenario le
plus probable ;
 Mais beaucoup d'informations à structurer...;
 Scénario d’exception : description du fonctionnement du cas
 Plusieurs propositions dans la littérature ; d’utilisation pour une partie du scenario supplémentaire et
optionnelle ;

 Chaque cas d’utilisation doit être décrit en détail ;  Les variantes possibles et les cas d’erreurs ;
Les exigences non fonctionnelles.
 Commencer par les cas d’utilisation prioritaires. 

31 32

Description textuelle Description textuelle


d’un cas d’utilisation (3/4) d’un cas d’utilisation (4/4)
Exemple pour le cas d’utilisation «Payer par carte bancaire»
 Acteurs principaux : Acheteur (Client, Commerçant)  Scénario alternatif :
 Acteurs secondaires : Système Bancaire  A1: Le numéro de la carte bancaire est incorrect.
 Précondition : L’acheteur a validé sa commande.  Démarrage à l'étape 3 du scénario nominal.
 Début : L’acheteur arrive sur la page de paiement. 1. L’acheteur recommence de saisir les informations sur sa carte bancaire.
 Postcondition : La commande est validée, le compte de l'entreprise est crédité. 2. …
 Fin : …
 Scénario nominal :
 A2 : …
 …
1. L’acheteur choisit de faire le mode paiement par la carte bancaire.
2. Le système demande à l’acheteur les informations sur sa carte bancaire.
 Scénario d’exception :
3. L’acheteur saisit les informations sur sa carte bancaire.
 E1 : L’acheteur annule le payement par carte bancaire.
4. Le système vérifie que le numéro de carte bancaire est correct.
5. Le système demande l’autorisation de prélèvement au système bancaire.
 Contraintes non fonctionnelles :
6. Le système bancaire valide la transaction.
 Sécurité et confidentialité des échanges ;
7. Le système indique à l’acheteur que la commande est confirmée.  …

33 34

Conseils (1/3) Conseils (2/3)


 Fragmenter les cas d'utilisation si:
 Un diagramme de cas d'utilisation doit toujours rester  Interactions trop complexes;
simple;  Isolation de parties indépendantes possible.
 Donner un nom parlant (verbe à l'infinitif) à chaque cas
d'utilisation;  Il doit toujours y avoir au moins un acteur par cas d'utilisation:
 Compléter la spécification du cas d'utilisation:  Explicite pour les cas d'utilisation de plus haut niveau;
 Par une description textuelle;  Via les relations d'extension et d'inclusion pour les autres.
 Eventuellement à l'aide du diagramme d'activité.
 Ne pas modéliser à un niveau de détail trop précis:  Présentation des cas d'utilisation:
Entrer le nom du client  Par séquence de déclenchement / acteur;
 Par hiérarchisation;
Entrer le prénom du client
 Par domaine d'activité.
 Ne pas modéliser en dehors de l'application:
Choix des articles commandés
 Eviter:
…  De décomposer les cas d'utilisation / classes;
 Les cycles.

6
ENI - L3

Conseils (3/3) DIAGRAMMES


 Représentation du comportement normal de
l'application mais aussi:
 Des variations possibles;
COMPORTEMENTAUX
 Des situations exceptionnelles. DIAGRAMME DE SÉQUENCE

 Les cas d'utilisation doivent générer un résultat.

 Les cas d'utilisation doivent traduire ce que fait


l'application:
 Vision claire;
 Organiser les cas d'utilisations et les diagrammes.

 Vision complète:
 Représenter un maximum de choses;
 En respectant et en utilisant la notation choisie.

Diagramme de séquence…? Objet


 Représenté par un rectangle contenant le
 Représente les interactions entre objets selon un point
de vue temporel, on y met l'accent sur la chronologie nom de l’objet.
des envois de messages ;
Syntaxe d’un objet :
 Documente un ou plusieurs scénarios d’un cas [<nomObjet>] : [<NomClasse>]
d’utilisation ;
Nommant format Notation
 Montre :
 les réactions du système aux actions des utilisateurs ; Un objet d'une classe non spécifiée.
 la création et la manipulation des objets.
Un objet nommé d'une classe spécifiée.

 Utile en phase d'analyse, de conception et de test. Un objet sans nom d'une classe spécifiée.

39 40

Ligne de vie Barre d’activation


 Représente l’ensemble des  Un rectangle qui remplace
opérations exécutées par la ligne de vie ;
un objet ;
 Traduire l'activation de
 Ligne verticale pointillée
dirigée vers le bas à partir l'objet.
de chaque objet ;
 Symboliser une durée qui
dépend du scénario et du
comportement modélisé.

41 42

7
ENI - L3

Message (2/5)
Message (1/5)  Message synchrone : l’objet émetteur reste bloqué le temps lorsque l’objet
récepteur traite le message envoyé ;
 Généralement un appel, un signal ou une
réponse ;  Message asynchrone : l’objet émetteur n’est pas bloqué lorsque l’objet
récepteur traite le message envoyé ;

 Message de retour de l’invocation d’une méthode n’est pas systématique,


 Représentés par des flèches horizontales toutes les méthodes ne retournant pas un résultat ;
reliant la ligne de vie de l’objet émetteur à la Syntaxe d’un message retour :
ligne de vie de l’objet récepteur ; [<attribut> = ] message [ : <valeur_de_retour>]

Syntaxe d’un message :


[’[’Condition’]’[séquence][*[||
]’[’itération’]’]:][résultat:=]
message([paramètres])

43 44

Message (3/5) Message (4/5)


 Message de création : un message spécifique qui donne
lieu au début de la ligne de vie du nouvel objet ;  Message réflexif : un objet peut envoyer un
message à lui-même.
 Message de destruction : un message envoyé à un objet
existant et qui donne lieu à la fin de sa ligne de vie.

45 46

Message (5/5) Fragments combinés (1/15)


 Regroupements logiques représentés par un rectangle et
contenant les structures conditionnelles qui affectent le flux
 Message récursif se représente par un de messages ;
 Pour décrire les diagrammes de séquence de manière
dédoublement de la barre d’activation. compacte ;
 Définis par un opérateur et des opérandes ;

 L'opérateur conditionne la signification du fragment combiné ;

 Les diagrammes peuvent se référencer les uns les autres :


 Pointeur / raccourci vers un diagramme de séquence
complètement décrit ;
 Pour factoriser les parties de comportements à plusieurs
endroits.

47 48

8
ENI - L3

Fragments combinés (2/15) Fragments combinés (3/15)


Différents fragments combinés d’opérateur d’interaction :
 Les opérateurs de base :
 alt
 opt
 loop
 par
 seq
 strict

 Les opérateurs pour les situations exceptionnelles :


 break

 Les opérateurs pour les tests:


 critical
 ignore
 consider
 negative
 assert

49 50

Fragments combinés (4/15) Fragments combinés (5/15)


Les opérateurs de base (suite)
Les opérateurs de base
 Operateur « Option » ou opt:
 Operateur « Alternative » ou alt:
 Exprime la possibilité de choisir différents
 Représente un choix dans le comportement où
comportements ; soit seul l’opérande d’interaction contenu dans le
fragment combiné s’exécute, soit rien ne se
 Réalisé par le choix d’un unique opérande produit ;
d’interaction en fonction des contraintes
d’interaction.
 Correspond à un alt sans else.

51 52

Fragments combinés (7/15)


Fragments combinés (6/15) Les opérateurs de base (suite)
 Operateur « Parallel » ou par:
Les opérateurs de base (suite)  Désigne un interclassement (ou entrelacement) entre les
 Operateur loop: comportements des opérandes ;
 Représente une boucle ;
 Les occurrences des évènements des divers opérandes
d’interaction peuvent être entrelacées de toutes les façons tant
 L’opérande d’interaction sera répété un que l’ordre impose par chaque opérande est préservé.
certain nombre de fois.

53 54

9
ENI - L3

Fragments combinés (8/15)


Fragments combinés (9/15)
Les opérateurs de base (suite)
 Operateur seq : Les opérateurs de base (suite)
 Operateur strict :
 Désigne un entrelacement faible entre les
 Définît un séquencement strict entre les comportements
comportements des opérandes. des opérandes.

55 56

Fragments combinés (10/15) Fragments combinés (11/15)


Les opérateurs pour les situations Les opérateurs pour les tests
exceptionnelles  Operateur critical :
 Operateur break :  Représente une région critique ;
 Représente un scénario d’arrêt qui est  Les occurrences d’évènement ne peuvent pas être
exécuté à la place du reste du fragment entrelacées avec les traces de la région critique ;
d’interaction englobant.  La région doit être traitée de manière atomique.

57 58

Fragments combinés (12/15) Fragments combinés (13/15)


Les opérateurs pour les tests (suite) Les opérateurs pour les tests (suite)
 Operateur ignore :
 Indique que les types de certains messages sont ignorés dans le  Operateur consider :
fragment combiné ;
 Seuls certains messages vont être considérés à
 Les messages ignorés peuvent apparaitre à n’importe quel
endroit de la trace. l’intérieur du fragment combiné.

59 60

10
ENI - L3

Fragments combinés (14/15) Fragments combinés (15/15)


Les opérateurs pour les tests (suite)
Les opérateurs pour les tests (suite)  Operateur « Assertion » ou assert :
 Operateur « Negative » ou neg :  Représente une assertion ;
 Définit des traces invalides.  La séquence de trace de l’opérande décrit
par l’assertion est la seule trace valide.

61 62

Exemple d’un diagramme de séquence Changement de niveau d’abstraction


du système par rapport au diagramme de
séquence système

63

Stéréotypes de Jacobson (1/2) Stéréotypes de Jacobson (2/2)


À l’intérieur du système, Jacobson Il existe des règles précises sur les interactions
distingue les trois stéréotypes suivants : possibles entre instances de ces trois types de
classes:
 Les acteurs ne peuvent interagir (envoyer des
Stéréotype Symbole Description
<<boundary>> Ce sont les classes qui serve nt à modéliser les
interactions entre le système et ses acteurs. messages) qu’avec les dialogues (Boundary);
<<control>> Ce sont les classes utilisées po ur représenter la  Les dialogues (Boundary) peuvent interagir avec
coordination, l’enchaînement et le contrôle d’autres
objets – elles sont en général reliées à un cas les contrôles;
<<entity>>
d’utilisation particulier .
Ce sont les classes qui serve nt à modéliser des
 Les contrôles (Controller) peuvent interagir avec
informations durables et souvent persistantes les dialogues, les entités, ou d’autres contrôles;
 Les entités (Entity) ne peuvent interagir qu’entre
elles.

11
ENI - L3

Exemple d’un diagramme de Conseils


Toujours donner le contexte du diagramme du cas d’utilisation;
séquence de conception

 Indiquer précisément le but du scénario;

 Bien préciser:
 l’acteur qui déclenche le scénario;
 le résultat observable de l’exécution du cas d’utilisation.

 Faire apparaître un objet interface/application entre l’acteur et


les objets du système;

 Soigner la succession des appels.

NB:
 Ne pas confondre le cas d’utilisation / diagramme de séquence;
 Cohérence diagramme de classe / diagramme de séquence.

DIAGRAMMES Diagramme de communication…?


COMPORTEMENTAUX  Aussi appelé diagramme de collaboration en UML
DIAGRAMME DE COMMUNICATION 1.x ;
 Représentation des scénarios ;
 Interaction entre les objets ;
 Définit une communication particulière entre les
objets ;
 Représentation simplifiée d'un diagramme de
séquence :
 Pas de ligne de vie ;
 Même syntaxe d’objet au diagramme de séquence.

 Messages séquentiels numérotés.

70

Diagramme de séquence Diagramme de séquence


et et
Diagramme de communication (1/3) Diagramme de communication (2/3)
 Diagramme séquence :
 Deux vues du même phénomène :  Se focalise sur les aspects temporels ;
 Importance des messages ;
Il existe des outils supportant UML qui  Modélise la création/destruction d'objets ;
Montre l'activation des objets ;
permet de créer automatiquement le 
 Décrit les scénarios complexes ;
diagramme de communication (ou  Permet la modularité de la représentation.

collaboration) à partir du diagramme de  Diagramme de communication :


séquence.  Se focalise sur la représentation spatiale ;
 Adapté pour montrer les liens ;
 Donne la priorité à figuration des interactions ;
 Pas de modularité de la représentation.

71 72

12
ENI - L3

Diagramme de séquence
Exemple d’un diagramme
et
de communication du système
Diagramme de communication (3/3)

73 74

Exemple d’un diagramme


LES DIAGRAMMES
de communication de conception
COMPORTEMENTAUX
DIAGRAMME D’ÉTATS – TRANSITIONS

75

Diagramme d’états-transitions…? État


 Ensemble des valeurs qui impliquent la même réponse à
 Aussi appelé diagramme de machine d'état ; l’arrivée d’un événement ;
 Décrit le comportement des objets d’une classe au moyen  Situation durant la vie d’un objet pendant laquelle :
d’un automate d’états associé à la classe ;  il satisfait une certaine condition ;
 Le comportement est modélisé par un graphe :  il exécute une certaine activité ;
- Nœuds = états possibles des objets ;  ou il attend un certain évènement.
- Arcs = transitions d’état à état.
 Chaque objets possède à un instant donné un état particulier ;
 Montre les états remarquables des objets du système ;  Un état est stable et durable ;
 Permet d’autoriser/interdire les traitements sur les objets ;  Chaque état est identifié par un nom ;
 Il est possible de n’avoir aucun état final : un système qui ne
 Pas de diagramme si la classe n’a pas d’états différents ; s’arrête jamais.
 Un diagramme est attaché à une seule classe.

77 78

13
ENI - L3

Action et activité (1/2) Action et activité (2/2)


 Action :
 opération instantanée qui ne peut être interrompue ;
 être associée à une transition ;
 peut être exécutées :
- lors d’une transition (ex : action4) ;
- en entrant dans un état (ex : action1) ;
- en sortant d’un état (ex : action3).

 Activité : Exemple :
 une opération d’une certaine durée qui peut être interrompue ;
 être associée à un état d’un objet ;
 peut être exécutées dans un état (ex : activité2).

79 80

Evénement Transition
 Un fait survenu qui déclenche une transition ;

 Types d’événements :
 Réponse
d’un objet à l’occurrence d’un
 Type appel de méthode (call) – C’est le type d’évènement qui représente la réception de
l'appel d'une opération par un objet. Les événements d'appel sont des méthodes déclarées au
évènement ;
niveau du diagramme de classes ;

 Une relation entre deux états ;


 Type signal – C’est la réception d’un signal asynchrone, explicitement émis par un autre objet ;

 Type changement de valeur (vrai/faux) – C’est le cas de l’évaluation d’une expression  Syntaxe d’une
transition :
booléenne ;
événement[garde]/action
 Type écoulement du temps – C’est un événement lié à une condition de type after (durée) ou
when (date).

81 82

Point de jonction
Point de choix
 Permet de décomposer une transition en  Se comporte comme un test de type : si
deux parties en indiquant si nécessaire les condition faire action1 sinon faire action2.
gardes propres à chaque segment de la
transition.

83 84

14
ENI - L3

Etat composite Point d’entrée et de sortie


 Permet de structurer de manière  Repérer un point d’entrée et un point de
hiérarchique les états et les transitions. sortie particuliers sur une sous-machine
d’état.

85 86

Exemple d’un diagramme


État historique d’états-transitions
 Permetde pouvoir indiquer la réutilisation
du dernier état historisé en cas de besoin.

87 88

Conseil DIAGRAMMES
 Cohérence entre la classe et le diagramme
COMPORTEMENTAUX
DIAGRAMME D’ACTIVITÉS
d’états-transitions.

15
ENI - L3

Diagramme d'activités…? Nœud de bifurcation (fourche)


 Création des plusieurs flots concurrents en sortie de la
 Variante des diagrammes d’états- barre de synchronisation à partir d’un flot unique entrant.
transitions ;

 Permet de représenter le
comportement interne d’un cas
d’utilisation ou processus ;
 Représente le déroulement des
traitements en les regroupant dans
des étapes appelées « Activité » ;

 Prend en charge les


comportements parallèles.
91 92

Nœud de jonction (synchronisation) Nœud de test-décision


 Production d’un flot unique sortant à partir de plusieurs flots  Permet de faire un choix entre plusieurs flots sortants en
concurrents en entrée de la synchronisation ; fonction des conditions de garde de chaque flot ;
 Symétrique du nœud de bifurcation.  N’a qu’un seul flot en entrée ;

 On peut aussi utiliser seulement deux flots de sortie : le


premier correspondant à la condition vérifiée et l’autre
traitant le cas sinon.

93 94

Nœud de fusion-test Couloir d’activités (Responsabilité)


 Permet d’avoir plusieurs flots entrants  Préciser la responsabilité de différents acteurs ;
possibles et un seul flot sortant ;  Chaque activité est allouée à un couloir
 Le flot sortant est donc exécuté dès qu’un correspondant à la ressource concernée.
des flots entrants est activé.

95 96

16
ENI - L3

Nœud d’objet Autres notations (1/2)


 Souvent, différentes activités manipulent un  Signal reçu : un événement pour le processus étudié ;
même objet qui change alors d’état selon le  On le représente par un pentagone concave.
degré d’avancement du mécanisme ;  Signal envoyé : un résultat émis par le processus étudié ;
 Un résultat de l’activité (lié par une flèche)  On le représente par un pentagone convexe.
et repris comme événement pour l’activité  Evénement temporel : une date ou un délai ;
suivante.  On le représente par deux triangles isocèles inversés (en tête
bêche).

 Nœud de départ du diagramme ;


 On le représente par un petit cercle plein.

 Nœud de fin du diagramme ;


 On le représente par un cercle vide contenant un petit cercle
plein.

97 98

Exemple d'un diagramme d'activités


Conseils (1/2)
 A utiliser pour documenter les cas
d'utilisation:
 Les cas d'utilisation en extension doivent
apparaître dans le cadre d'un branchement /
fusion qui explicite la condition d'extension;

 Distinguer les cas d'utilisation des tâches qui


les constituent:
- Actions / Activités;
- Stéréotypes.

99

Conseils (2/2) DIAGRAMMES


A utiliser à bon escient;
COMPORTEMENTAUX
DIAGRAMME GLOBAL D'INTERACTION
 Peuvent devenir trop complexes.

17
ENI - L3

Exemple d’un diagramme


Diagramme global d'interaction…? global d'interaction
 Nouveau diagramme d’UML 2.x ;
 Mélange du diagramme d'activités et du
diagramme de séquence.

103 104

DIAGRAMMES Diagramme de temps…?


COMPORTEMENTAUX  Nouveau diagramme d’UML 2.x ;
DIAGRAMME DE TEMPS
 Permet de représenter les changements
d’états et des interactions entre objets liés à
des contraintes de temps ;

 A faire après le diagramme d’états-transitions ;

 Vient du domaine du hardware ;


 Plutôt pour les systèmes temps réel.

106

Représentations Concepts
 Deux représentations graphiques possibles :  Concepts représentés :
 représentation « en escalier » ;  la ligne de vie ;
 représentation linéaire.  l’évènement ;
 l’état ;
 la contrainte de durée.

107 108

18
ENI - L3

Exemple d’un diagramme de temps Exemple d’un diagramme de temps


avec représentation « en escalier » avec représentation linéaire

109 110

DIAGRAMMES DIAGRAMMES
STRUCTURELS STRUCTURELS
DIAGRAMME DE CLASSES

Diagramme de classes…? Classe, attribut et opération (1/6)


Classe :
 Diagramme pivot de l’ensemble de la  Décrire un groupe d’objets ;
modélisation d’un système ;  Rectangle comportant plusieurs compartiments :
 Compartiment 1 : nom de la classe,
 Compartiment 2 : attributs,
 Permet de donner la représentation statique du  Compartiment 3 : opérations,
système à développer;  Possibilité d’ajouter les compartiments des responsabilités et/ou
exception.
 Différents niveaux de détail possibles : possibilité d’omettre des
 Fondé sur : attributs et/ou des opérations.
 le concept d’objet,
 le concept de classe comprenant les attributs et
les opérations,
 les différents types d’association entre classes.

113 114

19
ENI - L3

Classe, attribut et opération (2/6) Classe, attribut et opération (3/6)


Attribut : Attribut : (suite)
 Propriété élémentaire d’une classe.  Syntaxe :
visibilité/nomAttribut : type [= valeurInitiale
{propriétés}]

 visibilité : + (public), - (privé), # (protégé), ~ (package)


 nomAttribut : nom unique dans sa classe
 type : type primitif (Entier, Chaîne, ...) ou classe
 valeurInitiale : valeur initiale à la création de l’objet
 propriétés : valeurs marquées facultatives ({gelé}, {variable},
{ajoutUniquement}, ...)

 Attributs de classe (statiques) soulignés ;

 Attributs dérivés précédés de "/".

115 116

Classe, attribut et opération (4/6) Classe, attribut et opération (5/6)


Opération : Opération : (suite)
 Syntaxe :
 Fonction applicable aux objets d’une classe ; visibilité nomOpération (paramètres)
 Décrire le comportement d’un objet. [:[typeRésultat] {propriétés}]

 visibilité: + (public), - (privé), # (protégé), ~ (package)


 nomOpération: utiliser un verbe représentant l’action à réaliser
 paramètres: liste des paramètres selon le format
 typeRésultat: type de la valeur retournée (type primitif ou classe)
 propriétés: valeurs facultatives applicables ({query}, …)

 Opérations abstraites/virtuelles (non implémentées) en italique ;


 Opérations de classe (statiques) soulignées ;
 Possibilité d’annoter avec des contraintes stéréotypées
«precondition» et «postcondition» : programmation par
contrats ;
 Possibilité de surcharger une opération : même nom, mais paramètres
différents ;
117 118

Association, multiplicité,
Classe, attribut et opération (6/6)
navigabilité et contraintes (1/6)
Visibilité des attributs et opérations : Association:

 Public(+):Attribut ou opération visible par tous  Représenter les liens existant entre les instances des classes ;
 Privé(-):Attribut ou opération seulement visible à l’intérieur  Porter un nom (signification).
de la classe.
 Protégé(#): Attribut ou opération visible seulement à
l’intérieur de la classe et pour toutes les sous-classes de la classe
 Paquetage(~):Attribut ou opération ou classe seulement
visible à l’intérieur du paquetage où se trouve la classe.

119 120

20
ENI - L3

Association, multiplicité, Association, multiplicité,


navigabilité et contraintes (2/6) navigabilité et contraintes (3/6)
Association: (suite) rôle d’ association Multiplicité :
 Précise le rôle d’une classe au sein de l’association ;
 Indique un domaine de valeurs pour préciser le
 Explicite le nom de l’association si besoin.
nombre d’instance d’une classe vis-à-vis d’une autre
classe pour une association donnée.

1 un et un seul
0 .. 1 zéro ou un
M .. N de M à N (entiers naturels)
* de zéro à plusieurs
0 .. *
1 .. * de un à plusieurs
N exactement N (entier naturel)

121 122

Association, multiplicité, Association, multiplicité,


navigabilité et contraintes (4/6) navigabilité et contraintes (5/6)
Navigabilité : Navigabilité : (suite)

 Indique si l’association fonctionne de manière


unidirectionnelle ou bidirectionnelle.

123 124

Association, multiplicité,
Association réflexive
navigabilité et contraintes (6/6)
Contraintes :
 Définit les liens entre des objets d’une
 Ordre de tri (multiplicité supérieure à 1) : même classe.
 non ordonnés (valeur par défaut),
 ordonnés ou triés lorsque l’on est au niveau de
l’implémentation (tri sur une valeur interne).

125 126

21
ENI - L3

Classe-association Association n-aire


 Permet de décrire soit des attributs soit des  Association reliant plus de deux classes.
opérations propres à l’association.

127 128

Agrégation et composition (1/2) Agrégation et composition (2/2)


Composition :
Agrégation:
 Besoin d’être nommées : « contient », « est composée de »;
 Pas besoin d’être nommées : « contient »,  Durées de vie liées composants/composé.
« est composée de » ;
 Durées de vie indépendantes des objets.

129 130

Généralisation et spécialisation (1/4) Généralisation et spécialisation (2/4)


Généralisation et spécialisation :
Elles sont des points de vue portés sur les hiérarchies de classes.
Classe abstraite :
 Généralisation :
 consiste à factoriser dans une classe, appelée superclasse, les attributs et/ou opérations  Pas d’instance directe ;
des classes considérées ;  Classes descendantes ayant des instances ;
 permet de réaliser une hiérarchie des classes.
 Indiquée en italique de manière générale.
 Spécialisation :
 représente la démarche inverse de la généralisation ;
 consiste à créer à partir d’une classe, plusieurs classes spécialisées ;
 Chaque nouvelle classe créée est dite spécialisée puisqu’elle comporte en plus des
attributs ou opérations de la super-classe (disponibles par héritage) des attributs ou
opérations qui lui sont propres.

131 132

22
ENI - L3

Généralisation et spécialisation (3/4) Généralisation et spécialisation (4/4)


Héritage avec recouvrement :
Héritage multiple :
 {chevauchement}(ou {inclusif}) : deux sous-classes peuvent avoir, parmi leurs
 Une classe peut hériter des plusieurs
instances, des instances identiques ;
 {disjoint}(ou{exclusif}) : les instances d’une sous-classe ne peuvent être


incluses dans une autre sous-classe de la même classe ;
{complète}: la généralisation ne peut pas être étendue ; super-classes.
 {incomplète}: la généralisation peut être étendue.

133 134

Association qualifiée, Association qualifiée,


dépendance et classe d’interface (1/3) dépendance et classe d’interface (2/3)
Qualification :
Dépendance :
 Relation entre deux classes permettant de préciser la  Permet de représenter l’existence d’un lien sémantique ;
sémantique de l’association et de qualifier de manière  Une classe B est en dépendance de la classe A si des éléments de la
restrictive les liens entre les instances. classe A sont nécessaires pour construire la classe B.

135 136

Association qualifiée,
dépendance et classe d’interface (3/3) Quelques stéréotypes et mots-clés
Classe d’interface :
 Décrire la vue externe d’une classe ;  « Classe d’implémentation » : ce
 Classe sans compartiment des attributs ;
Comporte la liste des opérations accessibles par les autres classes ;
stéréotype est utilisé pour décrire des classes de
niveau physique.

 Se note avec le stéréotype <<interface>> ou avec un rond.

 « Type » : ce stéréotype permet de spécifier des


opérations applicables à un domaine d’objets.

 « Utilitaire » : ce stéréotype qualifie toutes


les fonctions utilitaires de base utilisées par les objets.

 « MétaClasse » : ce stéréotype permet de


regrouper des classes dans une famille de classe.

137

23
ENI - L3

Exemple d’un diagramme de


Exemple d’un diagramme de classes
classes de conception

139 140

Conseils DIAGRAMMES
 Ne pas confondre classe et acteur; STRUCTURELS
 Relation 1-1 possible mais à justifier; DIAGRAMME D'OBJETS
 Une classe doit:
 Correspondre à une seule responsabilité;
 Représenter une abstraction pertinente;
 Etre bien nommée;
 Etre complètement décrite à un endroit du
document;

 Cohérence entre les diagrammes.

Diagramme d’objets…? Objet (1/2)


 Instance particulière d’une classe :
 Aussi appelé diagramme d'instance ;  Nom de l’objet ;

 Ensemble d'objets respectant les contraintes Syntaxe d’un objet (comme dans le diagramme de séquence et le
diagramme de communication) :
du diagramme de classes : nomObjet : NomClasse

 respect des cardinalités ;  Valeurs d’attribut (optionnelles);


 chaque attribut d'une classe a une valeur Syntaxe pour la valeur d’attribut :
nomAttribut = valeurAttribut
affectée dans chaque instance de cette Exemple:
classe.

 Facilite la compréhension de structures


complexes.

143 144

24
ENI - L3

Objet (2/2) Liens (1/4)


Nommage de l’objet :  Lesvaleurs des attributs sont optionnelles
ainsi que les liens entre objets.
Nommant format Notation
Un objet d'une classe non spécifiée.

Un objet nommé d'une classe spécifiée.

Un objet sans nom d'une classe spécifiée.

145 146

Liens (2/4) Liens (3/4)


 Les liens instances des associations réflexives  Lesliens d’arité supérieure à 2 ou la
peuvent relier un objet à lui-même. multiplicité peuvent être représentés.

147 148

Diagramme de classes
Liens (4/4) et
 Les objets composés de sous-objets peuvent être représentés au Diagramme d'objets
moyen d'un objet composite.

 Le diagramme de classes représente un


cas général.
 Les objets composites sont instances de classes composites.

 Le diagramme d'objets représente un cas


particulier.

149 150

25
ENI - L3

Exemple d’un diagramme d’objets DIAGRAMMES


STRUCTURELS
DIAGRAMME DE STRUCTURES COMPOSITES

151

Diagramme de structures composites…? Classificateur, port , et partie


 Aussi appelé diagramme d‘architecture ;  Classificateur :
 Décrit les caractéristiques structurelles et
 Nouveau diagramme d’UML 2.x ; comportementales.
 Représentation de la collaboration d’instances de
classes via des liens de communication ;  Port :
 Relie les classificateurs avec son environnement ou ses
 Même rôle qu’un diagramme de classes ; parties internes ;
 Spécifier les points d'interactions d'un objet.
 Permet d’afficher :
 Partie :
 la structure interne d’un classificateur ;  Représente une ou plusieurs instances d'une classe grâce à
 les interactions avec l’environnement par le bais des contraintes de multiplicité;
des ports ;  Zone bien délimitée à l’intérieur d’une classe ou d’un
composant.
 un comportement d’une collaboration.

153 154

Exemple DIAGRAMMES
STRUCTURELS
DIAGRAMME DE COMPOSANTS

155

26
ENI - L3

Diagramme de composants…? Composant


 Partie modulaire d’un système qui encapsule son contenu ;
 Permet de représenter les composants  Définir le comportement en termes d’interfaces fournies et
logiciels d’un système, et les liens existant requises ;
entre ces composants ;  Il peut être :
 Pour les systèmes complexes.  les codes sources ;
 les exécutables et bibliothèques ;
 les tables, les fichiers, les documents.

 Caractérisé par :
 un nom ;
 un port de connexion ;
 une spécification externe sous forme soit d’une ou plusieurs
interfaces requises, soit d’une ou plusieurs interfaces fournies.

157 158

Port de connexion et interface de


Relation entre composants (1/3)
composant Connecteur d’assemblage :
 Port de connexion :
 Représente le point de connexion entre le composant et une
 Regroupement de deux composants par
interface. un connecteur d’assemblage.
 Interface de composant :
 Interaction entre composants au travers des interfaces fournies
et requises ;
 Une interface requise est une interface nécessaire au bon
fonctionnement du composant ;
 Une interface fournie est une interface proposée par le
composant aux autres composants.

159 160

Relation entre composants (2/3) Relation entre les composants (3/3)


Dépendance : Contenance :

 Regroupé par la flèche de dépendance.  Un composant peut être contenu dans un


autre composant.

161 162

27
ENI - L3

Exemple
Connecteur de délégation
d’un diagramme de composants
 L'interface fournie d'un composant peut
être réalisée par l'une de ses parties
internes ;
 Son interface requise peut être imposée
par l'une de ses parties ;
 Les connecteurs de délégation montrent
que ces parties internes réalisent ou
utilisent les interfaces du composant,
pouvant être stéréotypé « delegate ».
163 164

DIAGRAMMES Diagramme de déploiement…?


STRUCTURELS  Permet de représenter l’architecture
physique supportant l’exploitation du
DIAGRAMME DE DEPLOIEMENT
système ;
 Constitué de « nœuds » connectés par
des voies physiques ;
 Montre des instances de nœuds (un
matériel précis), ou des classes de nœuds.

166

Nœud Relation entre nœuds (Association)


 Représente un ensemble d'éléments matériels du  Indique une voie physique (connexion
système ; ethernet, bus de communication, …) entre
 Interconnectés par intermédiaire d’un réseau deux nœuds.
d’éléments physiques ;
 Contient un ou plusieurs composants qui peuvent
être liée entre eux ;
 Prend en charge l’exécution des composants ;
 Un nœud ou une instance de nœud se représente
par un cube ou parallélépipède.

167 168

28
ENI - L3

Exemple
DIAGRAMMES
d’un diagramme de déploiement
STRUCTURELS
DIAGRAMME DE PAQUETAGES

169

Paquetage
Diagramme de paquetages…?  Elément de modélisation qui contient d'autres éléments de modélisation : des
classes, des interfaces, des composants, des nœuds, des cas d’utilisation, des
diagrammes, d’autres paquetages… ;
 Nouveau diagramme d’UML 2.x ;  Possible de ne pas représenter tous les éléments contenus ;

 Représenter la structure hiérarchique et  Peut importer les éléments d’un autre paquetage ;
modulaire ;  Peut-être fusionné avec un autre paquetage ;
 Elément peut avoir une visibilité déclarée soit de type public(+) soit
 Permet de regrouper les éléments de privé(-).

modélisation.

171 172

Espaces de nom Dépendance entre paquetages (1/3)


 « import » :
 Deux éléments ne peuvent pas avoir le même nom dans un  correspond à un lien ayant une visibilité « public » ;
paquetage ;  permet d’importer l’espace de nommage d’un autre paquetage ;
tous les membres du paquetage donné ont accès à tous les noms des membres du paquetage importé sans avoir
 Deux éléments dans deux paquetages différents sont

à utiliser explicitement le nom du paquetage concerné.
différents, quel que soit leur nom ;
« access » :
 Nom complet = nom préfixé par les noms des paquetages 
correspond à un lien ayant une visibilité « privé » ;
englobant : Banque::Compte ≠ Commerce::Compte 
 permet d’avoir accès à l’espace de nommage d’un paquetage cible ;
 L’espace de nommage n’est donc pas importé et ne peut être transmis à d’autres
paquetages par transitivité.

173 174

29
ENI - L3

Dépendance entre paquetages (2/3) Dépendance entre paquetages (3/3)


 « merge » :
« uses » :  Permet de fusionner deux paquetages et d’obtenir ainsi un
paquetage contenant la fusion des deux paquetages d’origine.
 B nécessite A pour sa mise en œuvre ou
son fonctionnement ;
 La nature de l’utilisation peut être :
- l’invocation d’une opération ;
- la création d’un objet.

175 176

Généralisation des paquetages Exemple d’un diagramme


 Comparable à celle de la classe ;
 Possible d’ajouter ou de spécialiser les éléments de
de paquetages (1/2)
paquetages en modélisant les relations de généralisation
entre paquetages ;
 Les éléments publics et protégés sont alors accessibles dans
les paquetages de spécialisation ; les éléments privés non.

177 178

Exemple d’un diagramme


de paquetages (2/2)

Outils supportant UML

179

30
ENI - L3

Critères de sélection
Outils UML
des outils UML
 Respect des normes UML ;  ArgoUML
 Plateforme supportés ;  BOUML
 Stabilité;  Enterprise Architect
 Exhaustivité des diagrammes ;  Modelio
 Correspondance relationnel ;
 Objecteering
 Licence ;
 Code source ouverte ;
 Open ModelSphere
 Génération de code ;  Poseidon
 Rétro-ingénierie;  Rational Rose
 Format de documentation ;  StarUML
 Gestion de configuration ;  Visual Paradigm for UML
 Gestion de tests ;  WinDesign Module OBJECT
 Intégration IDE.  …

181 182

Bibliographie
 Fien VAN DER HEYDE et Laurent DEBRAUWER (2008). UML 2 : Initiation,
exemples et exercices corrigés (2ième édition). Saint-Herblain : Editions ENI.
 Hugues M., Jean-Pierre S. et Gilles M. Règles de cohérence UML 2.0 (Version
1.1).
 James R., Ivar J. et Grady B. (2004). The Unified Modeling Language - Reference
Manual (2e ed.). Canada : Addison Wesley.

Bibliographie et webographie
 Joseph Gabay et David Gabay (2008). UML 2 : Analyse et Conception - Mise en
œuvre guidée avec études de cas. Paris : Dunod.
 OMG (2003). UML 2.0 Superstructure Specification.
 Pascal Roques (2008). Les Cahiers du Programmeur : UML 2 - Modéliser une
application web (4ème édition). France : Editions Eyrolles.
 Pascal Roques et Franck Vallée (2007). UML 2 en action - De l’analyse des
besoins à la conception (4ème éd.). France : Editions Eyrolles.
 Pierre-Alain Muller et Nathalie Gaertner (2004). Modélisation objet avec UML.
France : Editions Eyrolles.
 Pierre-Allain Muller (1997). Modélisation objet avec UML. France : Editions
Eyrolles.

184

Webographie
 http://bdd.crzt.fr/mod/prs/co/modUE04.ht
ml?mode=html
 http://uml.free.fr/
 http://www.omg.org/
 http://www.uml-diagrams.org
 https://openclassrooms.com
 https://www.ibm.com
 www.agilemodeling.com/essays/umlDiagra
ms.htm

185

31

Vous aimerez peut-être aussi