Hi Stacy,
Several aspects can be considered to answer your questions :
1° Meaning of ‘Deployment’
From the Arcadia language point of view, there are only two notions related to “components inside other components”:
- each behavioral component can be ‘composed’ of other behavioral components that contribute to its behavior;
- each hosting component can be ‘composed’ of other hosting components that contribute to its assembly;
- behavioral components can be ‘hosted’ by hosting components.
‘Composition’ is to be considered with a weak semantics here; it just means that to use a component, you should consider it along with its composing “sub-components” as a whole. No other stronger semantics consideration is to be considered (such as UML composition vs aggregation, or the notion of parts, etc.). But this composition will also drive the PBS assembly tree as well.
In Capella, for compatibility reasons mainly, things are a bit more complicated. If you want to be aligned with Arcadia, I would recommend that :
- behavioral components (BC) are related with each others by breakdown relations only (as seen in breakdown diagrams, and depicted in architecture diagrams as sub-components having square-angles rectangles)
- implementation components (nodes) are related with each others by breakdown relations only (same as for BC)
- BC are
deployed on Nodes only (no relation between BC and nodes in breakdown diagrams; and BC deployment on node being depicted in architecture diagrams as deployed BC having round-angles rectangles).
2° hosting of behavioral ports by physical ports
One of the major recommendations in Component-based Design (CBD) and in Arcadia is encapsulation : in order to use a (behavioral) component, you should as much as possible only need to know and use its external interfaces (and behavioral ports in Arcadia). If this “interface port” is in fact managed by a sub-component, then delegation should be used.
This is only a recommendation in Arcadia (some limited cases have been identified that may require direct exchanges between sub-components), but it is enforced by a creation rule in Capella (which could be subject to discussion).
So if you want to describe you embedded Linux as a behavioral component, then in Capella you have to create a Linux port and delegate the GPSD service port to this one, as you suggest.
3° Behavioral or hosting component ?
However, you might consider another option : what about creating the embedded Linux as a hosting component (node component in Capella) ? In your engineering scope, I suppose that you will not modify Linux “component”, and probably not allocate directly functions to it ? This looks more like a resource component hosting your software, rather than a true behavioral one.
If so, you could define Linux as a hosting component, having physical ports linked to embedded computer hardware physical ports by means of driver-supported connections (physical links); then these ports would host your GPSD service component ports (port allocation link in Capella).
Hope this helps.
Jean-Luc
Hi Jean-Luc,
Yes, each one of your points were helpful, especially the clarification of Arcardia’s approach to “components inside other components”. I have revised the PAB diagram to reflect my new understanding as applied to the original problem.
I have changed the Embedded Linux to a PC as it is COTS software that we acquire without modification but we will use with configuration. So we will put the functions we need to model onto a BC ‘Configuration of Embedded Linux’ while having it hosted on a PC, ‘Embedded Linux’. This works because the GPSD Service is software provided by the Embedded Linux PC (COTS) but our GPSD Service Configuration BC (developed as part of our solution) achieves the functions we need, when hosted on the Embedded Linux PC.
This meets the needs of our modelling because:
We have a sensible place to show important functional exchanges. Sometimes key functional paths traverse through operating system provided software services.
I can identify from the diagrams which physical links the functional exchanges occur on.
I have a sensible and reasonably complete group of PC and BCs that can be used to populate the build strategy.
Thanks again,
Stacy.