Then of course there is the whole fractal nature of software. As you add more detail, the arrows can flip flop around. Polling in a lower level of a stack can very much be used as a push mechanism. (e.g. USB interrupts are in fact the host polling the device)
This is why communicating architecture is often as hard if not harder than implementing it.
Comments
There is in fact a 3rd: build time dependencies.
Control: Object/module/function A calls object/module/function B.
Data: The call can either push or pull data.
Build dependency: The call can be direct (A depends on B) or indirect through an interface/callback/etc (both A and B depends on the interface).
Ideally every design document includes all 3 as separate diagrams.
Then of course there is the whole fractal nature of software. As you add more detail, the arrows can flip flop around. Polling in a lower level of a stack can very much be used as a push mechanism. (e.g. USB interrupts are in fact the host polling the device)
This is why communicating architecture is often as hard if not harder than implementing it.