Mike,

I"ll look for some examples. UML definitely has elements of data flow diagrams but I believe that UML has it's own syntax and way of doing things. Not that it's bad, sometimes I just find UML to be a bit daunting.

Also I had intended to say in my first sentence that it is a bit like ERD's but with a focus on PROCESSES.

Data flow digrams are basically data, people/entities, and processes.

Greg


>Sounds good. Do you have any links to good examples? Is it useful in UML?
>
>>Data flow diagrams visually describe how data flows through your processes and how data acts with entities. It's somewhat similar to an ERD but with a focus on data.
>>
>>Often my first diagram is a data flow diagram because it helps visualize the people, processes, and data required for a particular business process.
>>
>>Another cool thing about data flow diagrams is they can be exploded to show greater detail.
>>
>>It's also a good diagram to present to executive types because it doesn't concern itself with details that would only be useful to programmers.
>>
>>If I had to choose only one type of diagram to do it would be a data flow diagram because it's less about programming details and more about seeing the big picture and how it relates to employees and business processes.
>>
>>Greg
>>
>>>I'm familiar with flow-charting and ERD (Entity Relationship Diagrams), but what is a Data Flow diagram? I guess the point I'm getting at is this: In other industries, diagrams like blueprints or CAD models are required because they have to move from the virtual to the physical. In software, the "model" could very well be the software, if there was an environment that saw it that way, no?
>>>
>>>>>To do full -cycle projects, flow charting skills are absolutely necessary for an outsider (like me) to specify, plan and schedule a big system. There is no substitute.
>>>>
>>>>Flow charts, AND Data Flow Diagrams .... :-)