Craig:

A context diagram is a special type of data flow diagram in which the systems is represented as just one big function.   Most data flow diagrams have between 5 to 7 functions on them.   A context diagram does not offer the decomposition that regular dfd's do.

It is a common belief that dfd's are system centric, while use cases are actor centric.   However, dfd's can be drawn from any view point, including from "just as the user experiences it".    The profound difference between use cases and dfd's is that only the latter actually guides the analyst through the discover process. 

Tony

Chris:

Thanks for pointing out that data flow diagrams can be very end-user centric.  (Note: they were invented about 75 years before the computer was - so they have to be user-centric.)

However, Chris, I must point out that forced, artificial partitioning is not related to functional decomposition.  (Nor is it related to perspective.)  A single non-leveled diagram can be loaded with forced, artificial partitioning.   Forced artificial partitioning relates to how the functions on a single diagram are determined.  Whenever an analyst first draws the circles (ovals) and then trys to connect them, essentially, what he/she is doing is putting what ever functions happen to pop into their head down on paper and then he/she trys to figure out how all those functions interrelate.  As Tom DeMarco points out in "Structured Systems Analysis and Specification", what the analyst is doing here is trying to force fit reality to his/her initial (flawed and incomplete) understanding.  The functional discovery process is derailed.

Compare the above use case way with the data flow diagram way.   As DeMarco described, in creating a data flow diagram, the analyst follows a couple of data flows like flowing rivelets of water that combine and split apart.   When the data flows naturally come together, the analyst has discovered an essential function.   Same thing when the data flows split apart.   Note how the method actually prods the analyst through the discovery process - use cases do not do this.

The Lost Secret Of  Business Analysis is that, especially for larger systems, it is necessary to avoid playing the old "connect-the-boxes" game and to, instead, employ a technique that naturally flushes out all essential functionality.   When I learned data flow diagraming back in the mid 80's, all the analysts in my department had avoidance of forced, artiticial partitioning in the forefrount of their minds.  Today, almost nobody - managers, top-level academics, etc. is even familiar with it.

Tony

Hi Adrian:

You are right that alot of abritrary partitioning is done using Use Case.  But, just as important, with use cases, where is the lithmus test of completedness? - how does an analyst know when he/she has covered all bases? 

Where forced, artifical partitioning was drilled into my head was when I took the Yourdon course on data flow diagramming.   Indeed, the very introduction to the course revolved around such.   The best book to discuss the topic is Tom DeMarco's "Structured Systems Analysis and Specification" (this Yourdon book goes back to the 70's).  I will get my copy and dig up a couple of refs.  

I am currently leading cross-project integration efforts.  Some of these projects utilized UML techniques (esp Use Casees, Activity Diagrams, and Sequence Diagrams).    I start by proceed in as-top-down a fashion as possible using data flow diagrams.  At lower levels, I sometimes "feather in" existing UML diagrams into my data flow diagrams. 

About Activity Diagrams:  They are often described as being "kind of like " data flow diagrams.   That may be true, but, like Use Cases, Activity Diagrams are based upon the age-old "connect-the-boxes" (i.e., forced, artificial partitioning) approach.  

Tony