Diagramme de flux de données
Représente le modèle logique du système d’information.
Symboles utilisés
Cercle ou rectangle aux coins arrondis représente le traitement/processus
Flèche représente le flux de données
Rectangle ouvert à droite représente un dépôt de données
Rectangle complet représente la source, destination ou les deux, ou un agent externe
Règles
Un traitement reçoit toujours au moins un flux entrant et produit toujours au moins un flux sortant.
Chaque flux passe par un traitement.
Un flux de données doit être identifié par un nom unique.
Une entité externe est une personne, groupe ou organisation qui fournit ou reçoit de l’information.
Niveaux
On distingue plusieurs niveaux de diagramme de flux de données (DFD).
Diagramme de contexte :
Contient un seul traitement
Identifie toutes les sources et destinations.
Identifie tous les flux de données entrant et sortant des sources et destinations.
Normalement sans dépôt de données.
DFD de niveau 1 :
C’est une explosion du diagramme de contexte : on décompose les traitement du diagramme de contexte pour décrire les détails de ce traitement.
Tous les flux de données qu’un traitement reçoit ou produit doivent être présents au niveau inférieur lors de la décomposition.
Les traitement de ce niveau sont numérotés 1, 2, 3, …
Les symboles d’une source, destination ou dépôt de données peuvent être dupliqués.
DFD de niveau 2 :
Avantages du DFD
Il est simple parce qu’il ne comporte que quatre symboles;
Il offre la possibilité de présenter des activités parallèles;
Il est indépendant du matériel utilisé pour traiter les données;
Il permet d’impliquer les utilisateurs qui en examinant les diagrammes peuvent détecter rapidement des problèmes et exprimer leurs besoins;
Avec l’approche « Top-down » ou descendante, il permet d’isoler certains domaines de l’entreprise et de les étudier plus en détail.
Étapes de l'élaboration du DFD
Identifiez les entités externes concernées, les inputs et les outputs; Les flux de données sont créés lorsqu’il se passe un événement à l’extérieur. Par exemple, un client achète un article, un étudiant demande de s’inscrire à un cours, un camion livre la marchandise, un fournisseur envoie une facture à payer, la direction demande un rapport des ventes.
Identifiez les différentes étapes qui sont nécessaires à l’exécution de l’activité; Pour déterminer les étapes, suivez le cheminement d’une activité et demandez : « Que se passera-t-il après pour cette étape de l’activité? ». Au fur et à mesure que la liste augmente, essayez de trouver les tâches qui concernent uniquement les procédures de traitement d’erreurs et d’exceptions.
Identifiez, pour chacune de ces étapes, les données nécessaires et les informations produites, c’est-à-dire les flux de données qui entrent et ceux qui sortent;
Prenez une grande feuille de papier et dessinez à main levée le premier brouillon; Commencez par dessiner le cadre en laissant de l’espace de chaque côté pour les entités externes. Donnez un nom à cette application comme GÉRER LES COMPTES-CLIENTS. À l’extérieur du cadre, sur le côté gauche, dessinez l’entité externe (par exemple CLIENTS). Dessinez les différentes étapes de l’application, les flux de données et les stockages de données nécessaires. Essayez de faire apparaître tout, sauf les erreurs, les exceptions et les décisions. Celles-ci apparaissent dans les processus de niveau inférieur
Faites-vous à l’idée que vous devrez dessiner au moins trois (3) brouillons du diagramme de flux de données de niveau supérieur; Ne vous tracassez pas si le premier brouillon est un fouillis désespérant. On peut en tirer quelque chose.
Vérifiez votre premier brouillon de DFD avec vos listes d’entrées et de sorties pour vous assurer que vous avez tout représenté sauf bien entendu les cas d’erreurs ou d’exceptions; N’oubliez pas qu’il faut mettre à jour tous les dépôts de données.
Maintenant élaborez un second brouillon plus clair avec le minimum d’intersections de traits de flux de données;
Validez le cheminement de votre second brouillon avec un utilisateur du système d’information et notez tout changement qui résulte de cet examen;
À partir de cette troisième version du DFD, éclatez en processus de niveau inférieur chaque activité de traitement qui nécessite un éclatement;
Lorsque votre modèle sera conforme au système d’information de l’organisation, cette dernière version sera prête à être saisie à l’ordinateur par un logiciel spécialisé dans la conception des diagrammes.
Ce document pourra être agrandi et sera une aide précieuse pour la présentation à toute personne qui est concernée par le système d’information (Opération, conception, entretien, administration).
Règles de développement des DFD
Travaillez de haut en bas, c’est-à-dire du niveau supérieur au niveau inférieur;
Pour les processus, mettez des verbes d’action à l’infinitif;
Un traitement est toujours numéroté. Cette numérotation ne correspond pas nécessairement à l’ordre dans lequel les tâches sont effectuées, mais sert à identifier chaque étape du traitement;
Ne mettez pas plus que huit (8) processus sur un même diagramme;
N’ajoutez des contrôles que sur les diagrammes de niveau inférieur;
Tous les traitements d’un DFD doivent être de même niveau;
La vigilance s’impose en ce qui a trait aux noms des flux d’un niveau à l’autre. Le même flux de données, quel que soit le DFD où il se situe, doit avoir la même étiquette;
Tous les flux entrants d’un processus de niveau supérieur doivent aussi être des flux entrants de ce processus éclaté. De la même façon, tous les flux sortants d’un processus de niveau supérieur doivent aussi être des flux sortants de ce processus éclaté; Il faut maintenir une certaine unité et cohérence entre les différents niveaux d’un DFD.
Le nom du flux en sortie doit être différent du nom du flux en entrée, puisqu’un traitement doit obligatoirement effectuer une transformation aux données;
Un flux de données provient soit d’une entité externe, soit d’un dépôt, soit d’un traitement et se dirige vers l’une de ces trois destinations. Cependant un traitement est toujours impliqué soit comme source soit comme destination d’un flux de données;
Les entités et les dépôts peuvent être répétés plus d’une fois sur un même diagramme;
Chaque flux de données doit recevoir un nom sans exception;
Deux flux de données qui ont une structure de données différentes ne peuvent avoir le même nom;
A chaque traitement que l’on n’a pas fait exploser doit correspondre une fiche logique de traitement dans le dictionnaire de système.
Dictionnaire des données ou dictionnaire système
Un dictionnaire de données (aussi appelé dictionnaire de système) doit contenir les définitions de toutes les composantes constituant les modèles d’un système d’information. Les deux modèles de l’approche classique sont le diagramme de flux de données (DFD) et le diagramme entité-relation (DER). D’autres modèles peuvent aussi être utilisés, mais le DFD et le DER sont les plus utilisés.
Dans un dictionnaire de données, chaque processus de niveau inférieur doit être décrit en détail. En outre, l’analyste doit définir chaque flux et chaque dépôt de données reliés à ces processus, en termes de structures et d’éléments de données. Enfin, l’analyste doit aussi décrire chacun de ces éléments de données.
Construire un dictionnaire de données consiste à identifier chaque composante, lui donner un nom significatif, la définir et l’organiser pour pouvoir facilement y accéder.
Les diagrammes de flux de données ne décrivent pas complètement le sujet étudié. C’est pourquoi il est primordial de fournir des informations supplémentaires sur le système. Le dictionnaire de données fournit ces informations supplémentaires.
L’intérêt d’un dictionnaire de données comme outil de développement dépend de l’utilisation que les autres outils de développement peuvent faire des définitions qui y sont emmagasinées. Si le dictionnaire est bien conçu et régulièrement mis à jour, les définitions qui y sont emmagasinées sont directement utilisées par le système d’information lors de son exploitation. Le dictionnaire devient alors dynamique.
Enfin, il aide l’analyste à déterminer les besoins du système. Il sert également à la conception du système. Par exemple, si l’analyste veut connaître le nombre de caractères d’une donnée ou encore quels sont les différents noms d’une donnée et où elle est utilisée, il devrait trouver la réponse dans un bon dictionnaire de données.
Éléments, structures, flux et dépôts de données
Dans un DFD, nous avons donné des noms à des flux et à des dépôts de données. Mais que signifie réellement ces noms? Par exemple, que voulons nous dire par commande? Dans un dictionnaire, on pourrait expliquer le flux de données commande par la structure de données suivante :
COMMANDE :
Détails commande
Numéro de la commande
Date de la commande
Détails client
Nom de l’organisme
Personne responsable
Prénom
Nom
Téléphone
Indicatif régional
Numéro
Poste
Adresse d’expédition
Rue
Ville
Province
Code postal
Adresse de facturation
Rue
Ville
Province
Code postal
Détails livre
Nom de l’auteur
Titre
ISBN
Nom de l’éditeur
Linsting ci-haut → Définition d’un flux de données COMMANDE dans un dictionnaire de données.
Définitions
Structures de données → Les structures de données sont composées d’éléments de données ou d’autres structures de données ou d’un mélange des deux.
Élément de données → Un élément de données est la plus petite unité qui ne se décompose plus.
Les flux de données sont des chemins le long desquels les structures de données voyagent. Ce sont des structures en mouvement.
Les dépôts de données sont des endroits où les structures de données sont conservées jusqu’à leur utilisation. Ce sont des structures de données au repos.
Contenu d’un dictionnaire de données
Les processus
Les flux de données
Les dépôts de données
Les structures de données
Les éléments de données
Les entités externes (sources et destinations, ou agents externes)
Un glossaire
Chaque définition est présentée sous la forme d’une fiche descriptive. Examinons ces composantes pour voir ce que nous désirerions enregistrer sur chacune d’elles. Cela nous donnera des éléments de base pour évaluer n’importe quel dictionnaire de données ou pour organiser le nôtre.
Les processus
Non seulement les flux et les dépôts de données doivent être définis, mais aussi la logique des processus qui transforment ces données. Chaque processus de niveau inférieur doit être décrit en détail. Par exemple, que voulons-nous dire par Vérifier le montant de la facture du processus 2.4? Les méthodes utilisées pour décrire cette logique est :
Voici quelques exemples de description de la logique d’un processus.
Exemple 1 : Vérifier la solvabilité du client
Retrouver historique des paiements.
Si nouveau client
Envoyer demande de paiement d’avance
Si client régulier (2 cmdes par mois en moyenne)
Expédier, sauf si dette de plus de deux mois
Pour les clients connus qui ne sont pas réguliers
Expédier, sauf s’ils doivent quelque chose
Exemple 2 : Enregistrer les informations du client
Demander si le client possède un compte (ou a déjà placé une commande)
Si le client possède un compte, alors
Demander les informations d’identification
Interroger la base de données avec les informations d’identification
Copier les données de la réponse à l’interrogation dans Commande
Sinon
Créer un enregistrement vide de client dans la base de données
Demander au client les attributs du client
Remplir l’enregistrement vides de client avec les attributs du client
Fin Si
Demander au client les informations sur la commande pour le premier article
Tant que sont exécutés d’autres articles pour la commande
Ajouter les informations sur la commande dans Commande
Fin Tant que
F1 | Nouvelle commande |
F2 | Détails client |
F3 | Nouveau client |
F4 | Détails sur la commande |
Exemple d'un DFD