Un modèle de flux de données est un moyen intuitif de montrer comment un système traite les données. Au niveau analytique, ils devraient être utilisés pour modéliser la façon dont les données sont traitées dans les systèmes existants.
Après la publication du livre de DeMarco Structured Systems Analysis , le modèle de flux de données est devenu de plus en plus largement utilisé dans l’analyse. Ils font partie intégrante de l’approche structurée développée à partir de ce travail. Les symboles utilisés dans ces modèles représentent le traitement des fonctions (rectangles arrondis), le stockage des données (rectangles) et le mouvement des données entre les fonctions (flèches étiquetées).
Pourquoi DFD est-il toujours utile pour le développement de logiciels ?
Bien que la modélisation orientée flux de données soit considérée comme une technologie obsolète par certains ingénieurs en logiciel, elle reste l’un des symboles d’analyse des exigences les plus largement utilisés. Bien que les diagrammes de flux de données (DFD) ne soient pas des parties formelles d’UML, ils peuvent être utilisés pour compléter les diagrammes UML et fournir des informations supplémentaires sur les exigences et les processus du système.
Le modèle de flux de données est précieux car le suivi et l’enregistrement de la façon dont les données liées à un processus particulier se déplacent dans le système aident les analystes à comprendre ce qui se passe. L’avantage des diagrammes de flux de données est que, contrairement à certains autres symboles de modélisation, ils sont simples et intuitifs. Elles peuvent généralement être expliquées aux utilisateurs potentiels du système qui peuvent être impliqués dans l’analyse et la validation des exigences.
Pourquoi DDF ?
DFD représentant graphiquement les fonctions, ou processus, qui capturent, manipulent, stockent et distribuent des données entre un système et son environnement et entre les composants d’un système. La représentation visuelle en fait un bon outil de communication entre l’utilisateur et le concepteur du système. La structure de DFD permet de partir d’une large vue d’ensemble et de l’étendre à une hiérarchie de diagrammes détaillés. DFD a souvent été utilisé pour les raisons suivantes :
- Flux d’informations logique du système
- Détermination des exigences de construction du système physique
- Simplicité de notation
- Établissement des exigences des systèmes manuels et automatisés
DFD est un processus de décomposition descendant
La modélisation des flux de données est un processus « descendant ». Commencez par analyser l’ensemble du processus d’approvisionnement. Les sous-processus sont ensuite analysés selon un mode de décomposition descendant.
DFD peut être utilisé pour modéliser des systèmes ou des logiciels à n’importe quel niveau d’abstraction. Comme mentionné précédemment, DFD peut être divisé en niveaux qui représentent un flux croissant d’informations et de détails fonctionnels. Les numéros de niveau dans DFD sont 0, 1, 2 ou plus. Ici, nous verrons qu’il existe trois niveaux principaux dans le diagramme de flux de données, à savoir le DFD de niveau 0, le DFD de niveau 1 et le DFD de niveau 2.
Diagramme de contexte — Niveaux de DFD
Diagramme de contexte (également connu sous le nom de niveau 0 DFD), il représente l’ensemble des exigences logicielles sous forme de bulle, avec des données d’entrée et de sortie représentées par des flèches d’entrée et de sortie.
Le système est ensuite décomposé en un DFD à plusieurs bulles. Les parties du système représentées par chaque bulle sont ensuite décomposées et enregistrées dans des diagrammes de flux de données de plus en plus détaillés. Ce processus peut être répété aux niveaux nécessaires jusqu’à ce que le programme en cours soit parfaitement compris.
Le nombre d’entrées et de sorties entre les niveaux doit être maintenu, un concept connu sous le nom de nivellement DeMacro. Par conséquent, si la bulle « A » a deux entrées X1 et X2 et une sortie Y, alors le ou les diagrammes de flux de données de sous-niveau représentant le niveau supérieur DFD « A » doivent avoir exactement deux entrées externes et une sortie externe.
Dans le DFD de niveau 1, le diagramme de contexte est décomposé en plusieurs processus. Dans ce niveau, nous mettons en évidence les principales fonctions du système et décomposons le processus de haut niveau du DFD de niveau 0 en sous-processus pour représenter davantage les détails des activités de traitement.
Diagramme de contexte (niveau 0 DFD) — un diagramme de contexte DFD est un diagramme qui représente une vue d’ensemble du système et de son interaction avec le reste du « monde ».
Diagramme de flux de données de niveau 1 – le DFD de niveau 1 fournit une vue plus détaillée du système que le diagramme de contexte en montrant les principaux sous-processus et magasins de données qui composent l’ensemble du système.
Niveau 2 (ou inférieur) - un avantage majeur de la technologie de modélisation des flux de données est que la complexité détaillée des systèmes du monde réel peut être gérée et modélisée à un niveau abstrait grâce à une technologie appelée « nivellement ». Certains éléments de tout diagramme de flux de données peuvent être décomposés (« décomposés ») en un modèle plus détaillé à un niveau inférieur de la hiérarchie
Niveaux DFD — Exemple — Système de commande de nourriture
Niveau 0
Il est également connu sous le nom de diagramme de contexte . Il est conçu pour être une vue abstraite, montrant le système comme un processus unique avec sa relation avec des entités externes.
- Le diagramme de contexte doit tenir sur une page.
- Le nom du processus dans le diagramme de contexte doit être le nom du système d’information.
- Par exemple, système de notation, système de traitement des commandes, système d’enregistrement.
Dans le DFD de niveau 1, le diagramme de contexte est décomposé en plusieurs processus. Dans ce niveau, nous mettons en évidence les principales fonctions du système et décomposons le processus de haut niveau du DFD de niveau 0 en sous-processus pour représenter davantage les détails des activités de traitement.
Niveau 1 — Système de commande de nourriture
Dans le DFD de niveau 1, le diagramme de contexte est décomposé en plusieurs processus. Dans ce niveau, nous mettons en évidence les principales fonctions du système et décomposons le processus de haut niveau du DFD de niveau 0 en sous-processus pour représenter davantage les détails des activités de traitement.
Si un processus avec beaucoup de flux de données relie quelques entités externes, nous pourrions d’abord extraire ce processus particulier et les entités externes associées dans un diagramme séparé similaire à un diagramme de contexte, avant d’affiner le processus dans un niveau distinct de DFD ; et de cette façon, vous pouvez assurer la cohérence entre eux beaucoup plus facilement.
Symboles DFD
Quatre symboles de base sont utilisés pour représenter un diagramme de flux de données.
Traiter
Un processus reçoit des données d’entrée et produit une sortie avec un contenu ou une forme différente. Les processus peuvent être aussi simples que la collecte de données d’entrée et leur enregistrement dans la base de données, ou ils peuvent être complexes comme la production d’un rapport contenant les ventes mensuelles de tous les magasins de détail de la région du nord-ouest.
Chaque processus a un nom qui identifie la fonction qu’il exécute.
Le nom est composé d’un verbe, suivi d’un nom singulier.
Exemple:
- Appliquer le paiement
- Calculer la commission
- Vérifier la commande
Notation DFD
- Un rectangle arrondi représente un processus
- Les processus reçoivent des ID pour un référencement facile
Exemple de processus
Flux de données
Un flux de données est un cheminement des données pour se déplacer d’une partie du système d’information à une autre. Un flux de données peut représenter un seul élément de données tel que l’ID client ou il peut représenter un ensemble d’éléments de données (ou une structure de données).
Exemple:
- Customer_info (LastName, FirstName, SS#, Tel #, etc.)
- Order_info (OrderId, Item#, OrderDate, CustomerID, etc.).
Exemple de flux de données :
Notation
- Les lignes droites avec des flèches entrantes sont le flux de données d’entrée
- Les lignes droites avec des flèches sortantes sont des flux de données de sortie
Notez que:
Étant donné que chaque processus modifie les données d’un formulaire à un autre, au moins un flux de données doit entrer et un flux de données doit quitter chaque symbole de processus.
Magasin de données
Un magasin de données ou un référentiel de données est utilisé dans un diagramme de flux de données pour représenter une situation dans laquelle le système doit conserver des données car un ou plusieurs processus doivent utiliser les données stockées ultérieurement.
Notation
- Les données peuvent être écrites dans le magasin de données, qui est représenté par une flèche sortante
- Les données peuvent être lues à partir d’un magasin de données, qui est représenté par une flèche entrante.
- Exemples : inventaire, comptes clients, commandes et paiements quotidiens.
Exemple de magasin de données
Notez que:
- Un magasin de données doit être connecté à un processus avec un flux de données.
- Chaque magasin de données doit avoir au moins un flux de données d’entrée et au moins un flux de données de sortie (même si le flux de données de sortie est un message de contrôle ou de confirmation).
Entité externe
Une entité externe est une personne, un service, une organisation externe ou un autre système d’information qui fournit des données au système ou reçoit des sorties du système. Les entités externes sont des composants en dehors des limites des systèmes d’information. Ils représentent la façon dont le système d’information interagit avec le monde extérieur.
- Un rectangle représente une entité externe
- Ils fournissent des données ou reçoivent des données
- Ils ne traitent pas les données
Notation
- Un client soumet une commande et reçoit ensuite une facture du système
- Un fournisseur émet une facture
Exemple d’entité externe
Notez que:
- Les entités externes sont également appelées terminateurs car ce sont des origines de données ou des destinations finales.
- Une entité externe doit être connectée à un processus via un flux de données.
Règle de flux de données
L’une des règles de développement de DFD est que tout flux doit commencer et se terminer à une étape de traitement. C’est assez logique, car les données ne peuvent pas se transformer d’elles-mêmes en étant des processus. En utilisant la règle du pouce, il est assez facile d’identifier les flux de données illégaux et de les corriger dans un DFD.
Faux / Correct Description
Une entité ne peut pas fournir de données à une autre entité sans qu’un traitement n’ait eu lieu.
Les données ne peuvent pas passer directement d’une entité à une histoire de données sans être traitées.
Les données ne peuvent pas être transférées directement d’un magasin de données sans être traitées.
Les données ne peuvent pas passer directement d’un magasin de données à un autre sans être traitées.
Autres erreurs fréquemment commises dans DFD
Une deuxième classe d’erreurs DFD survient lorsque les sorties d’une étape de traitement ne correspondent pas à ses entrées et elles peuvent être classées comme :
- Trous noirs — Une étape de traitement peut avoir des flux d’entrée mais pas de flux de sortie.
- Miracles — Une étape de traitement peut avoir des flux de sortie mais pas de flux d’entrée.
- Trous gris — Une étape de traitement peut avoir des sorties supérieures à la somme de ses entrées
Outil UML gratuit
- Créateur de diagramme de flux de données en ligne
- Comment créer un diagramme de flux de données (DFD) ?
- Logiciel de diagramme de flux de données (DFD)