This tip is valid primarily for information systems, less for real-time, embedded-, hardware-oriented or more process-oriented systems.

You will be using the context for discussions with various stakeholders, who will likely have limited modeling skills and limited (or no!) knowledge of UML.

Intuitively, many people understand an arrow between software systems as data flow. (Directed) UML relationships like dependency, association, etc. might be rather confusing for such individuals.

Therefore: within the context, use data flows by reversing the direction of the usual dependency- or method-/service call arrows from UML.

Note: this advice is controversial in some teams, because we so explicitely do not comply with the standard UML notation, and also doing that only in the context. However, we found that data flows are often easier to communicate with (non-technical) stakeholders.

For the formalists among you: use the normal, dotted UML dependency arrow and annotate it with the stereotype « flow » to indicate it as data flow and not as a control flow.

For less puristic UML users: invent a new arrow (e.g., solid line with arrowhead) and declare it - as suggested above - in the legend as data flow. IT veterans recognize here the the good old context diagrams from the structured analysis.