#11 FFDS Sample : Unconnected Pin Region of Interest in AD "Detect and report fire"

[Alexander Haarer]

1. In the FFDS Sample in the AD "Detect and report fire" is an Action ":Request FF data", which has an unconnected Pin.

I dont think it was left open by accident, but I assume, that the Function is meant to take some pre-set Region of Interest which was configured previously (possibly in an other Use Case not shown in the Sample, or is a Preset of the SOI configured on system Deployment).

In both cases it would be nice to show a modeling solution to this kind of problems in the Sample.

The Pattern, that an AD cannot and should not show each and every Data source as object flow that is needed for a Function is useful. But leaving the pin just open leaves a bad feeling.

It should either be connected to a pre condition of the surrounding use case, or tied to a system state variable - possibly both.

1. In the same Diagram, the action ":Analyse FF Data" has an unconnected pin named "satellite data". Is this possibly a leftover ? It should be connected or deleted.

2. The naming of ":Retrieve FF Data" and ":Request FF Data" makes me cry :)
   The flows from "Request FF Data" suggest, that there is happening some sensor source selection, according to the Region of Interest, and that suggests, that Retrieve FF Data does some Filtering according to this source selection of the input streams.

The names "Request" and "Retrieve" suggest caller / callee patterns wich should not be applied at functional level (IMHO) . Additionally they cause an uneasy feeling considering the streaming characteristic of the input pins.

I'd like to suggest names like "Filter according to source selection" and "Select sources according to region of interest". If i guessed wrong, then please explain what the the actions are meant to achieve.

[Tim Weilkiens]

The "Region of Interest" pin is intentionally not connected. Actually, according to SysML, it should show an incoming arrow in the rectangle, so that you can see that it is an InputPin. However, it is not shown in Cameo.

The value is not a parameter of the activity, but should be read from a system configuration. This kind of modeling occurs very often. You are right that it is not very clear if you just use an unconnected pin.

As a pragmatic modeling pattern, I modeled OpaqueActions that read the value from the system configuration. As long as the model is only descriptive, the language of the OpaqueAction can be English. See attachment for an example.

The same applies to other unrelated pins in the activity.

The Satellite data pin was unconnected by mistake. I have corrected that. OutputPin and InputPin were both there, only the object flow was missing.

The idea of request/retrieve actions is that the request action contains the functionality to determine which data to read. The retrieve action contains the input and output functions to perform it. That means, request contains more domain logic and retrieve more technical logic. This separation of I/O functionality is a common pattern in use case analysis and a good groundwork for the functional architecture or FAS method.

I am open to better names for the actions. Filter and Select don't really hit the mark from my point of view.