Tony,
The trouble with Data Flow Diagrams, and I wrote them for about 15 years until UML came along, is that they force you to look at everything from the point of view of data. I find that restrictive and often too low level to properly define the system I'm trying to model from a business point of view. The thing is, you can actually use an activity diagram to write something that is effectively a data flow diagram but data flow diagrams themselves are too restrictive. Its start with data or bust. If you start and end with data you can easily miss the overall business picture. You need a tool that allows you to model based on the business problem you're faced with.
btw, you could quite easily define the activities or nodes or whatever they are called on your DFD in a use case. Open your mind and have a go :-)
You say "processes can occur in any order, therefore, there is no sequence, which means that one can not use activity diagrams" That's how I earn my pay by having the experience and the ability to define the business process at the correct level and in the correct sequence.
We are never going to agree of course
Kimbo
Kimbo:
You may want to refer to the BABOK 2.0. It is essentially a functional spec on how to create a functional spec. The authors state that the processes within the scope of the document (i.e., the procsses that a BA performs) can occur in occur in any order. So what diagramatical technique did they choose? Answer: Input/process/output diagrams. Data flow diagrams are integrated input/process/output diagrams.
The authors of the BABOK 2.0 did not choose a sequence based modeling technique, such as Activity Diagrams, because there is no set sequence. This happens alot with manual and/or automated systems. And large scale systems at the big picture level are always non-sequential. Now they could have choose Use Cases as they are non-sequenced based, but they wanted to show the inputs and outputs on the diagrams. Unfortunately, they did not utilize a follow-the-flow-of-data-end-to-end approach (the way dfd's are done) and the result is very confusing, but at least they are right in recognizing that systems often don't have a set sequence of processes.
Tony
I haven't read all the BABOK, so I can't comment. Of the bits that I have read I've found cause for disagreement. You obviously have too.
Use cases define a function btw, not a process although I suppose you can argue that it is a lower level process.
Like I said before, you can choose an activity diagram or even a BPMN diagram to show the input/process/output type thing you want. The problem I have with DFDs is that is all they do whereas Activity Diagrams and BPMN will do so much more.
I think you have it in reverse: Data flow diagrams can do everything that a BPMN or an Activity Diagram can - and additional essentials. It is part of the Yourdon methodology (probably the most popular DFD method) that, after the BA decomposes downwards to a low even level, he/she then transfers to using a sequence/flow of control technique to nail down that logic. Indeed, I do this all the time. These lower level diagrams can, in addition to sequence, capture timing - or what ever else that is on an Activity or BPMN diagram.
Again, at the big picture level, where there is no definable sequence, we follow the flow of data. At the detail level we capture flow of control/seqence. The additional essential that we can only capture via DFD is a logical, natural partitioning of the system. A logical, natural partitioning is prerequisite for effective decomposition, and effective decompostion is required to handle complexity.
Told you we'd never agree. In my opinion the key is the skill of the BA doing the work. A good BA will come up with a good model regardless of whether they use DFDs or UML / BPMN.
Enjoyed the chat.
brought to you by enabling practitioners & organizations to achieve their goals using: