In an OAB, when I want to add an existing Interaction on an Operational Activity which is not a leaf (that is to say, this Activity contains at least 1 level of lower-level Activities), the wizard for addition of existing Interactions proposes only the Interactions of the leaf-Operational Activities contained in this Operational Activity, not the Interactions that directly belong to this higher-level Operational Activity). The crazy thing is, in the same diagram I can CREATE new Interactions for the higher-level Operational Activity and they are displayed correctly, but I cannot make existing ones appear. Is there a workaround for this limitation of the wizard ? Is there another way to add existing Interactions in an OAB without the wizard (I tried drad-and-dropping from the Project Explorer but it doesn’t work) ?
Hi,
My question is what would be the sense of interactions between non leaf activities:
Option one: a lower level was created, but the interaction is not with it. To me the union of subactivities shall equal the upper level activity. What is missing there is may be a complementary activity to fulfil this rule. Then the interaction goes to this complementary which is leaf.
Option two: The lower level is set as partition of the upper level activity, but you want to gather interactions by making iit go to the parent. In this case the description is blurred: where shall go the exchange items : to which leaf, some (which?) all? I’m afraid that you need then to duplicate the interaction and allocate same exchange tiem then.
Option three: the sub-activies are there as description but the interaction level is always the parent. Then the sub-activities should not be created, but described in description text. This makes the parent activity recover the state of leaf.
The reasons to split activities and functions are:
Sub functions are allocated by different components
Sub functions runs in different mode sets: should lead to component split
Sub functions are available in different variant sets: should lead to component split
If Capella is not happy wiith connecting exchanges to parent items, it’s problably for this reason.
Regards
Thierry Poupon
Hello Thierry, thanks for your analysis.
My case is what you describe as option two. In the same way that an Operational Activity can be a parent of several lower-level Operational Activities, there is something missing on Capella about interactions, it should be possible to define that an operational interaction (the one between the upper-level activities) is the parent of lower-level interactions (the ones between leaf-activities).
In my current state I do have duplicated interactions: I have the upper-level interactions and the lower-level interactions. Yes, the Exchange Items transported on an upper-level interaction will be the concatenation of the Exchange Items transported on the corresponding lower-level interactions.
Depending on the purpose of the diagram, I have some diagrams where I want to display only the parent activities and their high-level interactions, deliberately hiding the details underneath. And I have other diagrams where I want to show the details between some of or all of the child activities and their lower-level interactions.
“If Capella is not happy wiith connecting exchanges to parent items…” → actually, Capella does not prevent to create interactions between parent activities and does not report any errors or warnings about this. In a OAB, I can create new interactions between parent activities and they are displayed correctly as I want to. The limitation is ONLY on the wizard that allows to add existing interactions in a new diagram. So Capella in unfortunately not consistent on this matter, that’s why I’m trying to find a way to bypass the wizard.
If I were at SA perspective I could use Categories but they don’t work at OA perspective…
Hi Boris,
My new question is then what was the reason to split your activity:
are the children allocated by different roles or entities?
are they running while diffrent modes/states of the allocating entity
are they involved by different scenarios or fragment operands that run while different modes/states of an universe part that owns all scenario actors?
If no to all, then may be you should consider another way to describe the activity to be shown in diagram than splitting it in children. Then your interaction group would be interaction again…
If yes to the first, then the communication mean that could allocate each of the duplicated interactions will be different because connected to different entity. In the next level the FE would be probably allocated to different component exchanges (pending if your system or some actor realizes several entities).
If yes to the others, then you have to consider splitting entity about the mode/state, allocate the appropriate activity. When shifting to SA, you have to decide if your system is requested to realize all or not. If you guess that this split will be canceled at system analysis, then may be the concerned state/mode is not for OA.
Remember OA is setting the current universe before the system exist, and how this universe currently runs the scenario that the system will have to support. Or if the targeted capacities and missions are new, then the universe includes your system as OE, and may be some enabling systems as well (they are new as well, but you don’t want to create them yourself)
The reasons for splitting an operational entity are:
They change state at different time for different reasons
System will have to realize entire OEs.
When initiating SA, the use phases will come from useful combinations of actor states, that brings different requirement sets.
Each item split (entity, role, activity, state) brings complexity that you have already enough and therfore shall be thought twice.
Remember as well that naming executions and give them description text in scenarios may help in describing activities without splitting them.
Regards
TP
Edit one: As sum up:
OA purpose is describe the universe in which occurs behaviors that may involve the system you want to design, behavior that should be user experience. Then while SA, you will have to assess which part of this universe your system shall realize.
If some entity is not used nor has no role in user experience, then it should not appear, if some entity has no use for being split, then don’t split.
What helps is first create at the top the OE “universe”, then split to set up what you need, this OE universe may own the state machine to describe owned OE state combinations, that will useful to set system use phases, in the same way you will define system variants needed to answer to other actor variants. coming from their realized OE variants.