Differences between DFD (Data Flow Diagram) and activity diagram

Question

I need to know this differences in order to undestand how to use them right.

Which are the differences of DFD and Activity diagram?

Solution 1

Actually, it's reasonably logical. You only have to look at the names.

In data flow diagrams, the lines between "boxes" represent data that flows between components of a system. Because these only show the flow of data, they do not give an indication of sequencing.

In activity diagrams, those lines are simply transitions between activities and do not represent data flow at all. They more represent the sequencing of activities and decisions. You can tell from these what order things happen in.

That's a simplistic explanation but should be a good starting point. Further information can be garnered from Wikipedia for DFDs and activity diagrams.

Solution 2

Explicit bias: I'm a DFDs proponent.

@John is correct that Activity diagrams can be used to represent object flow. @pax equally correct they seldom are.

Two big DFD advantages for me:

1. Link to object model. Data stores on a DFD provide a really nice way to link the data produced / consumed to the object model. Very useful for consistency and ensuring your thinking is joined up.

2. They de-emphasise control flow. Far too often designs over-constrain sequencing. Activity diagrams do support concurrency - but it requires the user to (a) remember and (b) use it. So the default is over-serialisation. DFDs don't. They lay bare the real sequence dependencies without any extra effort on the part of the user. Consequently they also make it easier to see causal relationships. If processes a and b both require data input D then it's obvious on the diagram. And hence parallel activity is obvious.

Don't get me wrong - I'm not against Activity diags. Where control flow is the primary consideration I'll use an AD over a DFD. But empirically I'd say I find DFDs a more useful tool in ~70-80% of cases.

Of course, YMMV.

Solution 3

Just a humble opinion from someone who has had to explain processes, both computer and manual, to upper management and CIOs. I have found simple is better and pound-for-pound, DFDs get the message across when I am actually "asked" about details. That being said, the better approach is to always practice the story line and answer in simple answers.

One final comment regarding the age of tools and products. Remember that in most cases these are running the business and work pretty darn good. The adage "you break it (or replace it) and you own it" can make you a hero or make you into a clown.

We have a CIO who wants to replace all mainframe application for the simple reason that they are old technology. One must weigh the consequences and understand if the replacement can handle workload. Have you ever wondered why JPMC, Credit Swiss, Walmart, and Bank of America to name a few still run mainframes?

My apologies for taking it in that direction. Just make sure, whatever analysis tool is used, that all aspects of the replacement are documented including workload, I/O, concurrent users, adoption curve, and scalability.

Comments

[John Saunders]

Hint: don't use Data Flow Diagrams - they're antiquated.

[paxdiablo]

So is C and yet it still has its uses. I wouldn't be so quick to dismiss something just because it's old. Otherwise my wife would have left me years ago :-)

[WeNeedAnswers]

Nothing wrong with DFD's, they work where UML fails. Especially when modelling Threads of execution where data is passed around.

[paxdiablo]

@John, I've never seen them used that way. The lines have always represented control flow rather than data flow. In fact we were taught originally they they were just flowcharts with concurrency :-) Of course I could be wrong in this, it wouldn't be the first time but I would think that the only way to do it would be to still treat it an a control-flow diagram but have certain objects flow with the control.

[bluekeys]

Could you please tell me, as a proponent of DFDs. Do DFDs solely relate to structural programming and activity diagrams object oriented programming? I commonly see it expressed that way on the pipes and was taught SSADM vs the UML and never the 'twain shall meet. Is that true? Must it be?

[sfinnie]

@Dsjbirch: no, there's nothing that inherently ties DFDs to procedural programs - or ADs to OO. OMT and Shlaer-Mellor - OO methods that pre-dated UML - use DFDs to express processing. ADs are really an evolution of flow charts and there's nothing OO about them. The separation between e.g. SSADM and UML is more in the ideals of their proponents. There are some differences but both are founded on a similar set of modelling constructs. You should use whatever works for you and if that means picking aspects of different techniques that's perfectly ok. Hth.

[Anonigan]

@paxdiablo: Activity diagrams might include object flow with object flow edge: uml-diagrams.org/activity-diagrams.html#object-flow-edge