CallBehaviorAction versus CallOperationAction in Practical SysML Book

[mse]

There is a paragraph in the book Practical SysML that I do not understand and I would like to implement it in EA. Here is the text:

The action in the ESSactivity partition in the activity diagram can be a call operation action or a call behavior action. The call operation action calls an operation of the block. This method of the operation can be an activity. Alternatively, the action can be a call behavior action that calls an activity that is allocated to the ESS block. For this example, call behavior actions are used, but the call behavior actions are allocated to operations of the block with the same name. The activity that is called by the call behavior action is allocated to the block. This hybrid approach enables the operations to be used as a proxy for the actions, which can then be inherited and redefined.

I get the impression that the author might favor the call behavior option in order to redefine operations later if needed. That might be useful for me since we do lots of variants of a product.

Now the hard part. How do you do this in EA? I would have a block ESS, then have operations in that blocks' features. For the operation itself, I could reference another Activity in the referenced Behavior field of the Operation properties. I do not understand the allocate part. Is the author referring to the allocation relationship or basically nesting the Operation in the ESS block? Does the referenced Behavior also get nested in the ESS block as well?

[jfranflorez]

Hi

Do you have a diagram image related to the text?

The author talks about a "Hybrid-Approach", and he calls it hybrid, because he uses a CallBehaviorAction to call An Activity (this is normal) but he also links the CallBehaviorAction to an Operation (normally CallBehaviorActions have nothing to do with operations) by means of an Allocation relationship (He does not link the Operation with the Activity directly).

Apparently he states, that the Action's behavior is described by the Activity (because he calls the activity by the CallBehaviorAction) and he states the the Action's behavior is realized by the Operation (because he allocates the CallBehaviorAction "not the Activity" to the Operation).

In the text it is however not clear what he means by inherited and redefined. So it is hard to tell what the real use case of this approach is, but it maybe can look something ike this:


1) Two Blocks represent different versions of something and there is a diagram that describes the behavior of each block

AcitvityA
   --AllocatedTo--> BlockA
ActivityB
   --AllocatedTo--> BlockB
BlockA
   --doSomething (operation)
BlockB
   --Generalization  -->BlockA
   --doSomething (inherited)

ActivityDiagramX
   -doSomething:ActivityA (CallBehaviorAction) the Action has the same name as the operation to visually make it look like its the operation but it actually calls ActivityA
           --allocatedTo-->doSomething(from BlockA)

ActivityDiagramY
   -doSomething:ActivityB (CallBehaviorAction) the Action has the same name as the operation to visually make it look like its the operation but it actually calls ActivityB
           --allocatedTo-->doSomething(from BlockB)


So in the above example, two different diagrams which "appear" to call the same operation (they dont actually do it) have a different behavior for the "same called operation".


In EA you cant link Operations, so it is not possible to do something similar.

I however couldnt think of a single use case, which would be supported by the modelling tools EA, Rhapsody, Cameo or PTC Modeller where this approach would be benefitial.




In EA you cant link Operations, so it is not possible to do something similar. I however dont think this approach has any benefits

[vrieg]

Hey,
from my understanding you need to implement a methodology on top of EA to do this job for you.
You can use any approach as sysmod, capella or harmony or the methodology implemented in cameo.
Without this linking will be a mess.