views:

267

answers:

3

Suppose I would like to depict data flow between two servers in Visio.

I have boxes to represent servers and arrows to represent communication / data flow.

In this situation:

  • Server A always initiates connections to Server B.
  • Server A reads from server B, but does not write.

How would this be depicted? Which way would the arrows point?

Is there are convention used for arrows connecting these two servers? Is it based on...

  • Which server initiates connections to the other
  • Whether the operation is read, write, or both
A: 

Well, that really depends on the purpose of the diagram :-)

We deal mostly with network infrastructure so we would use the arrows pointing in the direction of session establishment - this would assist us in defining firewall rules for all our zones.

But, if you're diagramming an application and you need to know data flow for the application, you'd use arrows depicting the flow of data, not session estasblishment.

I would think that, as long as the chart made it clear what you were representing, you could go either way. You could even do a hybrid solution with, for example, the arrows at the end showing data flow while you have a smaller arrow in the middle showing direction of session establishment - as long as you still document, on the chart, what it means.

No idea if Visio has that sort of arrow line - I'd just use two of them, one overlapping the other.

paxdiablo
A: 

its unidirectional, so i would think you should just put a straight line , then explain in a note that the connection is always made from A and A always only reads from B.

I often see arrows when there is only 1 way flow of data. However, its really up to you, as long as you document.

Here is an alternative i have seen before.

use an arrow from B to A but in a different color to indicate the special clause that A initiates the connection, not B.

Andrew Keith
A: 

It depends on what you're trying to show, and the level of detail you need.

Often you'll find that an arrow can be to easily misinterpreted on it's own, unless you're working in something formal like UML. The best way to get around that and avoid ambiguity is to put a notes or labels on the diagram that explain the detail.

Another approach is to ask yourself if you're using the correct diagram - the point is maybe you need more than one diagram?

UML has specific types of diagram for different views / scenarios; a sequence diagram, activity diagrams etc. check out: http://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/diagrams.htm for starters, and of course there's heaps of other useful info out on the web.

Adrian K