COURS UML INFORMATQIUE TELECOM2 2007.pdf

UML
Université Aube Nouvelle - Année 2017-2018
Technologie de Génie Informatique/ IT2
Mme KAM / SOGLI Y. Evelyne
1

Plan (1/4)
Chapitre I : préalable
I-Système d’information
I-1-Définition
I-2-Rôle
II-Etapes de Réalisation d’un SI
II‐1‐Expression Des besoins
II‐2 Analyse
II‐3‐ Conception
II‐4‐ Implémentation
II‐5‐ Tests, vérification et validation
II‐6‐ Maintenance et Evolution
2

Plan (2/4)
Chapitre I : préalable
III‐Notion de modèle
III‐1‐Définition
III‐2‐utilité
III‐3‐Langage de modélisation
IV‐Introduction au concept orienté objet
IV‐1‐approche orienté objet
Iv‐2‐ concepts importants de l’approche orienté objet
3

Plan (3/4)
Chapitre II‐ UML
I‐ Présentation UML
I‐1‐Definition et Historique
I‐2‐ Briques de base d’UML
II‐Comment modéliser avec UML
III‐Diagramme d’UML
III‐1‐Diagramme de cas d’utilisation (CU)
4

Plan (4/4)
Chapitre II‐ UML
III‐2‐Diagramme de séquence
III‐3‐Diagramme de collaboration
III‐4‐Diagramme de classe
III‐5‐Diagramme objet
III‐6‐Diagramme d’activité
III‐7‐les autres diagrammes UML
Conclusion
Webographie
5

I‐1‐ Définition
Un système d’information représente l’ensemble des éléments
participant à la gestion, stockage, traitement, transport et
diffusion de l’information au sein d’une Organisation.
I‐2‐ Rôle
Collecte d’informations
Stockage de l’information
Traitement de l’information
Diffusion de l’information
6
CHAPITRE I : Préalable – I ‐ Système d’information

II‐1 Expression Des besoins
7
L'expression des besoins comme son nom l'indique, permet de définir les différents
besoins :
inventorier les besoins principaux et fournir une liste de leurs fonctions
recenser les besoins fonctionnels (du point de vue de l'utilisateur) qui
conduisent à l'élaboration des modèles de cas d'utilisation
appréhender les besoins non fonctionnels (technique) et livrer une liste des
exigences.
CHAPITRE I : Préalable – II‐ Etapes de Réalisation d’un SI

II‐2‐Analyse
L'objectif de l'analyse est d'accéder à une compréhension des besoins et des exigences du
client. Il s'agit de livrer des spécifications pour permettre de choisir la conception de la
solution.
Un modèle d'analyse livre une spécification complète des besoins issus des cas d'utilisation
et les structures sous une forme qui facilite la compréhension (scénarii), la préparation
(définition de l'architecture), la modification et la maintenance du futur système.
Il s'écrit dans le langage des développeurs et peut être considéré comme une première
ébauche du modèle de conception.
8

II‐3‐Conception
La conception permet d'acquérir une compréhension approfondie des
contraintes liées au langage de programmation, à l'utilisation des
composants et au système d'exploitation.
Elle détermine les principales interfaces et les transcrit à l'aide d'une
notation commune.
Elle constitue un point de départ à l'implémentation :
¾ elle décompose le travail d'implémentation en sous‐système;
¾ elle créée une abstraction transparente de l'implémentation.
9

II‐4‐Impléméntation
L'implémentation est le résultat de la conception pour
implémenter le système sous formes de cinq (5) composants, c'est‐
à‐dire de code source, de scripts, de binaires, d'exécutables et
d'autres éléments du même type.
Les objectifs principaux de l'implémentation sont de planifier les
intégrations des composants pour chaque itération, et de produire
les classes et les sous‐systèmes sous formes de codes sources.
10
CHAPITRE I : Préalable – II ‐ Etapes de Réalisation d’un SI

II‐5‐Tests ,vérification et validation
Les tests permettent de vérifier des résultats de l'implémentation en
testant la construction.
Pour mener à bien ces tests, il faut les planifier pour chaque
itération, les implémenter en créant des cas de tests, effectuer ces
tests et prendre en compte le résultat de chacun.
Après vérification, lorsque les résultats sont concluants, les tests
doivent être validés.
11

II‐6‐Maintenance et évolution
c’est l’une des phases le plus souvent négligées. Il convient d’assurer
la maintenance corrective et évolutive du système, pour qu’il soit
toujours en symbiose avec les avancées technologiques et qu’il
réalise toujours les opérations pour lesquelles il a été mis en place.
12

III‐1‐definition
Un modèle est une représentation partielle de la réalité
Abstraction de ce qui est intéressant pour un contexte donné
Vue subjective et simplifiée d'un système
Avec UML, on va s'intéresser principalement aux modèles d'applications
informatiques
Un modèle UML = des diagrammes UML
III‐2‐Utilité des modèles
Faciliter la compréhension d'un système
Permettre également la communication avec le client
Vision de communication, de documentation
Définir voire simuler le fonctionnement d'un système
Dans ce cas, on se doit d'être le plus précis possible dans le contenu des
modèles pour s'approcher du code
Vision de développement, de production
13
CHAPITRE I : Préalable – III – Notion de modèle

III‐3‐Langage de modélisation
Langage graphique pour représenter, communiquer les divers
aspects d’un système d’information
Possède un vocabulaire et des règles qui permettent de
combiner les mots afin de communiquer
Langage utilisé pour exprimer un modèle
14
CHAPITRE I : Préalable – III – Notion de modèle

IV‐1‐l’approche orienté objet (1/3)
L'approche considère le logiciel comme une collection d'objets dissociés,
identifiés et possédant des caractéristiques. Une caractéristique est soit un
attribut (i.e. une donnée caractérisant l'état de l'objet), soit une entité
comportementale de l'objet (i.e. une fonction). La fonctionnalité du logiciel
émerge alors de l'interaction entre les différents objets qui le constituent. L'une
des particularités de cette approche est qu'elle rapproche les données et leurs
traitements associés au sein d'un unique objet.
15
CHAPITRE I : Préalable – IV‐Introduction à l’approche orienté objet

Comme nous venons de le dire, un objet est caractérisé par plusieurs notions :
L'identité
l'objet possède une identité, qui permet de le distinguer des autres objets, indépendamment
de son état. On construit généralement cette identité grâce à un identifiant découlant
naturellement du problème (par exemple un produit pourra être repéré par un code, une
voiture par un numéro de série, etc.) ;
Les attributs
il s'agit des données caractérisant l'objet. Ce sont des variables stockant des informations sur
l'état de l'objet ;
16

Les méthodes
les méthodes d'un objet caractérisent son comportement, c'est‐à‐dire l'ensemble des actions (appelées
opérations) que l'objet est à même de réaliser. Ces opérations permettent de faire réagir l'objet aux
sollicitations extérieures (ou d'agir sur les autres objets). De plus, les opérations sont étroitement liées
aux attributs, car leurs actions peuvent dépendre des valeurs des attributs, ou bien les modifier.
La difficulté de cette modélisation consiste à créer une représentation abstraite, sous forme d'objets,
d'entités ayant une existence matérielle (chien, voiture, ampoule, personne…) ou bien virtuelle (client,
temps…).
La Conception Orientée Objet (COO) est la méthode qui conduit à des architectures logicielles fondées
sur les objets du système, plutôt que sur la fonction qu'il est censé réaliser.
En résumé, l'architecture du système est dictée par la structure du
problème.
17

IV‐2‐Concepts importants de l’approche objet (1/8)
L’objet
Un objet est une entité identifiable du monde réel. Il peut avoir une existence physique (un cheval, un
livre) ou ne pas en avoir (un texte de loi). Identifiable signifie que l’objet peut être désigné.
L’abstraction
L’abstraction est un principe très important en modélisation. Elle consiste à retenir uniquement les
propriétés pertinentes d’un objet pour un problème précis. Les objets utilisés en UML sont des
abstractions d’objets du monde réel.
L’abstraction est une simplification indispensable au processus de modélisation. Un objet UML est donc
une abstraction de l’objet du monde réel par rapport aux besoins du système, dont on ne retient que les
éléments essentiels.
18

Les classes d’objets
Un ensemble d’objets similaires, c’est‐à‐dire possédant la même
structure et le même comportement et constitués des mêmes
attributs et méthodes, forme une classe d’objets. La structure et le
comportement peuvent alors être définis en commun au niveau de la
classe.
Chaque objet d’une classe, encore appelé instance de classe, se
distingue par son identité propre et possède des valeurs spécifiques
pour ses attributs.
19

IV‐2‐Concepts importants de l’approche objet(3/8)
L’encapsulation
L’encapsulation consiste à masquer des attributs et des
méthodes de l’objet vis à vis des autres objets. En effet,
certains attributs et méthodes ont pour seul objectif des
traitements internes à l’objet et ne doivent pas être exposés
aux objets extérieurs. Encapsulés, ils sont appelés les attributs
et méthodes privés de l’objet.
20

La spécialisation et la généralisation
Jusqu’à présent, chaque classe d’objets est introduite séparément
des autres classes. Une classe peut également être définie comme
un sous ensemble d’une autre classe, ce sous ensemble devant
toujours constituer un ensemble d’objets similaires.
Il s’agit alors d’une sous classe d’une autre classe. Elle constitue
ainsi une spécialisation de cette autre classe.
21

L’héritage
L’héritage est la propriété qui fait bénéficier à une sous classe de la structure et du
comportement de sa surclasse.
L’héritage provient du fait qu’une sous classe est un sous ensemble de sa surclasse. Ses
instances sont également instances de sa surclasse. En conséquence, elles bénéficient de la
structure et du comportement définis dans cette surclasse, en plus de la structure et du
comportement introduits au niveau de la sous classe.
L’héritage est une conséquence de la spécialisation. Cependant, les informaticiens emploient
beaucoup plus souvent le terme hérite que spécialise pour désigner la relation entre une sous
classe et sa surclasse.
22

Les classes abstraites et concrètes
Des classes qui possèdent des instances, sont appelées classes concrètes et des
classes qui n’en possèdent pas directement sont appelés classes abstraites.
Une classe abstraite a pour vocation de posséder des sous classes concrètes.
Elle sert à factoriser des attributs et des méthodes communs à ses sous classes.
23

Le polymorphisme
Le polymorphisme signifie qu’une classe (très généralement abstraite)
représente un ensemble constitué d’objets différents car ils sont instances de
sous classes distinctes. Lors de l’appel d’une méthode de même nom, cette
différence se traduit par des comportements différents (sauf dans le cas où la
méthode est commune et héritée de la surclasse dans les sous classes).
24

La composition
Un objet peut être complexe et composé d’autres objets. L’association qui unit alors ces objets est la
composition. Elle se définit au niveau de leurs classes mais les liens sont bâtis entre les instances des
classes. Les objets formant l’objet composé sont appelés composants.
La composition peut prendre deux formes :
la composition faible ou agrégation ;
la composition forte.
Dans la composition faible, les composants peuvent être partagés entre plusieurs objets complexes.
Dans la composition forte, les composants ne peuvent être partagés et la destruction de l’objet
composé entraîne la destruction de ses composants.
25

Conclusion
L’approche par objets forme la base d’UML. Elle est constituée de
concepts (objets, classes, spécialisation, composition) et de principes
(abstraction, encapsulation). Cet ensemble fait de l’approche par
objets un véritable support pour la modélisation de systèmes
complexes, et au‐delà d’UML, pour leur programmation.
Nous verrons dans le chapitre suivants comment les différents
diagrammes d’UML s’appuient sur les concepts et principes de
l’approche par objets.
26

I‐1‐Definition et historique (1/2)
UML signifie « Unified Modeling Language » ou Langage de modélisation
unifié en français. C’est un langage de modélisation qui permet de
représenter graphiquement les besoins des utilisateurs.
c’est la référence actuel fondé sur l’orienté objet.
28
CHAPITRE II : UML – I ‐ Présentation UML

I‐1‐Definition et historique (2/2)
Années 80:
Méthodes pour organiser la programmation fonctionnelle
(Merise), Séparation des données et des traitements
Début des années 90:
Apparition de la programmation objet: nécessite d’une Méthodologie adaptée
Apparition de plus de 50 méthodes entre 1990 et 1995
1994
Consensus sur 3 méthodes pour créer une méthode commune: UML : Unified
Modeling Language (Langage de Modélisation Unifié)
OMT de James Rumbaugh : représentation graphique des aspects statiques,
dynamiques et fonctionnels d’un système
OOD de Grady Booch: concept de package
OOSE de Ivar Jacobson: description des besoins de l’utilisateur
1997: Définition de la norme UML comme standard de modélisation des
systèmes d’information objet par l’OMG (Object Management Group)
29

I‐2‐Domaine d’utilisation
UML est employé dans l’ensemble des secteurs
du développement informatique
Systèmes d’information
Télécommunication, défense
Transport, aéronautique, aérospatial
Domaines scientifiques
Mais pas seulement : on peut modéliser des
comportements mécaniques, humain, etc.
30

I‐ 3‐Pourquoi UML ?
UML permet de :
Cadrer l’analyse objet en offrant différentes vues ou perspectives complémentaires
d’un système ;
Mieux contrôler la complexité dans l’expression des besoins ;
il est un support de communication car il est universel et sa notation graphique
exprime visuellement les solutions objet;
etc.
31

I‐4‐ Briques de base d’UML
Les éléments
Ce sont les abstractions essentielles au modèle
Les relations
Les relations expriment les liens existants entre les différents éléments.
Les diagrammes
Un diagramme est une représentation visuelle de l’ensemble des éléments qui constituent
le système. Ils servent à visualiser un système sous différents angles (utilisateur,
administrateur par ex.)
Dans les systèmes complexes, un diagramme ne fournit qu’une vue partielle du système.
Chaque diagramme va permettre de modéliser ou spécifier une vue (spécificité) du
système à concevoir
L’ensemble des diagrammes réunis permet d’obtenir une vue globale du système à
concevoir.
32

UML est un langage qui permet de représenter des modèles, mais il ne définit pas le processus
d'élaboration des modèles! Cependant, dans le cadre de la modélisation d'une application
informatique, les auteurs d'UML préconisent d'utiliser une démarche :
guidée par les besoins des utilisateurs du système.
centrée sur l'architecture logicielle,
itérative et incrémentale,
D'après les auteurs d'UML, un processus de développement qui possède ces qualités devrait
favoriser la réussite d'un projet.
Il existe plusieurs processus de développement qui répondent aux critères défini plus haut
parmi lesquels on peut citer UP (Unified Process), 2TUP (Two Track Unified Process) , etc.
33
CHAPITRE II : UML – II ‐ comment modéliser avec UML

1‐Piloté par les cas d’utilisation
Le but principal d'un système informatique est de satisfaire les besoins du
client. Le processus de développement sera donc axé sur l'utilisateur.
Les cas d'utilisation permettent d'illustrer ces besoins.
Ils détectent puis décrivent les besoins fonctionnels (du point de vue de
l'utilisateur), et leur ensemble constitue le modèle de cas d'utilisation qui
dicte les fonctionnalités complètes du système.
34
CHAPITRE II : UML – II ‐ comment modéliser avec UML ‐UP‐ P1‐Definition

35
2‐ centrée sur l'architecture logicielle (1/4)
l'architecture est conçue pour satisfaire les besoins exprimés dans les cas d'utilisation,
mais aussi pour prendre en compte les évolutions futures et les contraintes de
réalisation.
La mise en place d'une architecture adaptée est la clé de voûte du succès d'un
développement car elle conditionne le succès d'un développement. Elle décrit des choix
stratégiques qui déterminent en grande partie les qualités du logiciel (adaptabilité,
performances, fiabilité...).Il est important de la stabiliser le plus tôt possible ;

36
2‐ Centrée sur l'architecture logicielle (2/4)
Figure 1: représentation du modèle d’architecture de Philippe Kruchtem.

Vue des cas d’utilisation
ƒ Description du modèle vu par les acteurs du système
ƒ Besoins attendus pour chaque acteur
ƒ Le QUOI et le QUI
la vue des cas d’utilisation qui fait référence aux diagrammes des cas d’utilisation (use
cases diagrams) et des acteurs. On va s’intéresser aux fonctionnalités du système ;
Vue logique
ƒ Définition du système vu de l’intérieur
ƒ COMMENT satisfaire les besoins des acteurs
la vue logique. Elle fait référence aux diagrammes de classes (class diagrams). C’est au
niveau de cette approche que l’on va utiliser la plupart des concepts objets ;
37

Vue d’implémentation ou de réalisation
ƒ Dépendances entre les modules
Vue des processus
ƒ Vue temporelle et technique
ƒ Mise en œuvre des notions de tâches concurrentes, synchronisation…
Vue de déploiement
ƒ Position géographique et architecture physique de chaque élément
ƒ Le OÙ
la vue de déploiement (deployment view). Elle décrit les différentes
ressources matérielles et l’implantation du logiciel dans ces ressources.
38

II‐3‐Itération (1/2)
L'ensemble du problème est décomposé en petites itérations, définies à partir des cas
d'utilisation et de l'étude des risques. Les risques majeurs et les cas d'utilisation les plus
importants sont traités en priorité.
L'itération est une répétition d'une séquence d'instructions ou d'une partie de programme
un nombre de fois fixé à l'avance ou tant qu'une condition définie n'est pas remplie, dans
le but de reprendre un traitement sur des données différentes; Elle qualifie un traitement
ou une procédure qui exécute un groupe d'opérations de façon répétitive jusqu'à ce
qu'une condition bien définie soit remplie.
39

II‐3‐Itération (2/2)
40
Figure 2: les activités d’une itération.

1.Généralités
¾ L'objectif d'un processus unifié est de maîtriser la complexité des
projets informatiques en diminuant les risques.
¾ UP est un ensemble de principes génériques adapté en fonctions
des spécificités des projets. UP répond aux préoccupations
suivantes :
QUI participe au projet ?
QUOI, qu'est‐ce qui est produit durant le projet ?
COMMENT doit‐il être réalisé ?
QUAND est réalisé chaque livrable ?
41
CHAPITRE II : UML – II ‐ comment modéliser avec UML :UP‐ P2. Vie du processus unifié

2.Architecture bidirectionnelle (1/2)
42
UP gère le processus de développement par deux axes:
L'axe vertical représente les principaux enchaînements d'activités, qui regroupent les
activités selon leur nature. Cette dimension rend compte l'aspect statique du processus qui
s'exprime en terme de composants, de processus, d'activités, d'enchaînements, d'artefacts et de
travailleurs.
L'axe horizontal représente le temps et montre le déroulement du cycle de vie du processus;
cette dimension rend compte de l'aspect dynamique du processus qui s'exprime en terme de
cycles, de phases, d'itérations.

2.Architecture bidirectionnelle (2/2)
43 Figure 3: cycle de vie du processus unifié

9 Expression des besoins
9 Analyse
9 Conception
9 Implémentation
9 Test
Confère: Chapitre I : préalable
44
CHAPITRE II : UML – II ‐ comment modéliser avec UML : UP ‐ P3. LES Activités

1.Analyse des besoins
L'analyse des besoins donne une vue du projet sous forme de produit fini.
Cette phase porte essentiellement sur les besoins principaux (du point de
vue de l'utilisateur), l'architecture générale du système, les risques
majeurs, les délais et les coûts.
Elle répond aux questions suivantes :
¾ que va faire le système ? par rapport aux utilisateurs principaux, quels services va‐t‐il
rendre?
¾ quelle va être l'architecture générale (cible) de ce système?
¾ quels vont être : les délais, les coûts, les ressources, les moyens à déployer?
45
CHAPITRE II : UML – II ‐ comment modéliser avec UML : UP‐ P4. LES Phases

2.Elaboration (1/2)
L'élaboration reprend les éléments de la phase d'analyse des besoins et
les précise pour arriver à une spécification détaillée de la solution à
mettre en œuvre.
L'élaboration permet de préciser la plupart des cas d’utilisation, de
concevoir l’architecture du système et surtout de déterminer
l'architecture de référence.
Au terme de cette phase, les chefs de projet doivent être en mesure de
prévoir les activités et d’estimer les ressources nécessaires à l’achèvement
du projet.
46

2.Elaboration (2/2)
Les taches à effectuer dans la phase élaboration sont les suivantes :
¾ créer une architecture de référence,
¾ identifier les risques, ceux qui sont de nature à bouleverser le plan, le coût et le
calendrier,
¾ définir les niveaux de qualité à atteindre,
¾ formuler les cas d'utilisation pour couvrir les besoins fonctionnels et planifier la phase
de construction,
¾ élaborer une offre abordant les questions de calendrier, de personnel et de budget.
47

3.Construction
La construction est le moment où l’on construit le produit. L’architecture
de référence se métamorphose en produit complet.
Le produit contient tous les cas d’utilisation que les chefs de projet, en
accord avec les utilisateurs ont décidé de mettre au point pour cette
version.
48

4.Transition
Le produit est en version bêta. Un groupe d’utilisateurs essaye le produit
et détecte les anomalies et défauts.
Cette phase suppose des activités comme la formation des utilisateurs
clients, la mise en œuvre d’un service d’assistance et la correction des
anomalies constatées.
49

tient compte des changements d’exigence très courants en gestion de
projet ;
permet d’accélérer le rythme de développement grâce à des objectifs
clairs à court terme ;
les éléments sont intégrés progressivement et non pas en fin de cycle ;
permet de limiter les risques de retard par identification des problèmes
dès les premiers stades de développement ;
peut permettre de fournir rapidement un produit avec des fonctionnalités
réduites pour parer un concurrent ;
l’itération favorise la réutilisation du code ;
on peut corriger des erreurs lors des différentes phases d’itération ;
les capacités des développeurs sont utilisées pendant le cycle de vie
entier.
50
CHAPITRE II : UML – II ‐ comment modéliser avec UML : UP‐ P5. Avantages

Les diagrammes UML sont les éléments qui permettent de décrire les différents aspects d’un système. Ces diagrammes
sont au nombre de treize (13) .
Dans les versions antérieures d’UML (ex : UML 1.3) on peut retrouver une description d’UML avec neuf (9) diagrammes.
le diagramme de classe
le diagramme d’objet
les diagrammes de package
les diagrammes de structure composite
les diagrammes de cas d’utilisation
les diagrammes de séquence
51
CHAPITRE II : UML – III – les diagrammes

les diagrammes de communication (collaboration)
le diagramme global d’interaction (overview interaction)
le diagramme de temps (timing diagram)
les diagrammes d’états des classes
les diagrammes d’activités
les diagrammes des composants
les diagrammes de déploiement
52

Ces diagrammes peuvent être classés en groupes selon les aspects qu’ils décrivent.
Tableau2 : récapitulatif des différents diagrammes UML
53
Le modèle statique ou structurel : indique
ce que le système EST
Modèle fonctionnel ou
comportemental : indique ce que le
système FAIT
Modèle d’interactions ou dynamiques :
indique COMMENT le système évolue
Diagrammes de classes Diagramme de cas d’utilisation Diagramme de séquence
Diagramme d’objets Diagramme d’activité Diagramme de communication
Diagramme de composants Diagramme d’état-transitions Diagramme global d’interaction
Diagramme de déploiement Diagramme de temps
Diagramme de paquetages
Diagramme de structures composites

III‐1‐1‐ Présentation du CU
Le diagramme des cas d’utilisation montre l’ensemble des processus du domaine d’étude.
Chaque processus, ou plus précisément, chaque variante de processus, sera modélisée au
moyen d’un diagramme d’états‐transitions et/ou d’un diagramme de séquences et/ou d’un
diagramme d’activités.
III‐1‐2‐Concepts
Acteur
Un acteur définit un ensemble cohérent de rôles qu’un utilisateur ou une entité externe peut
jouer en interagissant avec le système. Un acteur peut consulter et/ou modifier directement
l’état du système en émettant et/ou en recevant des messages susceptibles d’être porteurs de
données.
54
Nom acteur
Acteur physique
Nom acteur
«Actor»
Acteur non physique (Systèmes connexes)
Figure 3: représentation d’un acteur
CHAPITRE II : UML – III – les diagrammes‐ III‐1 –Les diagrammes de CU

Cas d’utilisation (CU)
Un cas d’utilisation est une technique de description du système étudié privilégiant le point de vue de
l’utilisateur. C’est aussi une façon spécifique d’utiliser le système. Il permet une meilleure structuration des
besoins des utilisateurs qui définissent clairement la manière dont ils interagissent avec le système. Il est
composé d’un ensemble d’actions déclenchées par un acteur externe et qui produit un résultat identifiable. Les
cas d’utilisation peuvent être liés par des relations de plusieurs types : include, extend
55
Figure 4: représentation d’un Cas d’utilisation
Interaction: Relation entre un acteur et un CU
Nom acteur
Acteurphysique
Se connecter
Figure 5: représentation d’une interaction entre un acteur et un CU

Relations des Cas d’Utilisation
ƒ Généralisation : Une généralisation de A vers B: A est une spécialisation
de B.
ƒ Include : Une relation d’inclusion d’un « CU2 » vers un « CU1» indique
qu’une instance du « CU2 » contient également le comportement
spécifié par le « CU1 ». Ce comportement est inséré à un endroit défini
par le « CU2 ».
ƒ Extend : La relation d’extension d’un « CU4 » à un « CU3 » indique
qu’une instance du « CU3 » peut être augmentée par le comportement
du « CU4». Le « CU4 » est inséré à l’endroit défini par le point
d’extension par le « CU3 ».
56

Relations des Acteurs
ƒ Généralisation : Une généralisation de A vers B : l’acteur A est une spécialisation de l’acteur B. une instance
de A peut communiquer avec les mêmes C.U. que les instance de B.
ƒ Association (Communication) : Participation d’un acteur à un C.U. La navigation (si elle existe) indique qui de
l’acteur ou du C.U. initie la communication
Figure 6: Formalisme du diagramme
des cas d’utilisation
57

Système ou sujet Cas d’utilisation
Acteur
Figure 7 : exemple de diagramme de cas d’utilisation
58

III‐1‐3‐Documentation des CU
ƒ Nom du CU:
ƒ Acteurs impliqués:
ƒ Description: // brève description du CU
ƒ Pré ‐ conditions: // à vérifier avant le début du CU
ƒ Séquence nominale:
1. …
2. …
ƒ Séquences alternatives:
a. Si… alors
b. Si… alors
ƒ Post‐conditions: // à vérifier après la fin du CU
59

III‐1‐ Diagramme des cas d’utilisation
Exercice 1
On considère le système suivant de gestion d’un DAB (Distributeur automatique
de billets) :
‐ le distributeur délivre de l’argent à tout porteur de carte (carte Visa ou carte de
la banque)
‐ pour les clients de la banque, il permet :
o la consultation du solde du compte
o le dépôt d’argent (chèque ou numéraire)
‐ toute transaction est sécurisée et nécessite par conséquent une authentification
‐ dans le cas où une carte est avalée par le distributeur, un opérateur de
maintenance se charge de la récupérer. C’est la même personne qui collecte
également les dépôts d’argent et qui recharge le distributeur.
Modélisez cette situation par un diagramme de cas d’utilisation
CHAPITRE II : UML – III – les diagrammes‐ III‐1 –Les diagrammes de CU III‐1‐4‐Exercices
60

III‐1‐ Diagramme des cas d’utilisation
Exercice 2 : Réaliser le diagramme de CU
Notre client, est le directeur d’une petite entreprise commerciale. Lors d’une première
discussion avec lui, nous avons pu obtenir les précisions suivantes :
Le client (ou client potentiel) doit pouvoir consulter les produits et éventuellement
procéder à un achat en ligne.
Les commerciaux de la société doivent pouvoir consulter le catalogue des produits en
ligne et enregistrer les achats des clients.
Le service des livraisons doit pouvoir consulter les commandes pour préparer les colis et
les livrer au client.
Le technicien doit pouvoir vérifier d’éventuelles remarques ou messages signalant un
dysfonctionnement lors de l’achat en ligne.
61

III-2-1-Presentation
Le diagramme de séquence montre les interactions entre les objets en mettant l’accent sur l’aspect
temporel (la chronologie des envois de messages).
Il permet de mieux visualiser la séquence des messages pour une lecture du haut vers le bas. L’axe vertical
représente le temps, l’axe horizontal représente les objets qui collaborent.
Une ligne verticale en pointillé est attachée à chaque objet et représente sa ligne de vie.
Concepts
ƒ Objet ;
ƒ Acteur;
ƒ Message.
Un message est un moyen de communication entre objets. Ici, le message caractérise un événement c'est-à-
dire une information envoyée à un objet et provoquant en réponse le déclenchement d’actions associées à
cet objet.
CHAPITRE II : UML – III – les diagrammes‐III‐2‐Diagramme de séquence
62

III-2-2- Messages (1/3)
message simple : message dont on ne spécifie aucune caractéristique d'envoi ou de réception
particulière.
message minuté (timeout) : bloque l'expéditeur pendant un temps donné (qui peut être spécifié dans une
contrainte), en attendant la prise en compte du message par le récepteur. L'expéditeur est libéré si la prise
en compte n'a pas eu lieu pendant le délai spécifié.
message synchrone : bloque l'expéditeur jusqu'à la prise en compte du message par le destinataire. Le
flot de contrôle passe de l'émetteur au récepteur (l'émetteur devient passif et le récepteur actif) à la prise
en compte du message.
63

III-2-2-Messages (2/3)
message asynchrone : n'interrompt pas l'exécution de l'expéditeur. Le message envoyé peut être pris en compte par le
récepteur à tout moment ou ignoré (jamais traiter) ;
ƒ le retour des messages asynchrones devrait toujours être matérialisé, lorsqu'il existe ;
ƒ message dérobant : n'interrompt pas l'exécution de l'expéditeur et ne déclenche une opération chez le récepteur que s'il
s'est préalablement mis en attente de ce message.
Figure: Exemple de diagramme de séquence
64

III-2-2‐Messages (3/3)
Création d'instance
o Création d'un objet qui n'existait pas
o Représentation : flèche qui pointe sur le
sommet d'une ligne de vie
Destruction d'instance
o Destruction d'un objet qui n'existera plus
o N'est pas toujours provoquée par un
message
o Représentation : une croix qui marque la
fin de la ligne de vie de l'objet détruit
65

III-2-3-Objets Actif et Passifs
Objet actif
o Initie et contrôle le flux d'activités
o Représentation : un rectangle à la
place de la ligne de vie verticale
Objet passif
o A besoin d'un flux d'activités pour
pouvoir exécuter une méthode
o À l'exécution d'une méthode, un
rectangle blanc est placé sur la ligne de
vie en pointillés
66

III-2-4-Structures de Contrôle
Structure de contrôle
mess1 envoyé si la condition de garde [entre
crochets] est respectée
Branche
On envoie soit mess2 soit mess3, selon les
conditions
Itération
Le mess4 est envoyé tant que la condition est vraie
4
67

Opérateur « Alternative »
Alternative (ou alt)
¾ Opérateur conditionnel
o Équivalent d’une exécution à choix multiples
(switch)
¾ Peut posséder plusieurs
opérandes, chacune détient
une condition de garde
¾ Absence de condition de garde: condition vraie
¾ Condition else: vraie si aucune autre condition
n’est vraie
4
68

Opérateur «Option »
Option (ou opt)
¾ Représente un comportement qui peut se
produire ou pas.
¾ Équivalent à un alt à une seule branche et
sans else
69

Opérateur «LOOP »
Loop
¾ Équivalent d’une boucle for
¾ Décrit des interactions qui s'exécutent
en boucle
¾ La condition (garde) indique le nombre
de répétitions (min et max) ou une
condition booléenne à respecter
70

Opérateur «Parallèle »
Parallèle (ou par)
¾ A au moins 2 sous fragments
exécutés simultanément
¾ Simule une exécution parallèle
71

Figure : Exemple diagramme de séquence
sd diagramme de séquence

GRH
Système
Nom ou mot de
passe incorrect
Diagramme de séquence : CU Authentification applicative
demande une connexion
affiche la fenêtre de connexion
Saisit infos(nom_utilisateur,mot_de_passe)
identification
Affichage de l'espace de travail du GRH
72

Exercice 1
Le déroulement normal d'utilisation d'un distributeur automatique de billets est le suivant :
• le client introduit sa carte bancaire
• la machine vérifie alors la validité de la carte et demande le code au client
• si le code est correct, elle envoie une demande d'autorisation de prélèvement au
groupement de banques. Ce dernier renvoie le solde autorisé à prélever.
• le distributeur propose alors plusieurs montants à prélever
• le client saisit le montant à retirer
• après contrôle du montant par rapport au solde autorisé, le distributeur demande au
client s'il désire un ticket
• Après la réponse du client, la carte est éjectée et récupérée par le client
• les billets sont alors délivrés (ainsi que le ticket)
• le client récupère enfin les billets et son ticket
Modéliser cette situation à l'aide d'un diagramme de séquence en ne prenant en compte
que le cas où tout se passe bien. NB : on identifiera les scénarios qui peuvent poser
problème en incluant des commentaires dans le diagramme
73

74
Exercice 1 : correction

III-3-1-Présentation
Le diagramme de communication permet de mettre en évidence les interactions entre les
différents objets du système étudié. Dans le cadre de l’analyse, il sera utilisé d’une part pour
préciser le contexte dans lequel chaque objet évolue et d’autre part pour mettre en évidence
les dépendances entre les différents objets impliqués dans l’exécution du processus ou d’un
cas d’utilisation. Un diagramme de communication fait apparaître les interactions entre les
objets et les messages qu’ils s’échangent.
NB: Temps : représenté implicitement par une numérotation des messages
CHAPITRE II : UML – III – les diagrammes ‐III-3-Diagramme de communication
75

III-3-2-Concepts (1/2)
Objet
Un objet est un élément matériel ou immatériel étudié dans la réalité qui satisfait au principe de
distinction (il peut être distingué des autres objets), de permanence (il a une certaine stabilité et son
évolution ne remet pas en cause son identité) et d’activité (il joue un rôle dans le domaine d’activité).
Un objet est donc une entité aux frontières précises qui possède :
- une identité (nom) ;
- un ensemble d’attributs qui caractérise l’état de l’objet ;
- un ensemble d’opérations (méthodes) qui définit son comportement.
Figure : Représentation d’un objet
76

III-3-3-Concepts (2/2)
Message
Les messages sont le seul moyen de communication entre les objets.
Ils sont décrits essentiellement par l’objet émetteur et l’objet récepteur.
Leur description peut être complétée par un nom, une séquence, des
arguments, un résultat attendu, une synchronisation, une condition
d’émission.
Figure : Représentation
d’un message
Figure : Formalisme du
diagramme de collaboration
77

Figure : Exemple d’un diagramme de communication
78

Exercice:
79
Le déroulement normal d'utilisation d'un distributeur automatique de billets est le suivant :
• le client introduit sa carte bancaire
• la machine vérifie alors la validité de la carte et demande le code au client
• si le code est correct, elle envoie une demande d'autorisation de prélèvement au groupement de
banques. Ce dernier renvoie le solde autorisé à prélever.
• le distributeur propose alors plusieurs montants à prélever
• le client saisit le montant à retirer
• après contrôle du montant par rapport au solde autorisé, le distributeur demande au client s'il désire un
ticket
• Après la réponse du client, la carte est éjectée et récupérée par le client
• les billets sont alors délivrés (ainsi que le ticket)
• le client récupère enfin les billets et son ticket
Modéliser cette situation à l'aide d'un diagramme de communication

Le diagramme de classes des entités est un ensemble d’éléments statiques qui montre la
structure d’un modèle (les classes, leur type, leur contenu et leurs relations). Il permet de
représenter l’ensemble des informations formalisées, qui sont gérées dans le domaine. Ces
informations sont structurées c’est‐à‐dire qu’elles sont regroupées dans des classes.
Ainsi, toutes les informations mémorisées, manipulées, transformées, analysées et partagées
pour accomplir les finalités du domaine doivent figurer quelque part dans le diagramme de
classes. Cependant, chaque propriété ne doit figurer qu’une seule fois.
CHAPITRE II : UML ‐ III – les diagrammes – III‐4‐Diagramme de classe
80

III-4-2-Concepts
Classe
Une classe est la description d’une famille d’objets ayant la même structure et le même comportement.
Elle comporte une partie statique (attributs) et une partie dynamique (méthodes ou opérations).
Représentation d’une classe
La notation d’une classe est un rectangle qui comporte trois compartiments.
- 1er compartiment : Nom de la classe et les propriétés générales ;
- 2e compartiment : les attributs ;
- 3e compartiment : les méthodes.
d’une classe
81

III-4-2‐Concepts
Encapsulation
Certains attributs et méthodes ne sont pas exposés à l’extérieur de l’objet. Ils sont encapsulés et appelés attributs et
méthodes privés de l’objet.
L’encapsulation est représentée par un signe plus, un signe moins, un dièse, ou un tilde précédant le nom de l’attribut. Le
tableau suivant détaille la signification de ces signes.
Visibilité Signe Signification
Public + tout élément qui peut voir la classe courante peut également voir
l’élément indiqué
Protected # seul un élément situé dans la classe courante ou un de ses descendants
peut voir l’élément indiqué.
Private ‐ seul un élément situé dans la classe courante peut voir l’élément.
Package ~ seul un élément déclaré dans le même paquetage peut voir l’élément.
82

III-4-2-Concepts
Attribut : C’est une information élémentaire composant une classe. Un attribut
peut permettre d’identifier la classe.
Opération ou méthode : Une opération ou une méthode est une fonctionnalité
assurée par une classe.
Association : Une association est un lien sémantique entre deux classes.
Nom de l'association
min,max
min,max
Figure : Représentation d’une association
83

III-4-2Concepts
Association réflexive : Une association réflexive est une association mettant en
relation une classe avec elle-même ;
Classe association : Une classe association est une association porteuse d’attributs.
Nom de l'association
Classe_Association
Attribut : Type
min,max
min,max
d’une classe association Figure : exemple d’une classe association
84

III-4-2‐Concepts
Association n-aire :Association qui lie plus que deux classes
Peu utilisée, Gestion des multiplicités délicate
85

Cardinalité : La cardinalité est le nombre d’instances d’une classe impliquée dans une association. Elle
est la traduction d’une règle de gestion. Il est possible de spécifier, à une extrémité d’une association, la
cardinalité minimale et la cardinalité maximale pour indiquer un intervalle de valeurs auquel doit
toujours appartenir la cardinalité.
Parfois ces deux sont égaux.
III-4-2-Concepts
Classe_1 Classe_2
q1,q2
p1,p2
Figure : Représentation de la cardinalité
86

La syntaxe de spécification des cardinalités minimales et maximales est décrite dans le tableau ci après.
En l’absence de spécification explicite des cardinalités minimales et maximales, celles‐ci valent 1.
87

III-4-2‐Concepts
Agrégation : C’est un type particulier d’association. Elle met en
évidence une classe agrégat et une classe agrégée. Chaque objet de la
classe agrégée est associé à un ou plusieurs objets de la classe agrégat.
L’agrégation définit une relation « tout ou partie » entre l’agrégat (le
tout) et l’agrégée (la partie).
Classe_agrégat Classe_agrégée
min,max
min,max
Figure : Représentation de l’agrégation
88

III-4-2-Concepts
Composition : C’est une forme d’agrégation qui véhicule des notions de fortes propriétés
et de la vie coïncidente des parties par rapport au tout. Dans une composition, le tout est
responsable de la mise à disposition de ses parties. La suppression d’un objet agrégat
entraîne la suppression des objets agrégés. La valeur maximale de multiplicité du
conteneur ne doit pas excéder 1 puisque les objets, instances de la classe des composants,
doivent tous appartenir au même objet conteneur.
Classe_agrégat Classe_agrégée
min,max
1
Figure : Représentation d’une composition
89

III-4-2-Concepts
Généralisation/Spécialisation
Le principe de généralisation/spécialisation permet d’identifier parmi les objets d’une classe
(générique) des sous-ensembles d’objets (des classes spécialisées) ayant des caractéristiques
spécifiques.
La généralisation est une relation entre un élément général (super-classe ou classe mère) et
un élément dérivé de celui-ci mais plus spécifique désigné par le terme sous-classe ou classe
fille. La généralisation est qualifiée de relation est une sorte de.
La spécialisation d’une classe permet de mettre en facteur commun certaines descriptions,
soit préciser de nouvelles contraintes sur le modèle de classes.
Polymorphisme : C’est la possibilité pour un même message de déclencher des
traitements différents, suivant les objets spécialisés auxquels il est adressé.
90

III-4-2‐Concepts
Classe Générique
Attributscommuns
Methodescommunes()
Classe Spécialisé
AttributsSpécifiques
MéthodesSpécifiques()
G
é
n
é
r
a
l
i
s
a
t
i
o
n
S
p
é
c
i
a
l
i
s
a
t
i
o
n
Figure : Représentation de la généralisation/spécialisation
91

III-4-Concepts
Nom association
Nom association
Nom association
Nom association
Classe Générique
Attributs Communs : int
Méthodes Communes ()
Classe Spécialisée
Attributs Spécifiques : real
Méthodes Spécifiques ()
Classe agrégat
Classe agrégée
Classe association
Attribut : string
Classe
min1..max1 min2..max2
min3..max3 min4..max4
1
Figure : Formalisme du diagramme de classes
92

III-4-2-Concepts
Figure : formalisme des notes
Les Notes (Commentaires)
Lors des phases de modélisation et de spécification, il est nécessaire de
documenter ses modèles :
ƒ Contraintes matérielles
ƒ Contraintes de performance
ƒ Choix techniques réalisés
ƒ Références à d’autres docs
ƒ Explications techniques, etc.
En UML, on utilise les Notes
93

Exemples
Figure : Exemple de diagrammes de classes
Soient les phrases suivantes :
∙ Un répertoire contient des fichiers
∙ Les modems et claviers sont des périphériques d’entrée
/ sortie
∙ Une transaction boursière est un achat ou une vente
∙ Un compte bancaire peut appartenir à une personne
physique ou morale
Elaborez les diagrammes de classe correspondants en
choisissant le type de relation
Approprié
94

Exercice
95
Gestion de bus de ramassage scolaire
Dans une société de transport, on voudrait gérer les bus de ramassage scolaire
et les conducteurs. Un lycéen est un enfant, il est caractérisé par son nom, son
âge et son sexe. Les informations qui caractérisent le conducteur sont les
mêmes que pour le lycéen, avec en plus le numéro de son permis. Quant au
bus, on a besoin de connaître son numéro d’immatriculation, sa date de mise
en service, nombre d’années de service, et le poids total.
Un bus est composé d’une carrosserie (poids, couleur), de 6 roues (pression,
diamètre), de plusieurs sièges (couleur) pour passagers, plusieurs vitres
(épaisseur, poids).
Présentez le diagramme de classes adéquat.

Exercice : correction
96

Un diagramme d'objets UML représente une instance spécifique d'un diagramme de classes à un moment
précis. Un diagramme d'objets se concentre sur les attributs d'un ensemble d'objets et sur la façon dont ils
interagissent les uns avec les autres.
Vous pouvez créer un diagramme d'objets pour un arbre généalogique, l'organisation d'une entreprise ou
tout autre système comprenant des éléments interconnectés.
Peut être utilisé pour:
o illustrer le modèle de classes en montrant un exemple qui explique le modèle,
o préciser certains aspects du système en mettant en évidence des détails imperceptibles dans le
diagramme de classes,
o exprimer une exception en modélisant des cas particuliers ou des connaissances non généralisables qui
ne sont pas modélisés dans un diagramme de classe
Le diagramme de classes modélise les règles et le diagramme d’objets modélise des faits.
CHAPITRE II : UML – III – les diagrammes‐III‐5‐Les diagrammes Objets
97

Les diagrammes d'objets sont simples à créer : ils sont composés d'objets, représentés
par des rectangles, et reliés entre eux par des lignes.
Graphiquement
Un objet est représenté comme une classe, mais le compartiment des méthodes
n’est pas indiqué
Le nom de l’objet est composé du nom de l’instance, suivi de celui de la classe, et est
souligné
Les attributs reçoivent des valeurs
o Si certaines valeurs ne sont pas renseignées, l’objet est partiellement défini
La relation de généralisation n’est jamais représentée
Les multiplicités ne sont pas représentées
On peut représenter la dépendance d’instanciation
o Stéréotype « instance of »
98

Exemple1 : Le diagramme d'objets d'entreprise ci‐dessous montre la façon dont les services sont liés,
dans le style d'un organigramme classique.
99

Exemple 2
10
0

Exercice 1
Une bibliothèque compte les exemplaires des titres suivants parmi les livres dont elle
dispose :
« Histoire de la 2ème guerre mondiale », « Les Aventures de Robin Hood », et deux
exemplaires de « Harry Potter».
Felix et Alain sont des utilisateurs abonnés. Alain a emprunté «Les Aventures de Robin
Hood» tandis que Felix a emprunté deux livres: « Histoire de la 2ème guerre mondiale
» et un exemplaire de « Harry Potter ».
Représenter le diagramme de classes et le diagramme d’objets modélisant ce cas de
figure.
101

Correction
102

Le diagramme d’activités permet de représenter la dynamique du système d’information. Il est considéré
comme une variante du diagramme d’états-transitions où les états sont des activités. Le diagramme d’activités
est attaché à une classe (processus, acteur ou entité), à un cas d’utilisation ou à une opération. C’est un
graphe orienté qui décrit un enchaînement de traitements. Le déroulement ainsi présenté est appelé flot de
contrôle. On peut aussi faire figurer des objets impliqués dans les activités : la participation de ces objets à des
traitements représente un flot d’objet.
L’enchaînement des activités peut être soumis à des branchements ou à des synchronisations.
La visualisation de couloirs d’activités permet de représenter la répartition de la responsabilité des activités
entre les différents acteurs.
CHAPITRE II : UML – III – les diagrammes‐III‐6‐Diagramme d’activité
103

III-6-2-Concepts
Activité ou état action : Une activité représente une exécution d’un
mécanisme, un déroulement d’étapes séquentielles. C’est une opération ayant
une certaine durée utilisée pour décrire le comportement d’une classe.
Transition : Une transition matérialise le passage d’une activité vers une
autre. Les transitions sont déclenchées par la fin d’une activité et provoquent
le début d’une autre (elles sont automatiques).
104

Figure : Notation : activité, transition
Un événement, c’est quelque chose qui a une signification pour le domaine et pouvant se produire
suffisamment fréquemment pour que l’on puisse définir a priori le comportement à adopter. L’événement
peut être interne (il provient de l’intérieur du domaine), externe (il provient de l’extérieur du domaine)
ou temporel (expiration d’un délai ou avènement d’une date).
Une condition de garde est une condition devant être vérifiée pour permettre la transition. Elle est
optionnelle.
Une action est une opération atomique (non interruptible) déclenchée par une transition. Elle est
optionnelle.
III-6-2-Concepts
105

III-6-2-Concepts
Synchronisation : Une barre de synchronisation permet d’ouvrir et de fermer des branches parallèles au sein d’un
flot d’exécution. Les transitions qui partent d’une barre de synchronisation ont lieu en même temps. On ne franchit
une barre de synchronisation qu’après réalisation de toutes les transitions qui s’y rattachent.
Figure : Représentation de la synchronisation
106

III-6-2-Concepts
Branchement conditionnel ou décision : Un flot de contrôle (représentation du déroulement d’un
ensemble d’activités) peut comprendre des chemins alternatifs. Chaque branche est soumise à une
condition, qui est une condition de garde comme le montre la figure suivante.
Figure : Représentation d’un branchement conditionnel
107

III-6-2-Concepts
Couloirs d’activité ou partition : Afin de décrire les acteurs responsables de chaque activité, on va dessiner une
colonne (un couloir) pour représenter chaque acteur jouant un rôle. Chaque activité sera placée dans le couloir
correspondant à l’acteur qui en est chargé.
Figure : Formalisme du diagramme d’activité
108

Exercice: : Réalisez le diagramme d’activité d’un CU (Authentification). Ce CU permet aux utilisateurs de se connecter au système en
s’authentifiant au système.
ad Authentification

Initial
Final
Page d'authentification
Vérification des informations
de connexion
Fermeture de la page de login Ouv erture de la page
principale
Saisie du login et du mot de passe
Annulation
Système
Utilisateur
[SINON]
[Bésoin de connexion]
[NON OK]
[OK]
Correction: diagramme d’activité CU Authentification
109

Elément spécifiant ses interactions avec l'extérieur via la définition de ses interfaces fournies et requises
o On connecte une interface requise d'un composant à l'interface fournie compatible d'un autre composant :
assemblage
Composant composite
o Composant peut être formé de composants internes assemblés par leurs interfaces
o Composition hiérarchique de composants
Port
o Point d'interaction du composant
o Associé à une interface d'opérations (en mode requis ou fourni)
Connecteur
o De délégation : lie un port du composite à un port d'un de ses éléments
o D'assemblage : lie une interface d'un élément interne avec celle d'un autre élément interne
Ensemble de composants connectés entre eux par assemblage ou composition
Diagramme de composants
CHAPITRE II : UML – III – les diagrammes‐III‐7‐Les autres diagrammes UML
110

Diagramme de structure composite
Diagramme conceptuellement assez proche d'un diagramme de composants
o Définit l'architecture interne d'une classe
• Les éléments qui la forment (les parts)
• Les interactions entre ces éléments (d'une manière proche des diagrammes de
collaboration)
Diagramme d'états des classes
o Diagrammes d'états : comportement interne d'un objet
o Utilisés pour modéliser l’état des données et leurs changements durant le cycle de vie des
objets instances des classes du diagramme de classe .
111

une variante du diagramme d’activité qui donne une vue globale d’un flot
de contrôle ;
Diagramme globale d'interaction
o Evolution de l'état du système selon un point de vue principalement
temporel.
o Utilisé pour explorer le comportement d’un ou plusieurs objets pendant
une période de temps donnée .
Diagramme de temps
112

Diagramme de paquetages
o organiser les éléments de modélisation en groupe avec pour objectif de rendre les diagrammes plus simples et plus
faciles à comprendre ;
o Disposer d'heuristiques pour regrouper les classes
• Heuristique la plus utilisée : la dépendance entre les classes
• Une dépendance existe entre 2 éléments si le changement de définition d'un élément peut modifier un changement
dans l'autre élément
• Dépendances entre classes
‰ Envoi d'un message (appel de méthode)
‰ Une classe fait partie des données d'une autre classe
‰ Une classe mentionne une autre classe comme un paramètre d'une opération
• Idéalement, seules les modifications de l'interface de la classe affectent les autres classes
Exemple de diagramme de paquetages
113

Diagramme de déploiement
Exemple de diagramme déploiement
o Relation entre le logiciel et le matériel
o Placement des composants et objets dans le système réparti
• Noeud = unité informatique (périphérique, capteur, mainframe,PC,...)
• Connexion
• Composant = module physique de code
114

ArgoUML
StartUML
UMLDesigner
Enterprise Architect
PowerAMC
115

116
Avantages d'UML
Un certain consensus autour de l'utilisation d'UML : standard de fait dans l'industrie
Notation avec une syntaxe très riche, tout en restant intuitive
Intégration dans des ateliers de génie logiciel avec production de squelettes de codes
et autres transformations automatiques des modèles
Langage de contraintes OCL pour spécifications précises à utiliser en complément
Inconvénients d'UML
Notation majoritairement graphique pouvant se révéler insuffisante ou trop chargée
d'un point de vue expressivité
Sémantique floue ou mal définie pour certains types de diagrammes
Lien parfois difficile entre les vues et diagrammes d'une même application

117
http://igm.univ‐mlv.fr
https://sites.google.com/site/liliasfaxi/supports/uml
https://www.lucidchart.com/
http://laurent‐audibert.developpez.com/Cours‐UML
http://ecariou.perso.univ‐pau.fr/cours/spec/cours‐UML.pdf
liris.cnrs.fr/csolnon/coursUML.pdf
http://uml.free.fr/
evesogli@yahoo.fr

COURS UML INFORMATQIUE TELECOM2 2007.pdf

Recommandé

Recommandé

Contenu connexe

Similaire à COURS UML INFORMATQIUE TELECOM2 2007.pdf

Similaire à COURS UML INFORMATQIUE TELECOM2 2007.pdf (20)

COURS UML INFORMATQIUE TELECOM2 2007.pdf