Will try to add more user need’s oriented answers.
Arcadia and Capella features
strict sequence in the process: at first atomic functions should be defined and after that behaviour should be defined using state machines
does not help in specifying behaviour of “atomics” functions
There is a need for the following approach:
“atomic functions” need to be defined during behaviour specification (the same way as interactions are defined during scenarios creations)
there should be an opportunity to specify behaviour of atomic function in detail
BTrees can help with theses needs:
BTree supports an approach when atomic functions are defined during behaviour modeling
BTree can be used on different levels : from high level to the low level behaviours (atomic functions behaviours)
BTree can be easily introduced in Capella due to using semantic information for composite functions to specify control flows (no need to model control flows explicitly)
Capella introduced a very simple tool for functional analysis. BTree adds an option to specify behaviour in the same simple manner, without using additional modeling constructs.
In my opinion it would be better to implement BTree notation as part of Capability Realisation mechanism. It would be more consistent than mixing BTree control flow with data flow on functional decomposition level (conditions, decorators, sequences and selectors are not functions (actions)).
I agree that it is a possible approach. And it should be also implemented in BTree viewpoint.
I used to name it “in a Capella way.” In this way composite functions in hierarchical decomposition do not have execution semantics. In this way leaf-functions are atomic.
There are several elements where BTree could be used in this way
in capabilities
in functions (in the same way as functional chains)
in components (in addition to statecharts)
In this way a new separate meta-model for BTree needs to be defined.
It’s more convenient than “stereotype” elements using property values.
It gives possibility to show BTree node types in model browser (using icons)
New BTree element type can be added to existing elements (using Capella element’s extension mechanism)
I will add support of this approach to the viewpoint also.
I need to make a decision now about linking leaf-nodes to functions.
There is an architecture trade betwee
1 to 1 mapping (one leaf node of BTree is linked to one atomic function)
1 to N mapping (one leaf node of BTree is linked to several atomic functions)
Currently I’ve selected 1 to 1 mapping.
1 to N mapping can be compared to statechart possibility to add several functions for entry\do\exit actions
May be In BTree this approach should be also used.
Abother decision about link implementation
using an attribute in leaf-function
using separate link elements that cab be added to leaf-functions
In the second case it will be possible to show linked functions in Model Browser.
The way is done for Functional Chains is IMHO quite consistent: a Function is involved in a Functional Chain. The involvement is an element of the model, and the relation is 1 to 1. This is because if a Function is involved in a FC more than once, each of these involvements say something about the expected behaviour of the function in this particular context. If leaf nodes are actions, I think it could be done in a similar way.
There is some thoughts aboout condition node enhancements.
Currently condition node can be defined by any text in BTree model.
It will be good to be able to reference other model elements from a condition node
in the same manner as guards and triggers are defined in statecharts
condition node can reference any constraint from model
condition node can define triggers by referencing exchange items of different types
condition node can references function from functional decomposition (to check function results)
if BTree is defined in a capability all functions referenced by BTree should be added to the Cappability as involved functions. It should be the same result as for data flow diagrams in capabilities and scenarios.
Check out for instance the Sequence Links in Functional Chains. They have a Condition field, which can be completed by the user referencing any element in the model, including constraints, exchange items, …
It’s the most flexible solution, but not necessairly the one the guides the engineer in the best way. I’m not a BTree expert, but there may be attributes that you shall fill regarding a condition. As an example, in Sequence Links you shall define the “Links” attribute, and the options are restrained to the involvements of functional exchanges between the functions.
Thanks! I like your proposal. Will change to this way.
At this point numbering is neccessary to sync diagram with model browser.
Numbering helps to understand that nodes order in model and diagram are different.
On diagram you can easily change order of nodes.
After that you also need to change order of nodes in model browser.
