The diagram illustrates that the allocation of Functional Exchange 1 and 2 to the system boundary Component Exchange 1 are routed through the individual component ports of the internal Logical Components 1 and 2. I interpret this as the boundary component port being ‘split’ into two ‘extended’ ports to the individual internal components, so when the Functional Exchanges are allocated to the Component Exchange, Capella knows to that they are routed through the local components ports of the internal logical components first and indicates it graphically as illustrated.
Usually one would simply drag the boundary component port onto a chosen internal logical component, but there are instances where the boundary component port needs to be part of more than one internal logical component, and hence needs to be ‘split’.
I found this diagram in Pascal Roques text book in Chapter 1, but I cannot seem to find the explanation of this unique feature anywhere else in the book. I found myself now needing to perform such a confiuration in my model, but do not know how.
Hi,
this cannot be done automatically. You have to draw the port delegations and allocations manually.
(And -for correctness in this case- change the ports from CE1 to InOut…)
There is something about ports or port delegations that I obviously do not understand here, so here is what I am attempting which does not seem to work:
Step 1: I get the model and diagram into the state below:
I found that, in stead of outright deleting the port allocations, simply double clicking on the ‘blue’ port allocation and changing the source element from “CP 3” to “CP X” (see below) is quicker. I also found that renaming the newly added port to ‘CP X’ before re-assignment makes it easier to find in the Selection Wizard since the default for all newly added component ports are ‘CP 1’ and there are usually many.
I must admit, this seems like a very clunky method. I am sure developers can find a more streamlined or automated way of doing this in the future. Also, I am struggling to understand what the philosophical difference is between doing it this way vs. splitting Component Exchange 1 into two separate ones and assigning each a Functional Exchange, except that from a System External Interface point of view you would then have two separate interfaces that need Requirements specified in stead of one. I am also somewhat blind to what this effect will have on the transition to Physical Architecture… I guess there is only one way of finding out… Thanks for the help.
Well no, because simply deleting and recreating the the allocation did not automatically include the added delegation ports in the allocation (for some unexplained reason). As I mentioned above, in my last step simply changing the allocation of one of the ports seems to be faster (but still somewhat clunky)
Maybe we’re not understanding each other.
When you’re at this stage:
What don’t you simply delete the link that you have circled in red and recreate it from the function exchange to the CP X port using the “Port Allocation” tool from the palette?
Misunderstanding indeed. I did not notice that there was a port allocation tool in the palette . This does speed it up a little bit, thank you.
Now the obvious question is:
Does it not seem more intuitive to be able to simply click and ‘drag’ the end point of the assignment from CP 3 to CP X (in the same way you are able to do with functional exchanges), in stead of having to delete it and use the tool to reassign? Is there some reason why developers chose this route in stead? BTW: this was exactly what I initially tried before getting lost…
1 - I certainly agree it would be more convenient to be able to drag the end point, I also tried it initially. Please raise a feature request to Capella (if not already existing)
2 - I don’t believe that the developers “chose this route instead”. Generally speaking, for any model element, what is mandatory is these 2 basic operations: to be able to manually create (a Port allocation) and to delete it. If you cannot do those 2 basic things, you’re going to be stuck, these are a must have. Once you have that, being able to drag the end of an existing one is added value, not mandatory, as you can do it by deleting and re-creating. Why did the developer not do it? Well maybe they forgot. Maybe this was not specified or requested. Maybe they did not have time. Maybe there was not budget for it. Maybe it was less a priority than the thousands of other things they were asked to do. But the bottom line is that I agree with you that this would be nice to have that working and I don’t see any reason why this would not work. BTW, we welcome contributions!
I remember long ago, in a past webinar, that Stéphane Bonnet admitted that the way Capella manages port allocations when you decide to use delegations was not optimal
Hello @pascal.roques , thank you for the feedback! I feel honoured to get attention from the original author of the book…
If you will allow me some friendly critique on this matter:
On page 206 of your book, you did not quite explain the steps of actually reallocating the functional exchanges that would cause Capella to include the delegated Component Ports in the allocation, but simply mentioned adding of the Delegation type Component Port to the model and then say “…and finalize all the Functional Port Allocations…”. The allocations then appear in Figure 5.47 as if “magic” happened, which is why I made the (wrong) assumption that Capella would be able to figure this out, causing me to go down this rabbit hole…
Question: Will you ever consider performing an updated version of your book that would include all the major (stable) evolutions of Capella since the last version?
You are right!
Probably I did not want to insist on what was not done perfectly by Capella at the time…
And I hoped that it would be fixed sooner or later, which is not the case
Unfortunately, I cannot decide to update the book. As you probably know, the editor (and not the author) has all rights on the book, and it does not seem that an update is wanted…
So I have discussed this topic with the Capella team @ Thales and this is indeed something that should be working. We’re going to see if we can find the resources to fix it for the next release.
Appreciate the feedback. Hope I didn’t rock the boat too much…
If it makes any difference, here is my two cents feedback:
The way I see it, Capella should always associate (i.e. join or ‘link’) a delegation with an external Component Exchange when created (this happens anyway when creating a delegation). This way, when assigning the Functional Exchange to the CE, Capella already knows to include the delegation and its ports in the final assignment.
. This does speed it up a little bit, thank you.
. The allocations then appear in Figure 5.47 as if “magic” happened, which is why I made the (wrong) assumption that Capella would be able to figure this out, causing me to go down this rabbit hole… 
