K:
Graphical use cases do not capture inputs and outputs. The supporting text may attempt to describe such; however, the inputs and outputs need to be modeled or else there is going to be a lack of rigor. That is why we model before we write text - to assure rigor. Agile proponents, on one hand, say: "model just enough"; but, on the other hand, they largely espouse use cases - which fail to ensure that the essentials are incorporated in their graphical models. Go figure?
Regarding activity diagrams, you are right: they do allow incorporation of data flows (called obect flows). My mistake is understandable, as I have never seen one in the real world with data flows.
Sooo, both activity diagrams and BPMN diagrams allow for data flows. But to quote Yourdon: "If you want to get anything done, you must not try to do everything - at least initially". Activity Diagrams and BPMN diagrams involve incorporating flow of control, flow of sequence, and other stuff all on the same diagram as flow of data. Especially for larger scale efforts, the result is predictable: complex diagrams that contain so much stuff, it is impossible to figure out what is missing.
K, let me let you in on a little secret: data flow diagrams attempt to show flow of control, sequence and data flows just like BPMN does. However, they - or at least the popular Yourdon technique - show flow of data on seperate higher-level diagrams, and postpone flow of control and sequence until detail level diagrams are constructed. Reason: to avoid diagrams so complex that it is impossible to figure them out.
Tony Markos