Incorrect error message about number of subprogram paramaters in behavior action statements

[rinsley]

On page 40 and 41 of the behavior annex specification document, it gives an example (BA_example7). In the example, the behavior annex clauses define some transitions with subprogram call statements in their actions. For example:

s2 -[ on dispatch short ]-> s0 { send_result!(local_result) };

If you implement this example in OSATE, you get an error from the AADL editor:

"Invalid number of argument(s) for the subprogram send_result"

The error message seems to think that there should be two parameters for the subprogram call. The subprogram send result has two features: one required data access feature and one out parameter. It appears that the error message is incorrectly counting the output parameter in the required number of input parameters.

[Etienne13]

Dear rinsley,

The error message seems to think that there should be two parameters for the subprogram call.

Yes, this is what the error message reports.

The subprogram send result has two features: one required data access feature and one out parameter.

correct.

It appears that the error message is incorrectly counting the output parameter in the required number of input parameters.

Well, this part of your message requires to pay more attention to the way subprogram features should be used in the BA. The BA plugin assumes that all the parameters (in, out, or inout) and requires data accesses (read-only, write-only, read/write) must be passed as parameters to the behaviour action call.

It is a bit similar to the requirement that all the features of AADL components be connected for an architecture to be considered correct. If I remember correctly, this is the case by default in AADL (and a dedicated property exists to release the constraint).

Just a last comment: the out parameter is not necessarily the return parameter of a function in a programming language, so it might correspond to a parameter in such implementation.

To my understanding, the question is: should all the features of a subprogram have an actual parameter in a subprogram call action? So far the plugin assumes the answer is yes, but the annex is not precise about this. The issue should first be raised as a standardisation issue.

Thanks for your feedback, this question will be raised during the AADL meeting next week.

[Etienne13]

Hello,

the question was raised during the AADL meeting and it appears that it was a mistake in examples of the Behavior Annex. The next release of the BA (to be published soon) will fix this error and the plugin is actually providing the expected error statement about this example.

Etienne.