Linking Operations to Behaviors via assignment as Method

[RT]

For context, I'm using Cameo System Modeler LTR 19.0 SP3.

I've noticed what seems to be a discrepancy, and I don't know if it's at the SysML level, or in the Cameo implementation of SysML via their plugin. It concerns a lack of synchronicity between the parameters defined on some behavior (activity in my case) and the parameters defined on an operation of a block, and the order in which that definition takes places, which are defined below. 

1.) Create a new Operation on the Block, and immediately add it's Method as a new Behavior (Activity, Interaction, State Machine, Opaque Function). Neither have parameters. As I add Parameters to the Method, parameters are added to the operations. As I add Parameters to the operation, parameters are added to the method. If I add 2 parameters, with the direction = return, the model changes the single existing return to be a inout, and adds the new parameter with direction return. If that return parameter is typed by some block or specialization thereof, that will be listed as the type of the operation itself.

2.) Create a new Operation on the Block, and Immediately add it's Method as an already existing Behavior. If that behavior has any parameters on it, those will automatically become parameters of the operation as well. If a parameter is added to that behavior, it will be added to the operation as well. If it is removed from the behavior it gets removed from the operation. If it is removed from the operation, it is removed from the behavior.

3.) Create a new behavior, and use it to define the method of an existing Operation, which already has parameters, but no method defined. If the behavior has no parameters, the parameters on the operation will be written to the behavior, and they will be 'synchronized' as before.

4.) Define as the method an existing behavior with an existing Operation which DO have matched parameter amounts, types, names, and directions. After assigning the method as the behavior, the names and other definitive properties will change it both place if I change it in the other.

5.) Define as in scenario 4, but without a mismatch in any parameter type, name, number, or direction. The Operation, when associated, will not ADD this new parameter, and neither does the BEHAVIOR add the parameter. It feels like that doesn't mesh with the above behaviors of the tool, and there should be SOME sort of synchronization dialog pop up automatically to force it to occur.

6.) An activity is defined to have 2 RETURN parameters. There are no error thrown. When I set that activity as the method for an operation, there are no errors thrown. But when I run the whole model against all the CSM validation suites, there are "excess return parameters" errors from the UML validation suite (i.e. only should be able to define 1 return param, as a rule that's not well enforced.) and it will also tell you that, as a warning (less intense than an error) that there is broken synchronization between Operation and Behavior. You can select from here a fix method, which brings up a parameter (behavior) to parameter(operation) synchronization dialog. 

Does the above feel like it's inconsistent application of parameter syncronization rules, or is there a known reason that this should be the behavior of any SysML compliant tool?

[Sonali Arora]

Hi,

I have been facing similar issues of parameter synchronisation as well. I am using Eclipse Papyrus. I defined the parameters in a block and was expecting to use the same parameters in an activity associated with that block but unfortunately cannot access the same parameters.

I will revert as soon as I find a solution to this problem.

Sonali

[jozsef bedocs]

Hi RT.  Thank you for this very interesting question. First, I want to be clear about scenarios 4 and 5.  Is 5 supposed to represent a mismatch?  4 states that the existing behavior and existing operation have matched amounts, types, names and directions.  5 states '... as in scenario 4, but without a mismatch ...'  If 5 is a mismatch scenario, then I would expect the assignment to fail and an error notification should occur, because the signatures must match.  

I would suggest that having multiple return values needs further consideration.

In the Software world, I have rarely had to use, or seen the use of, out or inout arguments.  Returning more than one outcome is not considered a best practice in software.  I suggest this to be true for activities as well.  The language allows for activities to contain more than one out parameter for the same reason as for operations; however it should be much less used than is the observed practice.  An activity or operation should have the function and objective of producing a result; the out parameter of an activity should reflect this result.  If an activity does something in the process of producing a result that is used downstream by another process, then the activity can set the value of an attribute on the owning block or class.  Such a practice makes it much easier for non modelers to understand models and makes models easier to maintain.