Paul, Tony and others interested in this thread:

As Paul does, it is helpful to separe Object Flow (Material, People) from Data
Flows and use UML Activity Diagrams for it.

Sequence Diagrams are well suited to show all one wants to show in Data Flow
diagrams. However the processes are identified as Operations within an Object
but not separatrely (in support of encapsulation of OOAD). They also show
timing / sequence information.

Data to be processed, Meta Data, Error Data and Control Data are all of one
kind: DATA, and they may arise concurrently (corret data and erronious data may
be mixed and are separable only by applying validation criteria).
So, using high level DFD's for Data and detaild DFD's for error and control may
be one way of partitioning but may not relate to the way such data occur.

So, it appears that in principle UML Diagrams (with corrections and
enhancements) may be used as effectively as DFD's for modeling systems of
different sizes / complexity. We can examine the cases / documnets to confirm
the same.

Best wishes,

Reaching Hyderabad on July 4th Morning
Mobile 98660 71582 Home 040 6666 9393

Putcha V. Narasimham

--- On Thu, 2/7/09, Paul Oldfield <Paul.Oldfield@...> wrote:


From: Paul Oldfield <Paul.Oldfield@...>
Subject: {Requirements-Engineering} Re: DFD's and corresponding UML Diagrams
To: Requirements-Engineering@yahoogroups.com
Date: Thursday, 2 July, 2009, 2:44 PM








(responding to Tony)
>
> I wrote that the UML diagrams are only appropriate for smallish
> efforts.  Why?
>
> Data flows are considered on the same diagram level as is flow
> of control and sequencing considerations (activity diagrams).

Well, you could try just putting data flows on the diagram,
you don't need to put the control flows on the same diagram.
(I frequently use UML activity diagrams with activities linked
solely by object flows. It seems to work.)

> As Yourdon used to say "If you (the analyst) want to know
> anything, you must not try to know everything - at least
> initially".  That is to say that putting all these things
> together on one level of diagrams, especially for complex
> systems, soon results in diagrams so complex, it is impossible
> to tell what is missing.

So, don't do that.

Paul Oldfield
Capgemini

















See the Web&#39;s breaking stories, chosen by people like you. Check out
Yahoo! Buzz. http://in.buzz.yahoo.com/