InformationFlow between Actor and UC

[PDC]

I seem to remember ages ago seeing Something Somewhere that said it is incorrect to link Actors to UCs with InformationFlows that describe the information flowing in/out of that UC (i.e. the Actor is using a system via that UC and the UC diagram also specifies the data flowing in/out of the system's Behaviours).
However, para 20.2.1.5 "InformationFlow > Constraints" of the UML spec states "The sources and targets of the information flow can only be one of the following kind: Actor... UseCase...", which would seem to imply that it is permitted to attach InformationFlows to the Actor-UC Associations on a UC diagram.

Does anyone have any thoughts on this? Is it permitted/forbidden/unrecommended?

If nothing else I guess that maybe it is 'permitted' but only when it is technically correct to do so (i.e. when the Actor is actually the entity that literally sends that InformationItem into the system or receives from it).

[shimon]

Hi,
We do have information flows from the Actor to the Use Case and vice-versa.
Shimon

[Geert Bellekens]

Information flows don't have many constraints, so I guess it would be technically valid to model informationflows between use cases and actors.

It's a bit unconventional, but as long as you have a clear documented purpose for this type of relation, I would not hesitate. (even if it would have been against UML syntax)

Geert

[PDC]

Thanks both, appreciate the input.

It's a bit unconventional, but as long as you have a clear documented purpose for this type of relation, I would not hesitate.

Yes this is increasingly my attitude to a lot of modelling to be honest - as long as something has a documented purpose (like an internal company style guide or set of rules) then it is a lot easier to justify bending rules... depends on the tool a little bit as well I guess.
It's also a challenge I've found when working with companies/programmes that are moving from documented design into a modelling environment. If people/businesses are less experienced in modelling (and I am by no means a veteran) then little 'features' like this one seem to creep in because they make sense to the person who drew the diagram. Sometimes it's easier to document the oddity rather than educate an entire team on every specificity of the UML & SysML specs (as the idiom goes: 'ask for forgiveness rather than permission'). But then again, I'm also naturally quite pedantic about syntax and am more inclined to try to educate myself directly from the specs whilst the business just wants a model that looks "graphically ok" and is "acceptable by a customer".