La conception de logiciels avec UML utilise des modèles pour résoudre des problèmes à travers divers diagrammes, répartis selon trois axes : fonctionnel, structurel et dynamique. Les diagrammes incluent les cas d'utilisation, les diagrammes de classes et d'états, chacun représentant différentes interactions et structures au sein du système. Les relations entre cas d'utilisation, telles que 'include' et 'extend', ainsi que les concepts d'agrégation et de composition, sont également détaillés pour décrire les interactions et la hiérarchie des éléments du système.

1. La conception du logiciel
avec UML

3. La modélisation est une technique qui permet de comprendre
un système par l’établissement de modèles
pour mettre au point une solution à un problème.
Qu’est-ce que la modélisation ?

4. UML représente un système, en se basant sur plusieurs diagrammes
parmi lesquels on cite :
Quatre pour la structure statique
 Diagramme d’objets
 Diagramme de classes
 Diagramme de composant
 Diagramme de déploiement
Cinq pour le comportement dynamique
 Diagramme de cas d’utilisation
 Diagramme de séquences
 Diagramme d’activité
 Diagramme de collaboration
 Diagramme d’états transitions
Les types de diagramme

5. Les concepteurs orientent leurs modélisations selon trois axes
sur lesquels ils répartissent les diagrammes :
L’axe fonctionnel qui est utilisé pour décrire le ce que
fait le système à réaliser,
L’axe structurel et statique qui est relatif à sa structure,
L’axe dynamique qui est relatif à la construction de ses
fonctionnalités.
Les axes de la modélisation

6. Fonctionnel
Dynamique
Statique
Diagramme de Use Cases
Diagramme d’activités
Diagramme de séquences
Diagramme de classes
Diagramme de composants
Diagramme de déploiement
Diagramme d’objets
Diagramme d’activités
Diagramme d’états/transitions
Diagramme de séquences
(Diagramme de collaboration)
Les 3 axes de la modélisation

13. Un acteur représente un rôle joué par une entité externe (utilisateur humain,
dispositif matériel ou autre système) qui interagit directement avec le système
étudié.
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.
Comment les représenter ?

14. Comment les représenter ?
 Le diagramme de cas d’utilisation est un schéma qui montre les cas
d’utilisation (ovales) reliés par des associations (lignes) à leurs acteurs (icône du
« stick man », ou représentation graphique équivalente). Chaque association
signifie simplement « participe à ». Un cas d’utilisation doit être relié à au
moins un acteur.
 La fiche de description textuelle d’un cas d’utilisation n’est pas normalisée
par UML.
Les cas d’utilisation (Use Case)
Un cas d’utilisation (« use case ») représente un ensemble de séquences
d’actions qui sont réalisées par le système et qui produisent un résultat
observable intéressant pour un acteur particulier.

18. Exemple d’un diagramme des cas d’utilisation

22. La relation de type « include »
Une relation « include » est utilisée pour indiquer que le cas
d’utilisation source (départ de la flèche) contient TOUJOURS
le cas d’utilisation inclus. Pour représenter cette relation, on
dessine donc une flèche en pointillé partant du cas
d’utilisation principal vers le cas d’utilisation interne. Puis,
on indique le stéréotype « include » sur la flèche. Dans une
relation « include », le cas d’utilisation source est donc celui
qui a besoin d’un autre cas d’utilisation dit interne, indiqué
par une flèche.
La relation « extend »
Une relation « extend » est la deuxième forme de relation
stéréotypée. Cette relation est utilisée pour indiquer que le cas
d’utilisation source (à l’origine de la flèche) n’est pas toujours
nécessaire au cas d’utilisation principal, mais qu’il peut l’être dans
certaines situations.

24. Exemple : diagramme de cas d’utilisation d’une médiathèque

25. PRINCIPES ET DÉFINITIONS DE BASE :
Le diagramme de classes est le point central dans un développement
orienté objet. En analyse, il a pour objectif de décrire la structure des
entités manipulées par les utilisateurs. En conception, le diagramme
de classes représente la structure d’un code orienté objet ou, à un
niveau de détail plus important, les modules du langage de
développement.
DIAGRAMME DE CLASSES

33. Associations particulières :
RELATION D’AGRÉGATION :
Une agrégation est une forme particulière d’association. Elle
représente la relation d’inclusion structurelle ou comportementale
d’un élément dans un ensemble. Contrairement à l’association,
l’agrégation est une relation transitive.
Exemple :
Une école dispose d’au moins une salle de cours. Dans chaque
salle, on trouve des chaises et un vidéo - projecteur fixé au
plafond.

34. RELATION DE COMPOSITION :
La composition, appelée également « agrégation composite », est une agrégation
particulière.
Cela signifie que toute composition peut être remplacée par une agrégation, qui elle-
même peut être remplacée par une association.
La relation de composition décrit une contenance structurelle entre instances.
La destruction ou la copie de l’objet composite implique respectivement la
destruction ou la copie de ses composants.
Exemple :

35. Exemple de relation d’agrégation :
Exemple de relation de composition :

37. Les diagrammes dynamiques
Les différents diagrammes dynamiques sont :
 Diagrammes d’états
 Diagrammes d’interactions
 Diagrammes de séquences
 Diagrammes de collaboration
 Diagrammes d’activité

44. Exemple : Retrait en espèce
1. Le guichetier ouvre une session
2. Le guichetier saisit le numéro de compte du client.
3. Le système guichet valide le compte auprès du système
central.
4. Le système guichet demande le type d’opération au
guichetier
5. Le guichetier sélectionne le montant du retrait
6. Le système guichet interroge le système central pour
s’assurer que le compte est suffisamment approvisionné
7. Le système guichet demande au système central de débiter
le compte
8. Le système notifie au guichetier qu’il peut délivrer le
montant demandé

45. 45

46. Exemple :

47. Diagramme de séquence « UC Authentification" :
Fragment de séquence « ALT »

48. Fragment de séquence « Ref »

49. Le cadre ref fait référence à un autre diagramme de séquence suivant :

50. Exemple :

54. ( Collaborations )
Le diagramme de collaboration (appelé également diagramme de
communication) permet de mettre en évidence les échanges de
messages entre objets. Cela nous aide à voir clair dans les actions
qui sont nécessaires pour produire ces échanges de messages. Et
donc de compléter, si besoin, les diagrammes de séquence et de
classes.
Objectifs :
- Faire apparaitre les classes, spécifier l’usage des instances.
- Montrer les interactions entre objets par leurs liens et les
messages échangés.

55. Exemple :

56. :Le secretaire :Interface Gestion des élèves :C_Gestion des élèves
:eleve
1:Inscription demandée demandé
4: données saisies etenregestrementdemandé 2:inscription demandée
5: Données saisies etenregistrementdemané()
3: Afficher(formulaire de saisie)
7: Afficher ("Inscription effectuée")
6:créer_élève(données saisies)

57. 57

58. ( Diagramme d’états-transitions )
Objectifs :
- Représentation du cycle de vie des instances d’une classe.
- Spécification des états, des transitions entre ces états et des
actions associées aux transitions.

62. Exemple :

63. Exemple :

64. Diagramme d’états 1 « Traiter le passage en caisse »

65. Diagramme d’états 2 « Traiter le passage en caisse »

66. Le diagramme d’activité :
Variante des diagrammes d’états-transitions : ce diagramme
met l’accent sur les activités, leurs relations et leurs impacts
sur les objets

67. L’alternative :
Elle permet d’indiquer les différents scénarios du cas
d’utilisation dans un même diagramme.
Dans l’exemple, il s’agit de la condition d’après laquelle le
cas d’utilisation « Inscription comme client » serait appelé.

70. Exemple 1 :

71. Exemple 2 :

72. Exemple 2 :