Alternative to DFD diagram with UML

[Modesto Vega]

Could anybody think/suggest a UML 2 alternative to a DFD?

Please keep in mind that I am trying to draw data flows between systems, so any alternative must be able to represent in a single diagram: functions/processes  and systems/data stores with data entities/classes as a bonus.

[qwerty]

AFAIK the DFD was developed in times when it was usual to transfer large file volumes between systems on a (say) daily basis. Current systems rely on much better network structure and exchange messages instead. Does DFD still make sense?

q.

[Modesto Vega]

Hence the question but not really sure of how much things have changed in reality between the inception of DFD and now.

How would you propose to represent in a single diagram (A3) a data flow which passes through at least 12 systems and goes from being a replenishment or purchase order to being an invoice?

I am looking for alternatives to put together an architectural data flow diagram which is a tad complicated. A DFD has done most of the trick.

Open to suggestions.

[qwerty]

Depends on your system. If you still have "data flowing" stick with DFD. If it's more messages think of SOA profiles.

q.

[Modesto Vega]

Where can I find SOA profiles in EA? Under SOMF?

[qwerty]

This or SoaML. There are also profile in the "world outside" (ICMB or the like had one).

q.

[Sunshine]

Ah yes I remember DFD's from about 25 years ago. Processes, Data Stores, Data flow, event flows. Now its Components, Objects, Messages and information flow.
Depending on the level on which you want to go you could use
Component diagram where components represent systems and show information flow between them. I used to use this for showing how all the systems in the enterprise passed information to one another. I now use ArchiMate for that.

Or alternatively if you wan to show whats going on within a system you could use communication or interaction diagrams to show how the objects within the system talk with each other by passing messages.

[Modesto Vega]

Ah yes I remember DFD's from about 25 years ago. Processes, Data Stores, Data flow, event flows. Now its Components, Objects, Messages and information flow.

Good old DFDs, almost had an attack of nostalgia  .

Depending on the level on which you want to go you could use
Component diagram where components represent systems and show information flow between them. I used to use this for showing how all the systems in the enterprise passed information to one another. I now use ArchiMate for that.

The diagram would eventually have 2 levels. Currently working on the top, less detailed, level. I am curious about how do you use ArchiMate for this. How do you represent a system in ArchiMate? Are you using ArchiMate 2.0?

[qwerty]

Forgot about ArchiMate. It's definitely easier to handle than any SOA profile. There's also some free source detailing it (I still can't recall the name of the guy from the Netherlands/Belgium but it was mentioned here on the forum and one of the Sparxian helped out with the link).

q.

P.S. http://www.sparxsystems.com/cgi-bin/yabb/YaBB.cgi?num=1410467081/2#2

[Nick B]

UML is a set of diagrams/templates to assist/document the design process rather than a methodology itself - so much like the pirate code "more what you'd call guidelines than actual rules.".

If what you need is "like" a DFD, why aren't you just using a DFD? Is someone stopping you, or is it just the shame of using something so ancient, regardless of whether it does what you want or not

[Modesto Vega]

If what you need is "like" a DFD, why aren't you just using a DFD? Is someone stopping you, or is it just the shame of using something so ancient, regardless of whether it does what you want or not

No problem at all using DFD and have a good DFD diagram in place I am realtively happy with.

It is more a question of not being able to capture as much detail in a single diagram as I would like to capture. In particular, I would like to capture all the data entities involved for a partticular flow and a particular system - e.g., to put together a purchase order I need at least 2 data entities: a list of products and a purchase order. At the moment the high level DFD has only one Data Store per system.

[Nick B]

Re: " to put together a purchase order I need at least 2 data entities: a list of products and a purchase order. At the moment the high level DFD has only one Data Store per system"

If I understand your problem ...

... what I would do is decompose the "Create Purchase Order" process ("New Child Diagram" => "Composite Structure Diagram"), and on that child diagram include your two data stores, together with any sub-processes (e.g. Verify PO info ->Derive PO number ->Store PO->send PO Notification); you could have all this on the top level diagram, but they tend to get a bit busy if you do that! DFDs were designed to be decomposed.

[Chris Armstrong]

I'd suggest using an information flow for this (which is considered an "Auxillary Construct" in UML 2): http://www.sparxsystems.com/enterprise_architect_user_guide/12.0/standard_uml_models/using_information_flows.html

Per UML 2.4.1: "The InformationFlows package provides mechanisms for specifying the exchange of information between entities of a
system at a high level of abstraction."

[AndyJ]

I typically put information flows on a deployment diagram to explain that sort of information.

Most complex recent example had systems on different networks, and boundaries to identify those networks.

Firewalls were represented as devices, nodes and components that overlapped boundaries.

I'm not sure that was technically sound modelling, but it was sufficient for explaining the complexity to the users.

[Modesto Vega]

Thanks to everybody for their replies, I have now found an alternative I am happy with: BPMN 2.0.

I has the concepts of Data Object and Data Store (good for a database), and Pools and Lanes which are good to partition a process.