5.5 KiB
| title | date | tags | categories | |||||
|---|---|---|---|---|---|---|---|---|
| PdP: Représentations et présentations | 2024-01-31 |
|
|
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. 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.