112 lines
4.8 KiB
Markdown
112 lines
4.8 KiB
Markdown
---
|
|
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 **executables**
|
|
* 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.
|