Au Moyen-Âge (milieu des années 1980), j'utilisais Diagrammes de flux de données de Analyse structurée un bon nombre d'entre eux, et les ont trouvés très utiles.
Mon employeur actuel adore UML. J'utilise normalement BOUML, qui ne fait pas de dessins non-UML.
Quel est le dessin UML qui correspond au diagramme de flux de données ?
S'il n'y en a pas, quel est le diagramme UML recommandé pour présenter les données correspondantes ?
La chose la plus proche est probablement le diagramme d'activités . Ce n'est pas tout à fait la même chose ; plus influencé par le diagramme de flux que par le DFD. Cependant, vous pouvez faire certaines des choses utiles dans les DFD, par exemple, les AD supportent la concurrence et différencient le flux de contrôle du flux de données.
Plus de détails sur les comparaisons et les différences dans cette question .
[pour info, j'utilise toujours les DFD : ils sont plus simples et plus élégants dans de nombreuses circonstances].
hth.
UML 2 a un très bon analogue à un diagramme de flux de données : le "diagramme de flux d'information".
Les diagrammes de flux d'informations sont expliqués ici : https://web.archive.org/web/20121118061853/http://www.uml-diagrams.org/information-flow-diagrams.html
Notez que UML 2.5 a des flux d'information et des éléments d'information, mais le terme "diagramme de flux d'information" ne fait pas partie de la taxonomie officielle des diagrammes UML 2.5. Donc, formellement, il suffit de créer un diagramme de classes ou de composants avec beaucoup de flux d'informations pour obtenir votre "diagramme de flux d'informations". Je fais cela tout le temps, en utilisant les éléments d'information d'UML pour représenter mes données.
Il n'existe pas de modèle équivalent en OOD. Les DFD mettent l'accent sur la séparation des données et des fonctions. C'est très utile lorsque l'on travaille de manière procédurale. Les DFD s'adaptent beaucoup mieux que la DOO. Si vous essayez de vous adapter (à la vision du monde) en utilisant la DOO, vous finissez par utiliser des diagrammes de cas d'utilisation, qui sont utiles pour capturer les essences. J'ai adoré les DFD, ils sont d'un niveau tellement élevé, et pourtant ils peuvent être étendus en ouvrant une boîte DFD et en l'appelant niveau 1, etc.
Je suis actuellement en train d'apprendre le langage de programmation Go, qui n'utilise pas du tout d'objets et, à certains égards, je pense que la modélisation DFD lui conviendrait bien mieux.
Je suis moi aussi à la recherche d'un schéma qui pourrait faire ce genre de travail. En Go, on utilise intensivement les structs qui sont des types de données de base. Vous pouvez avoir une méthode d'extension primitive qui lui est attachée, ce qui ressemble à du OO, mais en fait, si vous regardez le code de l'Assemblée, cela semble être du sucre syntaxique pour une fonction, dont le premier paramètre est la structure sur laquelle vous souhaitez que la fonction opère.
Mon conseil, c'est que si vous faites du code OO, alors utilisez OOD. Ils sont mieux adaptés et aident à réfléchir à un système. Il faut un certain temps pour se sortir du code procédural, surtout si vous venez de la programmation des années 80/90. Une fois que vous êtes dans la zone de réflexion sur les objets, les méthodes OOD fonctionnent bien. Il ne s'agit pas d'une méthodologie à proprement parler, car il n'y a pas de réponse directe à la question de savoir quelles parties utiliser. Un bon livre à ce sujet est "Object Thinking--David West"... cela aide à penser d'abord aux objets. Une fois que vous avez commencé, il est très difficile de s'arrêter, vous pouvez même, comme certains, finir par être pris au piège dans le royaume des noms, qui est un endroit horrible à être, parce que vous écrivez du code passe-partout sans fin, juste pour que le système soit parfaitement décrit. C'est une forme d'enfer de codage que j'ai évité pendant de nombreuses années.
Si vous codez dans un langage qui autorise le code procédural, ou même un mélange OO/Procédural, vous devez décider de votre paradigme avant de commencer à coder, par exemple dans Python et Object Pascal (Delphi), vous pouvez suivre l'une ou l'autre voie de codage OO ou procédural, mélangeant le code dans un fouillis de paradigmes. Cela déterminera les outils de diagramme à utiliser et la manière dont vous allez analyser le système.
Récemment, des changements ont été apportés à Java et à c# pour fournir des techniques de programmation fonctionnelle. J'ai découvert que ces techniques n'entrent dans aucune des catégories de programmation (OO ou procédurale). Essayer de faire correspondre un code de programmation fonctionnelle à un objet est un cauchemar.
Je suis désolé de ne pas avoir apporté de réponse, mais cela dépend du code que vous écrivez.
Il n'y a pas d'analogie directe, puisque UML met l'accent sur la conception OO alors que la DFD provient de l'analyse et de la conception de systèmes structurés (SSAD). En UML, un certain nombre de diagrammes, en particulier ceux de la section with les diagrammes d'interaction ont des caractéristiques qui pourraient modéliser des éléments du flux et du traitement des données. Un diagramme de communication peut être utilisé pour refléter la plupart des aspects d'un DFD en général, tandis qu'un diagramme de séquence peut modéliser des séquences spécifiques de flux. Si vous voulez suggérer la sémantique d'un DFD, vous pouvez utiliser des objets stéréotypés pour le traitement et le stockage des données, et utiliser des acteurs pour les entités externes.
Il est intéressant de noter que Sparx Systems Enterprise Architect, bien qu'il s'agisse principalement d'un outil UML, inclut le DFD comme extension.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
