IAP – S3

MI – S3
2025 - 2026

Pr. SOUKAINA MJAHED

[email protected]

PR. SOUKAINA MJAHED 1

UML – Introduction

❑ UML (Unified Modeling Language) est un langage graphique standardisé pour modéliser,
visualiser, spécifier et documenter des systèmes logiciels (et parfois non-logiciels). Il
facilite la communication entre développeurs, analystes, architectes et parties prenantes.

❑ Objectifs :

• Clarifier les idées avant d’implémenter.

• Communiquer la structure et le comportement du système.
• Servir de documentation vivante et d’artefact pour la conception.
• Aider à la conception orientée objet et à l’ingénierie des exigences.

❑ UML focalise sur l'approche orientée objet des applications et données.

PR. SOUKAINA MJAHED 2

 UML – Notions de base
❑ Modèle :
• Représentation abstraite de la réalité
qui exclut certains détails du monde
réel.
• Permet de réduire la complexité d'un
phénomène en éliminant les détails qui
n’influencent pas son comportement
de manière significative.
• Il reflète ce que le concepteur croit
important pour la compréhension et la
prédiction du phénomène modélisé, les
limites du phénomène modélisé
dépendent des objectifs du modèle.

PR. SOUKAINA MJAHED 3

 UML – Notions de base
❑ Maître d'ouvrage (MOA) : personne morale (entreprise, direction, etc.) entité de l'organisation. Ce
n'est jamais une personne.
❑ Maître d'œuvre (MOE) : personne morale (entreprise, direction, etc.) garante de la bonne réalisation
technique des solutions. Il a, lors de la conception du SI, un devoir de conseil vis-à-vis du MOA, car le SI
doit tirer le meilleur parti des possibilités techniques.
❑ Le MOA est client du MOE à qui il passe commande d'un produit nécessaire à son activité.
❑ Le MOE fournit ce produit. Soit il le réalise lui-même, soit il passe commande à un ou plusieurs
fournisseurs (« entreprises ») qui élaborent le produit sous sa direction.
❑ La relation MOA et MOE est définie par un contrat qui précise leurs engagements mutuels.
❑ Le MOE contrôle la qualité technique du produit en assurant le respect des délais fixés par le MOA et
en minimisant les risques.
❑ Le MOE est responsable de la qualité technique de la solution. Il doit, avant toute livraison au MOA,
procéder aux vérifications nécessaires (« recette de tests »).

PR. SOUKAINA MJAHED 4

 UML – Notions de base
❑ Logiciel :
• Ensemble de programmes, qui permet à un ordinateur ou à un système informatique
d'assurer une tâche ou une fonction en particulier.
• Les logiciels, suivant leur taille, peuvent être développés par une personne seule, une
petite équipe, ou un ensemble d'équipes coordonnées.
• Des études ont été faites sur les causes de succès et d'échec des projets : la plupart des
échecs proviennent non de l'informatique, mais de la maîtrise d'ouvrage (i.e. le client).
• Pour ces raisons, le développement de logiciels dans un contexte professionnel suit
souvent des règles strictes encadrant la conception et permettant le travail en groupe et
la maintenance du code.
• Ainsi, une nouvelle discipline est née : le génie logiciel.

PR. SOUKAINA MJAHED 5

 UML – Notions de base
❑ Génie logiciel :
• Domaine de recherche qui a pour objectif de répondre à un problème qui s'énonçait en
deux constatations : Fiabilité du logiciel, Délais (et donc coûts) prévus des logiciels
satisfaisant le cahier des charges.
• La maintenance est devenue une facette très importante du cycle de vie d'un logiciel.
• Une enquête effectuée auprès de 55 entreprises révèle que 53% du budget total d'un
logiciel est affecté à la maintenance. Ce coût est réparti comme suit :
• 34% maintenance évolutive (modification des spécifications initiales) ;
• 10% maintenance adaptative (nouvel environnement, nouveaux utilisateurs) ;
• 17% maintenance corrective (correction des bugs) ;
• 16% maintenance perfective (améliorer les performances sans changer les spécifications) ;
• 6% assistance aux utilisateurs ;
• 6% contrôle qualité ;
• 7% organisation/suivi ;
• 4% divers.

PR. SOUKAINA MJAHED 6

 UML – Notions de base
❑ Génie logiciel :
• Pour apporter une réponse à tous ces problèmes, le génie logiciel s'intéresse
particulièrement à la manière dont le code source d'un logiciel est spécifié puis produit.
• Ainsi, le génie logiciel touche au cycle de vie des logiciels :
• l'analyse du besoin,
• l'élaboration des spécifications,
• la conceptualisation,
• le développement,
• la phase de test,
• la maintenance.

PR. SOUKAINA MJAHED 7

 UML – Notions de base
❑ Qualité du logiciel :
• Divers travaux ont mené à la définition de la qualité du logiciel en termes de facteurs, qui
dépendent, entre autres, du domaine de l'application et des outils utilisés.
• Validité : aptitude d'un produit logiciel à remplir exactement ses fonctions, définies par le cahier
des charges et les spécifications.
• Fiabilité ou robustesse : aptitude d'un produit logiciel à fonctionner dans des conditions
anormales.
• Extensibilité (maintenance) : facilité avec laquelle un logiciel se prête à sa maintenance, c'est-à-
dire à une modification ou à une extension des fonctions qui lui sont demandées.
• Réutilisabilité : aptitude d'un logiciel à être réutilisé, en tout ou en partie, dans de nouvelles
applications.
• Compatibilité : facilité avec laquelle un logiciel peut être combiné avec d'autres logiciels.

PR. SOUKAINA MJAHED 8

 UML – Notions de base
❑ Qualité du logiciel :
• Divers travaux ont mené à la définition de la qualité du logiciel en termes de facteurs, qui
dépendent, entre autres, du domaine de l'application et des outils utilisés.
• Efficacité : Utilisation optimale des ressources matérielles.
• Portabilité : facilité avec laquelle un logiciel peut être transféré sous différents environnements
matériels et logiciels.
• Vérifiabilité : facilité de préparation des procédures de test.
• Intégrité : aptitude d'un logiciel à protéger son code et ses données contre des accès non
autorisés.
• Facilité d'emploi : facilité d'apprentissage, d'utilisation, de préparation des données,
d'interprétation des erreurs et de rattrapage en cas d'erreur d'utilisation.

• Ces facteurs sont parfois contradictoires, le choix des compromis doit s'effectuer en
fonction du contexte.
PR. SOUKAINA MJAHED 9
 UML – Notions de base
❑ Approche orientée objet :
• 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, 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.

PR. SOUKAINA MJAHED 10

 UML – Notions de base
❑ Approche orientée objet :
• Un objet est caractérisé par plusieurs notions :
• L'identité : qui permet de le distinguer des autres objets.
• Les attributs : données caractérisant l'objet. Ce sont des variables stockant des informations sur
l'objet.
• Les méthodes : méthodes d'un objet caractérisant 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.
• Représentation abstraite, sous forme d'objets, d'entités ayant une existence matérielle ou bien virtuelle.
• 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.

PR. SOUKAINA MJAHED 11

 UML – Notions de base
❑ Approche fonctionnelle VS Approche orientée objet :
• Tout ce que l'on fait avec un langage de programmation par objets pourrait être fait en
programmation impérative. La différence entre une approche fonctionnelle et une
approche objet n'est donc pas d'ordre logique, mais pratique.
• L'approche objet est une approche orientée donnée. Dans cette approche, les fonctions
se déduisent d'un regroupement de champs de données formant une entité cohérente,
logique, tangible et surtout stable quant au problème traité.
• L'approche structurée classique privilégie une organisation des données postérieure à la
découverte des grandes, puis petites fonctions qui les décomposent, l'ensemble
constituant les services qui répondent aux besoins.

PR. SOUKAINA MJAHED 12

 UML – Définitions
❑ Langage graphique qui permet de
représenter et de communiquer les
divers aspects d'un système
d'information. Aux graphiques sont
bien sûr associés des textes qui
expliquent leur contenu.
❑ Permet de de donner sur un système
une idée utilisable en pratique sans
risque d'erreur grave.
❑ UML 2.0 comporte plusieurs types de
diagrammes représentant des
concepts particuliers du système
d'information. Ils se répartissent en
deux grands groupes.

PR. SOUKAINA MJAHED 13

UML – Définitions

PR. SOUKAINA MJAHED 14

 UML – Diagramme des cas d’utilisation
❑ Permet de représenter les fonctions d’un système du point de vue de l’utilisateur (appelé
« acteur » en UML).
❑ Cet acteur ne doit pas nécessairement être un utilisateur humain. Le rôle peut également
être attribué à un système externe qui accède à un autre système.
❑ Le diagramme de cas d’utilisation montre en fait la relation entre un acteur et ses
demandes ou attentes vis-à-vis du système, sans décrire les actions en cours ni les mettre
dans un ordre logique.
❑ Permet de visualiser facilement et clairement quels cas d’utilisation doivent être pris en
compte dans la conception pour que les acteurs (et au sens large également l’opérateur ou
le client) atteignent les objectifs escomptés – sans tenir compte dans un premier temps de
la faisabilité technique.

PR. SOUKAINA MJAHED 15

UML – Diagramme des cas d’utilisation
❑ Acteur :
❑ Les acteurs principaux : vont réaliser le cas d'utilisation.
❑ Les acteurs secondaires : font que recevoir
des informations a l'issue de la réalisation d'un cas d'utilisation.
❑ Il ne peut y avoir qu’un seul acteur principal par cas d’utilisation.
❑ Les stéréotypes « primary » ou « secondary » indique si l’acteur est principal ou secondaire
pour un cas d’utilisation.

PR. SOUKAINA MJAHED 16

 UML – Diagramme des cas d’utilisation

❑ Système : le système auquel se rapporte le cas d’utilisation est représenté par un rectangle.
❑ Cas d’utilisation : le cas d’utilisation lui-même est représenté par une ellipse, dans laquelle il
y a généralement une courte phrase décrivant le processus et commençant par un verbe.

PR. SOUKAINA MJAHED 17

 UML – Diagramme des cas d’utilisation
❑ Association : ligne continue entre un acteur et un cas
d’utilisation qui indique clairement que l’acteur et le
cas d’utilisation décrits dans l’ellipse sont liés.

❑ Association d’inclusion (include) : le cas d’utilisation

d’où part la ligne de connexion en pointillés inclut un
deuxième cas d’utilisation, pointé par la pointe de
flèche.

❑ Association d’extension (extend) : le cas d’utilisation

d’où part la ligne de connexion en pointillés commence
peut, sous certaines conditions, étendre le cas
d’utilisation pointé par la tête de flèche. Mais ce n’est
pas toujours le cas.

PR. SOUKAINA MJAHED 18

 UML – Diagramme des cas d’utilisation
❑ Point d’extension (extend) : La prise en compte du deuxième cas d’utilisation, dans
l’association d’extension, dépend de certaines conditions.

PR. SOUKAINA MJAHED 19

 UML – Diagramme des cas d’utilisation
❑ Point d’extension (extend) : La prise en compte du deuxième cas d’utilisation, dans
l’association d’extension, dépend de certaines conditions.

PR. SOUKAINA MJAHED 20

 UML – Diagramme des cas d’utilisation
❑ Généralisation : utilisé entre acteurs mais aussi entre cas d’utilisation.

Acteur 1

Acteur 2

PR. SOUKAINA MJAHED 21

 UML – Diagramme des cas d’utilisation
❑ Exercice d’application
Une bibliothèque municipale souhaite informatiser la gestion de l’emprunt de livres.
Un usager peut :
• Consulter le catalogue en ligne.
• S’inscrire comme membre.
• Emprunter un livre s’il est membre et que le livre est disponible.
• Retourner un livre.
Un bibliothécaire peut :
• Enregistrer l’inscription d’un nouvel usager.
• Enregistrer les emprunts et les retours de livres.
• Mettre à jour le catalogue (ajouter/supprimer des livres).

1. Identifier les acteurs principaux et secondaires.

2. Lister les cas d’utilisation (use cases) à partir des actions décrites.
3. Dessiner le diagramme de cas d’utilisation UML en montrant :
❖ Les acteurs (avec les bonhommes)
❖ Les cas d’utilisation (ovales)
❖ Les relations (lignes d’association, éventuels liens « include » ou « extend » si nécessaire).

PR. SOUKAINA MJAHED 22

UML – Description textuelle des cas d'utilisation

❑ Le diagramme de cas d'utilisation décrit les grandes fonctions d'un système

du point de vue des acteurs => N'expose pas de façon détaillée le dialogue
entre les acteurs et les cas d'utilisation.
❑ Bien que de nombreux diagrammes d'UML permettent de décrire un cas, il
est recommandé de rédiger une description textuelle, car c'est une forme
souple qui convient dans bien des situations.
❑ Une description textuelle couramment utilisée se compose de trois parties.

PR. SOUKAINA MJAHED 23

UML – Description textuelle des cas d'utilisation
❑ Partie 1 : Identification
❑ Permet d'identifier le cas.
❑ Doit contenir les informations suivantes :
• Nom : utiliser une tournure à l'infinitif (ex. : Réceptionner un colis).
• Objectif : une description résumée permettant de comprendre l'intention
principale du cas d'utilisation.
• Acteurs principaux : ceux qui vont réaliser le cas d'utilisation.
• Acteurs secondaires : ceux qui ne font que recevoir des informations à l'issue
de la réalisation du cas d'utilisation.
• Dates : les dates de création et de mise à jour de la description courante.
• Responsable : le nom des responsables.
• Version : le numéro de version.

PR. SOUKAINA MJAHED 24

UML – Description textuelle des cas d'utilisation

❑ Partie 2 : Description des scénarios

❑ Description du fonctionnement du cas sous la forme d'une séquence de
messages échangés entre les acteurs et le système.
❑ Contient toujours une séquence nominale qui décrit de déroulement normal du
cas.
❑ À la séquence nominale s'ajoutent fréquemment des séquences alternatives (des
embranchements dans la séquence nominale) et des séquences d'exceptions
(qui interviennent quand une erreur se produit).

PR. SOUKAINA MJAHED 25

UML – Description textuelle des cas d'utilisation
❑ Partie 2 : Description des scénarios
• Les préconditions : elles décrivent dans quel état doit être le système
avant que ce cas d'utilisation puisse être déclenché.
• Des scénarios : ces scénarios sont décrits sous la forme d'échanges
d'événements entre l'acteur et le système. On distingue le scénario
nominal (qui se déroule quand il n'y a pas d'erreur), des scénarios
alternatifs (qui sont les variantes du scénario nominal) et enfin les
scénarios d'exception (qui décrivent les cas d'erreurs).
• Des postconditions : elles décrivent l'état du système à l'issue des
différents scénarios.

PR. SOUKAINA MJAHED 26

UML – Description textuelle des cas d'utilisation

❑ Partie 3 : Exigence non fonctionnelle

❑ Rubrique optionnelle.
❑ Contient généralement des spécifications non fonctionnelles (spécifications
techniques…).
❑ Peut éventuellement contenir une description des besoins en termes
d'interface graphique.

PR. SOUKAINA MJAHED 27

UML – Description textuelle des cas d'utilisation
❑ Exemple de description textuelle : Le cas d‘utilisation ‘Retirer de l’argent’

PR. SOUKAINA MJAHED 28

 UML – Description textuelle des cas d'utilisation
❑ Exemple de description textuelle : Le cas d‘utilisation ‘Retirer de l’argent’
Nom Retirer de l’argent
Objectif Ce cas d’utilisation permet aux possesseurs de carte bancaire de retirer de l’argent.
Acteurs principaux Un porteur de carte bancaire.
Acteurs secondaires Le Système d’Information de la banque et le Système d’Autorisation Globale Carte
Bancaire.
Dates 03/01/2022
Responsable S. Mjahed
Version 1.0
Pré-conditions - Le DAB contient des billets.
- Les connexions avec le Système d’Autorisation et le Système d’information de la
banque sont opérationnelles.

PR. SOUKAINA MJAHED 29

 UML – Description textuelle des cas d'utilisation
❑ Exemple de description textuelle : Le cas d‘utilisation ‘Retirer de l’argent’
Scénario nominal 1. Le Porteur de carte introduit sa carte dans le DAB.
2. Le DAB vérifie que la carte introduite est bien une carte bancaire.
3. Le DAB demande le code de la carte au Porteur de carte.
4. Le Porteur de carte saisit son code.
5. Le DAB compare ce code avec celui qui est codé sur la carte.
6. Le DAB demande une autorisation au Système Globale d’autorisation.
7. Le Système d’Autorisation globale donne son accord et indique le crédit hebdomadaire.
8. Le DAB demande le montant désiré au Porteur de carte.
9. Le Porteur de carte saisit le montant.
10. Le DAB vérifie si le montant demandé est inférieur ou égale au crédit hebdomadaire.
11. Le DAB demande au Porteur de carte s’il désire un ticket.
12. Le Porteur de carte accepte le ticket.
13. Le DAB rend la carte et demande au Porteur de carte de la retirer.
14. Le Porteur de carte reprend sa carte.
15. Le DAB délivre le ticket et les billets.
16. Le Porteur de carte prend les billets et le ticket.

PR. SOUKAINA MJAHED 30

 UML – Description textuelle des cas d'utilisation
❑ Exemple de description textuelle : Le cas d‘utilisation ‘Retirer de l’argent’
Scénario alternatif SA1 SA1 commence au point 5 du scénario nominale.
Le DAB indique que le code est erroné. Le DAB enregistre l’échec.
Le scénario reprend au point 3 du scénario nominal.
Scénario alternatif SA2 SA2 commence au point 10 du scénario nominale.
Le DAB affiche le montant max et demande au Porteur de carte de ressaisir un montant.
Le scénario reprend au point 9 du scénario nominal.
Scénario alternatif SA3 SA3 commence au point 11 du scénario nominale.
12. L’utilisateur refuse le ticket.
Puis 13 et 14 du scénario nominal.
12. Le DAB délivre les billets.
13. L’utilisateur prend les billets.
Scénario d’exception SE1 : SE1 commence au point 2 du scénario nominal.
Carte non valide Le DAB Indique que la carte n’est pas valide restitue la carte et met fin au cas.
Scénario d’exception SE2 : Le SE2 commence au point 5 du scénario nominal.
code est erroné pour la Le DAB Indique que le code est erroné pour la troisième fois, confisque la carte et met fin au cas.
troisième fois
Scénario d’exception SE3 : SE3 commence au point 6 du scénario nominal.
Retrait non autorisé PR. SOUKAINA MJAHED
Le DAB Indique que tout retrait est impossible, restitue la carte et met fin au cas. 31
 UML – Description textuelle des cas d'utilisation
❑ Exemple de description textuelle : Le cas d‘utilisation ‘Retirer de l’argent’

Scénario d’exception SE4 : SE4 commence au point 11 du scénario nominal.

Carte non reprise Au bout de 30s, le DAB confisque la carte et met fin au cas.
Scénario d’exception SE5 : SE5 commence au point 15 du scénario nominal.
Billets non pris Au bout de 30s, le DAB reprend les billets et met fin au cas.
Scénario d’exception SE6 : SE6 peut démarrer entre les points 4 et 9 du scénario nominal.
Annulation de la transaction Le DAB éjecte la carte et met fin au cas.
Post-conditions Les détails de la transaction doivent être enregistrés (montant, numéro carte, date…) aussi bien en cas de
succès que d’échec.
Exigences non fonctionnelles Sécurité : La saisie du code confidentiel ne doit pas faire apparaître le code à l’écran.

PR. SOUKAINA MJAHED 32

 UML – Diagramme des cas d’utilisation
❑ Exercice d’application
Une bibliothèque municipale souhaite informatiser la gestion de l’emprunt de livres.
Un usager peut :
• Consulter le catalogue en ligne.
• S’inscrire comme membre.
• Emprunter un livre s’il est membre et que le livre est disponible.
• Retourner un livre.
Un bibliothécaire peut :
• Enregistrer l’inscription d’un nouvel usager.
• Enregistrer les emprunts et les retours de livres.
• Mettre à jour le catalogue (ajouter/supprimer des livres).

• Choisir les 2 cas d’utilisation les plus importants de ce système.

• Réaliser le tableau de description textuelle de ces 2 cas d’utilisation.

PR. SOUKAINA MJAHED 33

 UML – Diagramme des cas d’utilisation
❑ Exercice d’application
Dans une entreprise X, le traitement des commandes clients et de la facturation est le suivant :
Les commandes clients arrivent chez la secrétaire au matin. Celle-ci la remet en début d’après-midi au service préparation des
livraisons. Dès que la commande parvient au responsable, celui-ci vérifie l’identité du client et examine les stocks, si les stocks
sont suffisants il rédige un bon de préparation sinon il adresse un courrier type au client et la commande est mise en attente.
Lorsqu’un préparateur est disponible, celui-ci prépare la livraison à l’aide du bon de préparation : il prélève les marchandises,
les emballe, saisit les bons de préparation et édite en double exemplaire le bon de livraison dont un exemplaire est adressé au
client en même temps que les colis, le deuxième exemplaire est transmis au service comptable.
Le service comptable établit les factures : A partir du bon de livraison, l’opératrice comptable saisit le n°du bon, vérifie les
tarifs et les conditions de règlement et édite la facture en double exemplaire : un exemplaire est adressé au client, l’autre est
archivé en attente de comptabilisation
L’enregistrement comptable des factures : l’opératrice comptable saisit le n°de facture et valide les données à l’écran. Après
saisie, le grand livre est mis à jour.

• Choisir les 2 cas d’utilisation les plus importants de ce système.

• Réaliser le tableau de description textuelle de ces 2 cas d’utilisation.

PR. SOUKAINA MJAHED 34

UML – Diagramme de Séquence

PR. SOUKAINA MJAHED 35

 UML – Diagramme de Séquence
❑ Il permet de représenter des échanges entre les différents objets et acteurs du système en
fonction du temps.
❑ Les messages sont échangés entre les lignes de vie, présentés dans un ordre chronologique (la
dimension verticale).
❑ A moins que le système à modéliser soit extrêmement simple, nous ne pouvons pas modéliser la
dynamique globale du système dans un seul diagramme.
❑ Solution : faire appel à un ensemble de diagrammes de séquences chacun illustre un cas
d’utilisation.
❑ Il existe deux types de diagrammes de séquence : Diagramme de séquence analyse (boite noire)
et diagramme de séquence conception (boite blanche).
❑ Composants : ligne de vie, messages asynchrones, messages synchrones, messages de création /
suppression d’une instance, événement, fragment d’interaction combiné.

PR. SOUKAINA MJAHED 36

UML – Diagramme de Séquence

❑ Acteur : les entités qui interagissent avec le système ou qui sont

extérieures à lui.

❑ Boite d’activation : Représente le temps nécessaire pour qu'un

objet accomplisse une tâche. Plus la tâche nécessite de temps, plus
la boîte d'activation est longue.

PR. SOUKAINA MJAHED 37

UML – Diagramme de Séquence
❑ Ligne de vie :
• Se représente par un rectangle, auquel est accroché une ligne
verticale pointillée, contenant une étiquette dont la syntaxe
est : objet : classe.
• Au moins un des deux noms doit être spécifié dans l'étiquette,
les deux points (:) sont, quant à eux, obligatoires.
• Représente le passage du temps qui se prolonge vers le bas.
• Cette ligne verticale en pointillés montre les événements
séquentiels affectant un objet au cours du processus
schématisé.
• Les lignes de vie peuvent commencer par une forme
rectangulaire avec un intitulé ou par un symbole d'acteur.
PR. SOUKAINA MJAHED 38
UML – Diagramme de Séquence
❑ Frontière : des interfaces qui interagissent avec des acteurs
externes. Ces objets peuvent, par exemple, être des interfaces
utilisateur où l’acteur serait alors une personne.

❑ Entité : représentent des conteneurs de données ou des objets qui

contiennent des données système.

❑ Contrôle : Pour que les frontières et les entités communiquent, il

faut faire appel à un élément de contrôle. L’élément de
contrôle relie l’entité et la frontière en tant que médiateur. Il
surveille les signaux des deux éléments et vérifie leur logique.

PR. SOUKAINA MJAHED 39

UML – Diagramme de Séquence
❑ Message :
❑ Un message définit une communication particulière entre des lignes de vie.
❑ Plusieurs types de messages existent, les plus communs sont :
• l'envoi d'un signal ;
• l'invocation d'une opération ;
• la création ou la destruction d'une instance.

PR. SOUKAINA MJAHED 40

UML – Diagramme de Séquence
❑ Message asynchrone :
❑ Une interruption ou un événement sont des exemples de signaux : Ils n'attendent
pas de réponse et ne bloquent pas l'émetteur qui ne sait pas si le message arrivera à
destination, le cas échéant quand il arrivera et s'il sera traité par le destinataire.
❑ Un signal est, par définition, un message asynchrone.
❑ Graphiquement, un message asynchrone se représente par une flèche en traits
pleins et à l'extrémité ouverte partant de la ligne de vie d'un objet expéditeur et
allant vers celle de l'objet cible.

PR. SOUKAINA MJAHED 41

UML – Diagramme de Séquence
❑ Message synchrone :
❑ La plupart des invocations sont synchrones,
l'émetteur reste bloqué le temps que dure
l'invocation de l'opération.
❑ Graphiquement, un message synchrone se
représente par une flèche en traits pleins et à
l'extrémité pleine partant de la ligne de vie
d'un objet expéditeur et allant vers celle de
l'objet cible.
❑ Ce message peut être suivi d'une réponse qui
se représente par une flèche en pointillé.

PR. SOUKAINA MJAHED 42

UML – Diagramme de Séquence
❑ Message reflexive :
❑ L’objets envoie un message à lui-même.
❑ L’expéditeur est lui-même le destinataire.

PR. SOUKAINA MJAHED 43

UML – Diagramme de Séquence
❑ Messages de création et destruction d'instance :
❑ La création d'un objet est matérialisée par une
flèche qui pointe sur le sommet d'une ligne de
vie.
❑ La destruction d'un objet est matérialisée par
une croix qui marque la fin de la ligne de vie
de l'objet. La destruction d'un objet n'est pas
nécessairement consécutive à la réception
d'un message.

PR. SOUKAINA MJAHED 44

UML – Diagramme de Séquence
❑ Événements et messages :
❑ UML permet de séparer clairement l'envoi du message, sa réception, ainsi que
le début de l'exécution de la réaction et sa fin.

PR. SOUKAINA MJAHED 45

UML – Diagramme de Séquence
❑ Événements et messages :

PR. SOUKAINA MJAHED 46

 UML – Diagramme de Séquence
❑ Message perdu et trouvé :
❑ Un message complet est tel que les événements d'envoi et de réception sont connus. Un
message complet se représente par une simple flèche dirigée de l'émetteur vers le
récepteur.
❑ Un message perdu est tel que l'événement d'envoi est connu, mais pas l'événement de
réception. Il se représente par une flèche qui pointe sur une petite boule noire.
❑ Un message trouvé est tel que l'événement de réception est connu, mais pas l'événement
d'émission. Une flèche partant d'une petite boule noire représente un message trouvé.

PR. SOUKAINA MJAHED 47

 UML – Diagramme de Séquence
❑ Exécution de méthode et objet actif :
❑ Un objet actif initie et contrôle le flux d'activités. Graphiquement, la ligne pointillée
verticale d'un objet actif est remplacée par un double trait vertical.
❑ Un objet passif, au contraire, a besoin qu'on lui donne le flux d'activité pour pouvoir
exécuter une méthode. La spécification de l'exécution d'une réaction sur un objet passif se
représente par un rectangle blanc ou gris placé sur la ligne de vie en pointillé.

PR. SOUKAINA MJAHED 48

UML – Diagramme de Séquence
❑ Messages :

PR. SOUKAINA MJAHED 49

UML – Diagramme de Séquence

❑ Messages :

PR. SOUKAINA MJAHED 50

 UML – Diagramme de Séquence
❑ Exo 1 : Réaliser le diagramme de séquence d’analyse du cas d’utilisation « Publier
message sur Forum Y ».
❑ Exo 2 : Réaliser le diagramme de séquence de conception de « Changer prix
article » par un administrateur de la plateforme.
❑ Exo 3 : Réaliser le diagramme de séquence de conception de « S’authentifier via
compte Facebook ».
❑ Exo 4 : Réaliser le diagramme de séquence de conception de « Exécuter une
requête ».
❑ Exo 5 : Réaliser le diagramme de séquence de conception de « S’inscrire à une
formation » entant qu’étudiant dans une université.
❑ Exo 6 : Réaliser le diagramme de séquence d’analyse de « Contacter administrateur
» tel que traiter par l’administrateur.

PR. SOUKAINA MJAHED 51

 UML – Diagramme de Séquence
❑ Diagramme de Séquence d’Analyse (boite noire) vs de Conception (boite blanche) :

PR. SOUKAINA MJAHED 52

 UML – Diagramme de Séquence
❑ Fragments d'interaction combinés :
❑ Représente des articulations d'interactions.
❑ Les fragments combinés permettent de décrire des diagrammes de séquence de
manière compacte.
❑ Il existe 13 Fragments combinés.

PR. SOUKAINA MJAHED 53

UML – Diagramme de Séquence
❑ Fragments d'interaction combinés :
❑ Opt : Fragment parcouru si une condition est vérifiée

PR. SOUKAINA MJAHED 54

UML – Diagramme de Séquence
❑ Fragments d'interaction combinés :
❑ Alt : Equivalent à la structure de contrôle "si .. alors .. sinon"

PR. SOUKAINA MJAHED 55

UML – Diagramme de Séquence
❑ Fragments d'interaction combinés :
❑ Loop : Répétition du fragment tant que la condition est vérifiée

PR. SOUKAINA MJAHED 56

UML – Diagramme de Séquence
❑ Fragments d'interaction combinés :
❑ Par : Un fragment d’interaction avec l’opérateur de traitements parallèles
contient au moins deux sous fragments (opérandes) séparés par des pointillés
qui s’exécutent simultanément (traitements concurrents)

PR. SOUKAINA MJAHED 57

UML – Diagramme de Séquence
❑ Fragments d'interaction combinés :
❑ Break : pour les fragments représentants des scenarios exceptionnels ou de
ruptures (ex appui sur la touche « Esc »). Le scénario de rupture est exécuté si
une condition de garde est satisfaite.

PR. SOUKAINA MJAHED 58

UML – Diagramme de Séquence
❑ Fragments d'interaction combinés :
❑ Ref : permet de faire appel à un autre diagramme de séquence.
❑ Les inclusions et les extensions sont des cas typiques d’utilisation de la
réutilisation par référencement

PR. SOUKAINA MJAHED 59

 UML – Diagramme de Séquence
❑ Exercice d’application
Une bibliothèque municipale souhaite informatiser la gestion de l’emprunt de livres.
Un usager peut :
• Consulter le catalogue en ligne.
• S’inscrire comme membre.
• Emprunter un livre s’il est membre et que le livre est disponible.
• Retourner un livre.
Un bibliothécaire peut :
• Enregistrer l’inscription d’un nouvel usager.
• Enregistrer les emprunts et les retours de livres.
• Mettre à jour le catalogue (ajouter/supprimer des livres).

• Choisir les 2 cas d’utilisation les plus importants de ce système.

• Réaliser le diagramme de séquence de ces 2 cas d’utilisation.

PR. SOUKAINA MJAHED 60

 UML – Description textuelle des cas d'utilisation
❑ Donner le Diagramme de Séquence du cas d‘utilisation ‘Retirer de l’argent’
Scénario nominal 1. Le Porteur de carte introduit sa carte dans le DAB.
2. Le DAB vérifie que la carte introduite est bien une carte bancaire.
3. Le DAB demande le code de la carte au Porteur de carte.
4. Le Porteur de carte saisit son code.
5. Le DAB compare ce code avec celui qui est codé sur la carte.
6. Le DAB demande une autorisation au Système Globale d’autorisation.
7. Le Système d’Autorisation globale donne son accord et indique le crédit hebdomadaire.
8. Le DAB demande le montant désiré au Porteur de carte.
9. Le Porteur de carte saisit le montant.
10. Le DAB vérifie si le montant demandé est inférieur ou égale au crédit hebdomadaire.
11. Le DAB demande au Porteur de carte s’il désire un ticket.
12. Le Porteur de carte accepte le ticket.
13. Le DAB rend la carte et demande au Porteur de carte de la retirer.
14. Le Porteur de carte reprend sa carte.
15. Le DAB délivre le ticket et les billets.
16. Le Porteur de carte prend les billets et le ticket.

PR. SOUKAINA MJAHED 61

PR. SOUKAINA MJAHED 62
UML – Description textuelle des cas d'utilisation
❑ Donner le Diagramme de Séquence du cas d‘utilisation ‘Retirer de l’argent’

PR. SOUKAINA MJAHED 63

 UML – Diagramme des cas d’utilisation
❑ Exercice d’application
Dans une entreprise X, le traitement des commandes clients et de la facturation est le suivant :
Les commandes clients arrivent chez la secrétaire au matin. Celle-ci la remet en début d’après-midi au service préparation des
livraisons. Dès que la commande parvient au responsable, celui-ci vérifie l’identité du client et examine les stocks, si les stocks
sont suffisants il rédige un bon de préparation sinon il adresse un courrier type au client et la commande est mise en attente.
Lorsqu’un préparateur est disponible, celui-ci prépare la livraison à l’aide du bon de préparation : il prélève les marchandises,
les emballe, saisit les bons de préparation et édite en double exemplaire le bon de livraison dont un exemplaire est adressé au
client en même temps que les colis, le deuxième exemplaire est transmis au service comptable.
Le service comptable établit les factures : A partir du bon de livraison, l’opératrice comptable saisit le n°du bon, vérifie les
tarifs et les conditions de règlement et édite la facture en double exemplaire : un exemplaire est adressé au client, l’autre est
archivé en attente de comptabilisation
L’enregistrement comptable des factures : l’opératrice comptable saisit le n°de facture et valide les données à l’écran. Après
saisie, le grand livre est mis à jour.

• Réaliser les diagrammes de séquence des 2 cas d’utilisation les plus importants.

PR. SOUKAINA MJAHED 64

 UML – Diagramme d’activité
❑ Dans UML, un diagramme d’Activités est utilisé pour afficher la séquence d’activités.
❑ Les diagrammes d’activité affichent le flux de travail d’un point de départ à un point d’arrivée en
détaillant les nombreux chemins de décision existant dans la progression des événements
contenus dans l’activité.
❑ Ils peuvent être utilisés pour détailler des situations dans lesquelles un traitement parallèle peut
avoir lieu lors de l’exécution de certaines activités.
❑ Les diagrammes d’activité sont utiles pour la modélisation métier car ils sont utilisés pour détailler
les processus impliqués dans les activités métier.
❑ Un diagramme d'activités visualise un graphe d'activités qui modélise le comportement interne
d'une méthode (une réalisation d'une opération), d'un cas d'utilisation ou plus généralement d'un
processus impliquant un ou plusieurs classificateurs (classes / cas d'utilisation / paquetages /...).

PR. SOUKAINA MJAHED 65

 UML – Diagramme d’activité
❑ Un diagramme d'activités représente l'état d'exécution d'un mécanisme, sous la forme d'un
déroulement d'étapes regroupées séquentiellement dans des branches parallèles de flots de
contrôle.
❑ Il est utile pour la représentation des processus métiers et les cas d'utilisation.
❑ Le diagramme d'activités comprend :
▪ des activités (une activité = une étape d'exécution, état-activité). Une activité représente une
exécution d'un mécanisme, un déroulement d'étapes séquentielles. Le passage d'une activité vers
une autre est matérialisé par une transition.
▪ des transitions qui sont automatiques entre activités, il est inutile également de préciser les
événements. Les transitions sont déclenchées par la fin d'une activité et provoquent le début
immédiat d'une autre.
❑ En théorie, tous les mécanismes dynamiques pourraient être décrits par un diagramme d'activités,
mais seuls les mécanismes complexes ou intéressants méritent d'être représentés.
PR. SOUKAINA MJAHED 66
 UML – Diagramme d’activité
❑ Exemple de diagramme d’activités :

PR. SOUKAINA MJAHED 67

 UML – Diagramme d’activité
❑ Activité : est la spécification d’une séquence paramétrée de comportement. Une activité est
représentée comme un rectangle à coins arrondis enfermant toutes les actions, les flux de contrôle
et d’autres éléments qui composent l’activité.

PR. SOUKAINA MJAHED 68

 UML – Diagramme d’activité
❑ Symbole de début : (aussi appelé nœud initial) Représente le début d'un processus ou d'un flux de
travail dans un diagramme d'activités. Il peut être utilisé seul ou avec un symbole de note qui
explique le point de départ.

PR. SOUKAINA MJAHED 69

 UML – Diagramme d’activité
❑ Action : représente un pas seul dans une activité. Les actions sont dénotées par des rectangles
ronds-coincés.

❑ Une action est le plus petit traitement qui puisse être exprimé en UML.
❑ Une action a une incidence sur l’état du système ou en extrait une information.
❑ Les actions sont des étapes discrètes à partir desquelles se construisent les comportements.
❑ La notion d’action est à rapprocher de la notion d’instruction élémentaire d’un langage de
programmation (comme C++ ou Java).

PR. SOUKAINA MJAHED 70

 UML – Diagramme d’activité
❑ Symbole de raccord : Indique le flux directionnel, ou flux de contrôle, de l'activité. Une flèche
entrante marque le début d'une étape d'une activité ; une fois l'étape terminée, le flux se poursuit
avec la flèche sortante.

❑ Symbole de raccord/barre de synchronisation : (aussi appelé nœud d’union/join) Associe deux

actions simultanées et les réintroduit dans un flux où n'a lieu qu'une seule action à la fois.
Représenté par une ligne verticale ou horizontale épaisse.

PR. SOUKAINA MJAHED 71

 UML – Diagramme d’activité
❑ Symbole d'embranchement : (aussi appelé nœud de bifurcation / fork) Divise un flux d'activités
en deux actions simultanées. Symbolisé par plusieurs lignes fléchées qui partent d'un raccord.

PR. SOUKAINA MJAHED 72

 UML – Diagramme d’activité
❑ Symbole de décision : Représente une décision et possède toujours au moins deux
embranchements avec le texte de la condition pour permettre aux utilisateurs de voir les options.
Ce symbole représente la ramification ou la fusion de différents flux et sert de cadre ou de
conteneur.

PR. SOUKAINA MJAHED 73

 UML – Diagramme d’activité
❑ Symbole de fin de flux : (aussi appelé nœud de fin de flot) Représente la fin d’un schéma de
procédé spécifique. Ce symbole ne doit pas représenter la fin de tous les flux dans une activité ;
dans ce cas, vous devez utiliser le symbole de fin. Le symbole de fin de flux doit être placé à la fin
d’un procédé dans un flux d’activités unique.
❑ Symbole de fin : (aussi appelé nœud de fin simple) Marque l’état final d’une activité et représente
l’achèvement de tous les flux d’un procédé.
❑ La plupart des diagrammes n’ont qu’un seul flux principal, donc un nœud de fin simple suffit.
❑ Le nœud “fin de flux” est utile seulement quand il existe plusieurs chemins parallèles (forks/join)
ou plusieurs branches alternatives qu’il faut tous interrompre d’un coup.

PR. SOUKAINA MJAHED 74

 UML – Diagramme d’activité
❑ Symbole de fin de flux : (aussi appelé
nœud de fin de flot) Représente la fin
d’un schéma de procédé spécifique. Ce
symbole ne doit pas représenter la fin
de tous les flux dans une activité ; dans
ce cas, vous devez utiliser le symbole de
fin. Le symbole de fin de flux doit être
placé à la fin d’un procédé dans un flux
d’activités unique.
❑ Symbole de fin : (aussi appelé nœud de
fin simple) Marque l’état final d’une
activité et représente l’achèvement de
tous les flux d’un procédé.

PR. SOUKAINA MJAHED 75

 UML – Diagramme d’activité
❑ Couloirs d'activité :
❑ Les diagrammes d'activités indiquent ce qui se
passe sans préciser qui fait quoi (en termes de
programmation, ils ne précisent pas quelle classe
est responsable et en termes de processus métier,
ils ne précisent pas quelle partie de l'organisation
exécute chaque action).
❑ Il est possible de diviser un diagramme d'activités
en partitions ou couloirs d'activités (travées,
swimlanes).
❑ Chaque partition montre quelles actions sont
exécutées par une classe ou une unité
organisationnelle.
PR. SOUKAINA MJAHED 76
 UML – Diagramme d’activité
❑ Exercice d’application
Une bibliothèque municipale souhaite informatiser la gestion de l’emprunt de livres.
Un usager peut :
• Consulter le catalogue en ligne.
• S’inscrire comme membre.
• Emprunter un livre s’il est membre et que le livre est disponible.
• Retourner un livre.
Un bibliothécaire peut :
• Enregistrer l’inscription d’un nouvel usager.
• Enregistrer les emprunts et les retours de livres.
• Mettre à jour le catalogue (ajouter/supprimer des livres).

• Définir au moins un processus.

• Réaliser le diagramme d’activité relatif à ce processus.

PR. SOUKAINA MJAHED 77

 UML – Diagramme
d’activité
❑ Diagramme d’activités d’un DAB

PR. SOUKAINA MJAHED 78

 UML – Programmation Orientée objet
❑ Avant la POO, la programmation procédurale dominait. On écrivait des fonctions qui manipulaient
des données globales. Mais à mesure que les logiciels grandissaient, cette approche devenait :
▪ difficile à maintenir (une fonction modifiée pouvait casser le reste),
▪ difficile à faire évoluer (ajouter une nouvelle fonctionnalité impliquait souvent de tout
réécrire),
▪ peu réutilisable (le code était spécifique à un contexte).
❑ La POO a été inventée pour structurer la complexité : elle permet de penser un logiciel comme un
ensemble d’objets interagissant, plutôt qu’une simple suite d’instructions.
❑ L’idée fondamentale est de représenter les objets du monde réel dans le programme :
▪ Chaque objet informatique correspond à une entité réelle ou conceptuelle (ex. : voiture,
compte bancaire, étudiant, produit…)
▪ Chaque objet a :
❖ Des caractéristiques → appelées attributs
❖ Des comportements → appelés méthodes

PR. SOUKAINA MJAHED 79

 UML – Programmation Orientée objet
❑ Code Programmation Orientée Objet : ❑ Code Programmation Procédural :

PR. SOUKAINA MJAHED 80

 UML – Programmation Orientée objet
❑ Programmation Orientée Objet VS Programmation Procédurale
Critère Procédurale Orientée Objet
Structure Fonctions et variables séparées Classes et objets
Organisation du code Logique séquentielle Modélisation du monde réel
Réutilisabilité Faible (copie de code) Forte (héritage, polymorphisme)
Maintenance Plus difficile (dépendances globales) Plus facile (modularité, encapsulation)
Adapté à Petits scripts, calculs simples Grands projets, systèmes complexes
Exemples de langages C, Pascal Java, C++, Python, C#, Ruby

PR. SOUKAINA MJAHED 81

 UML – Programmation Orientée objet
❑ Exemple :
❑ marque et vitesse = attributs
❑ demarrer() et accelerer() = méthodes
❑ Voiture = classe (modèle)
❑ Une instance de Voiture = objet réel (par ex. maVoiture)

PR. SOUKAINA MJAHED 82

 UML – Programmation Orientée
objet
❑ Les éléments constitutifs de la POO :
❑ Classe : est le plan de fabrication d’un objet.
Elle décrit ce qu’un objet sait (attributs) et ce
qu’il sait faire (méthodes).
❑ Attributs : Variables internes à la classe. Elles
stockent l’état de l’objet.
❑ Méthodes : Fonctions internes à la classe. Elles
définissent le comportement de l’objet.
❑ Objet : est une instance concrète d’une classe.
❑ Constructeur : méthode spéciale exécutée à la
création de l’objet.

PR. SOUKAINA MJAHED 83

 UML – Programmation Orientée objet
❑ Valeurs de la Programmation Orientée Objet :
Concept Définition Exemple
Classe Modèle ou plan de création d’objets class Voiture { ... }
Objet Instance concrète d’une classe maVoiture = new Voiture()
Attributs Variables internes à l’objet couleur, vitesse
Méthodes Fonctions internes à l’objet démarrer(), freiner()
Masquer les détails internes et protéger les
Encapsulation private vitesse; avec getVitesse()
données
Héritage Réutiliser le code d’une classe par une autre class Camion extends Voiture
Une même méthode peut agir différemment afficher() agit différemment pour Voiture
Polymorphisme
selon l’objet et Camion
Simplifier la complexité en ne montrant que
Abstraction Classe abstraite Forme avec dessiner()
l’essentiel

PR. SOUKAINA MJAHED 84

 UML – Programmation Orientée
objet
❑ Les piliers fondamentaux de la POO :
❑ Encapsulation : protéger les données internes
d’un objet pour éviter qu’elles soient
modifiées n’importe comment. On rend les
attributs privés (private) et on fournit des
méthodes d’accès contrôlées (get et set).

❑ Héritage : permettre à une classe d’hériter des

attributs et méthodes d’une autre. Cela évite
la duplication de code.

PR. SOUKAINA MJAHED 85

 UML – Programmation Orientée
objet
❑ Les piliers fondamentaux de la POO :
❑ Polymorphisme : la même méthode peut avoir des
comportements différents selon l’objet qui l’utilise.
Ainsi, Le code devient plus flexible, on peut appeler
parler() sans savoir le type exact d’animal.

❑ Abstraction : ne montrer que l’essentiel, cacher les

détails techniques. Une classe abstraite définit un
comportement commun, mais laisse les sous-classes
décider de l’implémentation.

PR. SOUKAINA MJAHED 86

 UML – Diagramme d’états-transition
❑ C’est le diagramme UML qui décrit le cycle de vie d’un objet/système réactif : dans quel état il se
trouve, quels événements le font changer d’état, et quelles actions sont exécutées en cours de
route.
❑ Modéliser des comportements réactifs : interfaces, workflows, IoT, protocoles, automates, règles
métier séquentielles.
❑ Clarifier les règles de passage d’un état à un autre (qui a le droit, quand, sous quelles conditions).
❑ Détecter les trous de logique : transitions manquantes, boucles impossibles, conflits de règles.
❑ Comportement décrit par états + transitions entre les états
▪ État : abstraction d'un moment de la vie d'une entité pendant lequel elle satisfait un ensemble
de conditions
▪ Transition : changement d'état

PR. SOUKAINA MJAHED 87

 UML – Diagramme d’états-transition
❑ Comportement décrit par états + transitions entre les états
▪ État : abstraction d'un moment de la vie d'une entité pendant lequel elle satisfait un ensemble
de conditions
▪ Transition : changement d'état

❑ Intérêt :
▪ Vue synthétique de la dynamique de l'entité
▪ Regroupe un ensemble de scénarios
PR. SOUKAINA MJAHED 88
 UML – Diagramme d’états-transition
❑ Types d'états :
▪ État initial : Initialisation du système, exécution du constructeur de l'objet.
▪ État final : Fin de vie du système, destruction de l'objet
▪ États intermédiaires : étapes de la vie du système, de l'objet

❑ Événement : Fait instantané venant de l'extérieur du système et survenant à un instant donné. Un

événement se produit à un instant précis et est dépourvu de durée. Quand un événement est
reçu, une transition peut être déclenchée et faire basculer l'objet dans un nouvel état. On peut
diviser les événements en plusieurs types explicites et implicites : signal, appel, changement et
temporel.
PR. SOUKAINA MJAHED 89
 UML – Diagramme d’états-transition
❑ Types d'événements :
▪ Signal : réception d'un message asynchrone
▪ Appel d'une opération (synchrone) : liée aux cas d'utilisation…
▪ Satisfaction d'une condition booléenne : when(cond), évaluée continuellement jusqu'à ce
qu'elle soit vraie
▪ Temps :
❖ Date relative : when(date = date)
❖ Date absolue : after(durée)

PR. SOUKAINA MJAHED

90
 UML – Diagramme d’états-transition
❑ Caractéristiques d'un état :
▪ Conditions vérifiées
▪ Événements attendus

PR. SOUKAINA MJAHED 91

 UML – Diagramme d’états-transition
❑ Action : Réaction du système à un événement. Elle est atomique, instantanée, non interruptible.
❑ Exemples d'actions (syntaxe laissée libre) : affectation, envoi d'un signal, appel d'une opération,
création ou destruction d'un objet.
❑ Action déclenchée par un événement événement [condition] / action Lorsque l'événement se
produit, si la condition est vérifiée, alors l'action est effectuée

PR. SOUKAINA MJAHED 92

 UML – Diagramme d’états-transition
❑ Événements internes à l'état : Événement sans changement d'état.

❑ Événements externes à l'état : transitions

▪ Transition vers l'état : evt-in
▪ Transition depuis l'état : evt-out
▪ Transition depuis l'état vers lui-même : evt-self

PR. SOUKAINA MJAHED 93

 UML – Diagramme d’états-transition
❑ Exemple diagramme état transition de l’objet DBA :

PR. SOUKAINA MJAHED 94

 UML – Diagramme d’états-transition
❑ Exemple diagramme état transition de l’objet Tâche :

PR. SOUKAINA MJAHED 95

 UML – Diagramme d’états-transition
❑ Etat composite : État regroupant un ensemble d'états dans l’objectif
▪ Hiérarchiser les états
▪ Structurer les comportements complexes
▪ Factoriser les actions

PR. SOUKAINA MJAHED 96

 UML – Diagramme d’états-transition
❑ Etat composite : État regroupant un ensemble d'états dans l’objectif
▪ Hiérarchiser les états
▪ Structurer les comportements complexes
▪ Factoriser les actions

PR. SOUKAINA MJAHED 97

 UML – Diagramme d’états-transition
❑ Etat orthogonal : État composite dans lequel plusieurs états sont actifs simultanément
(concurrence/parallélisme)
▪ Hiérarchiser les états
▪ Structurer les comportements complexes
▪ Factoriser les actions

PR. SOUKAINA MJAHED 98

 UML – Diagramme d’états-transition
❑ Exercice d’application
Une bibliothèque municipale souhaite informatiser la gestion de l’emprunt de livres.
Un usager peut :
• Consulter le catalogue en ligne.
• S’inscrire comme membre.
• Emprunter un livre s’il est membre et que le livre est disponible.
• Retourner un livre.
Un bibliothécaire peut :
• Enregistrer l’inscription d’un nouvel usager.
• Enregistrer les emprunts et les retours de livres.
• Mettre à jour le catalogue (ajouter/supprimer des livres).

• Définir au moins un objet qui change d’états dans le système.

• Réaliser le diagramme d’états-transitions relatif à cet objet.

PR. SOUKAINA MJAHED 99

 UML – Diagramme de classes
❑ C’est un diagramme structurel d’UML qui représente la structure statique d’un système
informatique.
❑ Il décrit :
▪ Les classes du système (concepts, entités, objets métiers)
▪ Leurs attributs (données)
▪ Leurs opérations (méthodes / comportements)
▪ Les relations entre classes :
❖ associations
❖ multiplicités
❖ dépendances
❖ agrégations
❖ compositions
❖ généralisations / héritages
PR. SOUKAINA MJAHED 100
 UML – Diagramme de classes
❑ Classe : Regroupement d'objets de même nature (mêmes attributs + mêmes opérations)
❑ Objet = instance d'une classe

PR. SOUKAINA MJAHED 101

 UML – Diagramme de classes
❑ Attributs :
▪ Caractéristique partagée par tous les objets de la classe
▪ Associe à chaque objet une valeur
▪ Type associé simple (int, bool...), primitif (Date) ou énuméré

PR. SOUKAINA MJAHED 102

 UML – Diagramme de classes
❑ Opérations
▪ Service qui peut être demandé à tout objet de la classe
▪ Comportement commun à tous les objets de la classe
▪ Ne pas confondre avec une méthode = implantation de l'opération

PR. SOUKAINA MJAHED 103

 UML – Diagramme de classes
❑ Association entre classes : Relation binaire (en général)
❑ Rôle : Nomme l'extrémité d'une association, permet d'accéder aux objets liés par l'association à un
objet donné
❑ Multiplicité : Contraint le nombre d'objets liés par l'association

PR. SOUKAINA MJAHED 104

 UML – Diagramme de classes
❑ Rappel : Types des attributs simples, primitif ou énuméré
❑ En particulier, pas d'attribut dont le type est une classe du diagramme

PR. SOUKAINA MJAHED 105

 UML – Diagramme de classes
❑ Rappel : Types des attributs simples, primitif ou énuméré
❑ En particulier, pas d'attribut dont le type est une classe du diagramme
❑ Mais association vers cette classe

PR. SOUKAINA MJAHED 106

 UML – Diagramme de classes
❑ Association réflexive :

PR. SOUKAINA MJAHED 107

 UML – Diagramme de classes
❑ Association multiple :

PR. SOUKAINA MJAHED 108

 UML – Diagramme de classes
❑ Multiplicités : Nombre d'objets de la classe B associés à un objet de la classe A

PR. SOUKAINA MJAHED 109

 UML – Diagramme de classes
❑ Hiérarchie de classes : Regrouper les classes partageant des attributs et des opérations et les
organiser en arborescence
❑ Spécialisation : raffinement d'une classe en une sous-classe
❑ Généralisation : abstraction d'un ensemble de classes en super-classe

PR. SOUKAINA MJAHED 110

 UML – Diagramme de classes
❑ Hiérarchie de classes : Regrouper les classes partageant des attributs et des opérations et les
organiser en arborescence
❑ Spécialisation : raffinement d'une classe en une sous-classe
❑ Généralisation : abstraction d'un ensemble de classes en super-classe

PR. SOUKAINA MJAHED 111

 UML – Diagramme de classes
❑ Hiérarchie de classes : Regrouper les classes partageant des attributs et des opérations et les
organiser en arborescence
❑ Héritage : Construction d'une classe à partir d'une classe plus haute dans la hiérarchie (partage
des attributs, opérations, contraintes...)

PR. SOUKAINA MJAHED 112

 UML – Diagramme de classes
❑ Hiérarchie de classes : Regrouper les classes partageant des attributs et des opérations et les
organiser en arborescence
❑ Classe abstraite : Classe sans instance, seulement une base pour classes héritées Notation : nom
de la classe en italique (ou stéréotype « abstract »)

PR. SOUKAINA MJAHED 113

 UML – Diagramme de classes
❑ Classe-association : Permet de paramétrer une association entre deux classes par une classe.
❑ Instance unique de la classe-association pour chaque lien entre objets

PR. SOUKAINA MJAHED 114

 UML – Diagramme de classes
❑ Classe-association : Permet de paramétrer une association entre deux classes par une classe.
❑ Instance unique de la classe-association pour chaque lien entre objets
❑ Équivalence en termes de classes et d'associations :

PR. SOUKAINA MJAHED 115

 UML – Diagramme de classes
❑ Exercice d’application
Une bibliothèque municipale souhaite informatiser la gestion de l’emprunt de livres.
Un usager peut :
• Consulter le catalogue en ligne.
• S’inscrire comme membre.
• Emprunter un livre s’il est membre et que le livre est disponible.
• Retourner un livre.
Un bibliothécaire peut :
• Enregistrer l’inscription d’un nouvel usager.
• Enregistrer les emprunts et les retours de livres.
• Mettre à jour le catalogue (ajouter/supprimer des livres).

• Réaliser le diagramme de classes relatif à cet énoncé.

PR. SOUKAINA MJAHED 116