---
title: "PdP: Représentations et présentations"
date: 2024-01-31
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. Ils permettent donc de faire du paralléllisme
et de la synchronisation.

### Diagrammes de machines à états

Les sommets représentent des états et les flèches les transitions. Ils
fonctionnent pour les scénarios mais il faut faire attention **de bien nommer
les états**.

### diagrammes de deploiement

Représente l'utilisation des ressources physiques, la manières dont les
composants sont répatis et les liens entre eux. Les éléments constitutif de ces
diagrammes sont les nœuds, les artefacts, composants et associations.

## Cahier d'analyse des besoins

C'est un document spécifique pour représenter l'analyse des besoins d'un
logiciel. Il est cependant difficile de décrire un standard pour la
représentation des besoins d'un logiciel.


