Strangely enough, nowhere in the Capella doc I have been able to find a specification of this (I recall though, there ha been some discussion about this in the fora which I could not retrieve neither). The questions are:
Do multiple input/output ports of a function/operational activity have a AND or an OR semantics? In other words, does the function need to have the inputs at all of its input ports available to execute and produce, analogously, outputs at all of its output ports at the same time?
I think, this implicit semantics is and should be AND. Which makes some of the information still present even in Capella 6.0 help, e.g. the “computational node gather” in the “Function (generic)” Glossary obsolete…
My view on this: ports and functional exchange in Arcadia/Capella are related to data flows, not control flows. So you don’t know. It may be an AND, may be an OR. Or something else.
To model this kind of information, using control flows may be an option, ie functional chains or scenarios, you may use “computational node gather” I suppose.
Comp. nodes like “gather” deal also with data flows and they still do not answer the question if you have multiple input ports, cause “gather” merges 2 inputs into a single output fed into a single input in the particular function. Control flows, i.e. sequence links (the addition of which I was advocating and eventually it happened despite some INCOSE/IEEE papers arguing they are contra-productive…) are not really an option here cause they control when a function will be executed not what data it requires. What we are discussing here is actually optional/mandatory arguments of a function/method - a concept used for decades in programming… Sorry, bu a “don´t know” semantics would imho make teh whole matter of func. mmodelling kind of ludicrous Therefore, I recommend to define the semantics valid for the model in the model itself, e.g. in a note or a constraint - the practice I am following personally…
In my head, programming is software design and is product design, not system. The software executes functions, requires entries and calls…the functions has inputs that come through ports. Exchange item should not represent software variables but their meaning, as signal or instant value. In my practise, I have software variables, they are numericals, enumerations or booleans and do have litterals when appropriate to link with specific values mentioned by exchange item elements. The condition of execution of a function is in a constraint where you can write the required situation about the inputs: this involves the exchange item, its elements, the detail typing it, the litteral value, if a class is in there, the properties… and the state/mode or property value applying to any item of the concerned scenario, or functional chain. The constraint may affect operand, mode/state transition, availability of scenario, capability…
About availability, each detail, property in a class has a litteral value prepared for default and null, that you can populate and use in constraint expression.
All this data is the entry to develop the product (software here)
Regards
Thierry P
Hmm, of course they do, obviously in the broad sense that both transform inputs (data) to outputs (data)… As in this case, clear-cut concepts from comp. science and SW eng. if taken over in MBSE would resolve ambiguities…
Yes, EIs represent messages (ops, events, shared data) or, quite inappropriately, also streams (flows) and variables and detail types of EI elements etc. should not be mixed with what is the question here (which I did not). What you are, I think, trying to explain is that the simple basic prerequisite of availability of input data needs to be burried deep in the class and constraint definitions distributed in the model and not clearly visible (in diagrams)… Instead, by “convention over configuration” (btw another successful principle from SW engineering there should a single default and clear general convention to discern optional from mandatory inputs etc. Because in many systems this is uniform. So this is what I explained we are doing in our models. If there is a need to have multiple different, it should still be possible but again, the distinctions should be made visible (in the diagrams and elewhere e.g a special icon for functions deviating from the convention)
Have you considered using Capabilities along with functional chains and scenarios to communicate the meaning of having multiple output ports of a function?
Depending on the functional chain, different functional exchanges may be invoked.
If you are finding that a single functional chain still goes through multiple output ports, then it could be that further functional decomposition is required… or that now is the time to jump into your software development tool.
Imho it is normal that multiple output ports of a function each conveys different EIs. And, within a particular func. chain, each of these ports is in the context of a particular func. chain connected to a different function processing those outputs, Why should that not be plausible?
Therefore, I recommend to define the semantics valid for the model in the model itself, e.g. in a note or a constraint - the practice I am following personally…