Quel est l'analogue UML par rapport au diagramme de flux de données de Structured Analysis?
À l'époque sombre (milieu des années 1980), j'ai utilisé un nombre considérable de diagrammes de flux de données de Structured Analysis et les ai trouvés très utiles.
Mon employeur actuel aime 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é . Ce n'est pas tout à fait pareil plus influencé par l'organigramme que dfd. Cependant: vous pouvez faire certaines choses utiles dans les DFD, par exemple Les AD prennent en charge 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 .
[fwiw, j'utilise toujours les DFD: ils sont plus simples et plus élégants dans de nombreuses circonstances]
hth.
Il n'y a pas de modèle équivalent dans OOD. L'accent mis sur les DFD est constitué de données séparées de la fonction. Ceci est très utile lorsqu’il s’agit d’une procédure. L'échelle de DFD est bien meilleure que celle de OOD. Si vous essayez d'évoluer (vers la vue du monde) à l'aide de OOD, vous finissez par utiliser des diagrammes de cas d'utilisation, qui sont utiles pour capturer des essences. J'ai adoré les DFD, ils sont d'un si haut niveau, et pourtant, ils peuvent être étendus en ouvrant une boîte DFD et en l'appelant le niveau 1, etc.
Je suis actuellement en train d'apprendre le langage de programmation Go, cela n'utilise absolument pas d'objets et, à certains égards, j'estime que la modélisation DFD lui conviendrait beaucoup mieux.
Moi aussi je cherche un schéma qui pourrait faire ce genre de travail. Les structures In Go sont utilisées de manière intensive, qui sont des types de données de base. Vous pouvez y associer une méthode d'extension primitive ressemblant à OO, mais en fait, si vous examinez le code Assembly, il semble être le sucre syntaxique d'une fonction, dont le premier paramètre est la structure sur laquelle vous souhaitez que la fonction opère. .
Mon conseil est que si vous utilisez le code OO, utilisez OOD. Ils cartographient mieux et aident à la réflexion sur un système. Il faut un certain temps pour sortir de votre tête du code procédural, surtout si vous venez de programmes des années 80/90. Une fois dans la zone de réflexion sur les objets, les méthodes OOD fonctionnent bien. Ce n'est pas strictement une méthodologie car il n'y a pas de réponse directe aux parties que vous utilisez, il vous suffit de penser à des objets que je trouve être la partie la plus difficile. Un bon livre à ce sujet est "Object Thinking - David West" ... il est utile de penser d'abord aux objets. Une fois que vous avez démarré, il est très difficile de vous arrêter, vous pouvez même aimer que certains finissent par se retrouver piégés dans le royaume des noms, ce qui est un endroit horrible, car vous écrivez un code de plaque de chaudière sans fin, juste pour que le système soit parfaitement décrit. C'est une forme de codage infernal dont je suis resté à l'écart pendant de nombreuses années.
Si vous codez dans un langage autorisant un code procédural, voire un mélange OO/procédural, vous devez définir votre paradigme avant de commencer à coder. Par exemple, en Python et en Object Pascal (Delphi), vous pouvez choisir l’itinéraire suivant OO ou codage procédural mélangeant le code dans un fouillis de paradigmes. Cela déterminera quels outils de création de diagrammes doivent être utilisés et comment vous allez analyser le système.
Récemment, Java et c # ont évolué pour fournir des techniques de programmation fonctionnelles. Celles que j’ai découvertes n’entrent dans aucune des catégories de programmation (OO ou procédurale). Essayer de mapper un code de programmation fonctionnel dans un objet est un cauchemar.
Je suis désolé de ne pas avoir fourni de réponse, mais cela dépend du code que vous écrivez.
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’information sont expliqués ici: https://web.archive.org/web/20121118061853/http://www.uml-diagrams.org/information-flow-diagrams.html
Notez que UML 2.5 contient des flux d’information et des éléments d’information, mais que le terme "diagramme de flux d’information" ne fait pas partie de la taxonomie officielle du diagramme UML 2.5. Donc formellement, vous créez simplement un diagramme de classes ou de composants avec beaucoup de flux d’informations pour obtenir votre "diagramme de flux d’informations" . Je le fais tout le temps, en utilisant des informations d’information UML pour représenter mes données.
Il n'y a pas d'analogue direct, car UML insiste sur la conception OO alors que DFD provient de l'analyse et de la conception de systèmes structurés (SSAD). Dans UML, un certain nombre de diagrammes, en particulier ceux du groupe avec diagrammes d'interaction , ont des caractéristiques susceptibles de modéliser des éléments de flux et de traitement de 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 souhaitez suggérer une sémantique DFD, vous pouvez utiliser des objets stéréotypés pour le traitement et le stockage de données, ainsi que des acteurs pour les entités externes.
Il convient de noter que Sparx Systems Enterprise Architect, alors qu’un outil UML comprend principalement DFD en tant qu’extension.
Des diagrammes similaires seraient:
- diagramme de flux d'information
- schéma de communication
- diagramme de séquençage
Je considère un diagramme de flux de données comme un diagramme de séquence, dans lequel les producteurs et les consommateurs de données créent, utilisent et détruisent des objets de données au moyen de messages synchrones et/ou asynchrones.