diff --git a/content/projet_programmation/5_representations/index.md b/content/projet_programmation/5_representations/index.md
new file mode 100644
index 0000000..0b62f54
--- /dev/null
+++ b/content/projet_programmation/5_representations/index.md
@@ -0,0 +1,112 @@
+---
+title: "PdP: Représentations et présentations"
+date: 2024-01-24
+tags: ["besoins", "UML", "developpement logiciel"]
+categories: ["Projet de programmation", "Cours"]
+---
+
+Une longue liste de besoin, même classées de plusieurs manières comme nous
+l'avons vu dans le chapitre précédent, n'est pas toujours claire.
+
+Mais nous pouvons représenter ces besoins sous forme graphique et utiliser les
+avantages de cette représentation (qui peut être partielle, et meme multiple):
+
+ * Clarifier la structure des besoins;
+ * Identifier les liens entre eux;
+ * Synthétiser.
+
+Les représentation peuvent être **multiple** et **formalisées*. Ici encore pas
+besoin de formalisme mais de la **rigueur**. Elles sont aussi appelées **modèles
+systèmes**.
+
+## Les diagrammes de flux de données
+
+C'est un graphe de dépendances entre processus / fonctionnalités (formes
+arrondies), les fichiers (barres) et les données/inputs/outputs (rectangles). 
+Ce type de graphe fonctionne bien pour les scénarios.
+
+Il est tout à fait possible de créer ses propres représentations graphiques mais
+il faut penser **impérativement** à légender. La nature des sommets et des
+arrêtes doit être fixée, décrite et appliquée uniformément.
+
+## UML
+
+Pour *Unified Modeling Language*, c'est un langage de modélisation graphique à
+base de pictogramme. Il sert à représenter, concevoir et documenter beaucoup
+d'aspect d'un logiciel. Nous en sommes actuellement à la version 2.5.1 (2017).
+
+UML Propose 14 type de diagrammes divisés en trois familles:
+
+ * **Les diagrammes de structures**: essentiellements liés aux codes sources
+   pour les paquetages, les classes, les déploiements, les composants ...
+ * **les diagrammes de comportements**: liés à l'exécution (dynamique) des
+   programmes comme l'activité, les cas d'utilisations, les états-transitions.
+   Cette famille comprend aussi les **diagrammes d'interaction**: séquences,
+   communications etc.
+
+**5 diagrammes** sont utiles pour l'expression des besoins. Il existe trois
+modes de programmation:
+
+ * Langage de programmation UML avec étape de compilation qui permet de produire
+   des **executables**
+ * Project director où les diagrammes produits permettent d'être utilisés dans
+   des outils d'aide et de synthèses.
+ * mode esquisse afin d'inclure seulement les éléments principaux sans être
+   obligatoirement exhastifs.
+
+Les diagrammes UML sont utiles pour représenter des ensembles de besoins en
+présentant les différents aspects de manière synthetique sans faire référence à
+une implémentation. Nous pouvons voir:
+
+ * Les diagrammes de comportements comprenant les diagrammes de *cas
+   d'utilisations*, diagrammes de *séquences*, les diagrammes *d'activités*, les
+   diagrammes *de machines à états*;
+ * Les diagrammes de structures: les diagrammes *de déploiement*.
+
+### LEs diagrames de cas d'usages
+
+Modélisent les interactions sympa entre les fonctionnalités proposées par le
+programme et les utilisateurs. Il sont constitués de:
+
+ * **use cases** représentant les fonctionnalités (besoins fonctionnels
+   généraux), il faut les nommer sans pour autant les décrire;
+ * **actors** représentant les utilisateurs et autres élements déclencheurs des
+   cas d'utilisation
+ * **associations** représentant les arrêtes entre nos acteurs et cas
+   d'utilisation.
+
+Les contraines de temps n'ont pas lieu d'êtres ici (enchaînement). Les cas
+d'utilisations sont indépendants et le déclenchement ne se fait que par un seul
+acteur à la fois.
+
+Il est possible d'affiner ces graphes:
+
+ * par des **inclusions** via `include` (arcs pointillés), par exemple
+   relations entre cas d'usage et ses sous-cas;
+ * Par des **extentions** via `extends` (arcs pointillés avec étiquette
+   *extends*), par exemple pour étendre un cas (les étendus ne connaissent pas
+   cesux les étandant)
+ * Par des **généralisations** (arcs pleins et flêches en pointillet)pour les
+   cas d'utilisations précisés en cas *spécifiques* d'utilisation.
+
+Ces diagrammes dont des représentation **simplifiées** de scénarios sans les
+descriptions associés
+
+### Diagrammes de séquences
+
+Modélisents une suite d'interactions entre les éléments avec comme éléments:
+
+ * les **participants**: éléments ou objets associés à une ligne de temps
+   verticale en pointillés afin d'indiquer leur activité;
+ * les **interactions**: requêtes, messages, appels de méthodes envoyés entre
+   les participants dans un ordre déterminés, symbolisés par des arcs
+   étiquettés. Les origines et destinations pointent vers les rectangles des
+   *participants*.
+
+Il precisent et complètent les scénario. chaque diagrammes se focalisent sur un
+cas d'usage / scénario à la fois.
+
+### Diagrammes d'activités
+
+eprésentent une suites d'activités parfois parallèles d'un processus avec des
+possibilités de contrôle de flux.