Deployment vs Hierarchy of Behavioural Components

[Stacy_Walker_old]

I have a common design pattern in my work that I am not sure how to best represent in Arcadia. Often I will (1) Buy a computer (hardware), (2) Take an operating system image, (3) develop custom software, (4) integrate the hardware, operating system and custom software together.
When I try to model this with a PAB I get a diagram similar to the attached example ‘PAB-Embedded Computer.png’. This looks good, except that Capella won’t let me do a Component Port Allocation for the RS-232 physical link to the flow port GPSD Service. Therefore I assume that isn’t valid Arcadia syntax. The focus here is on the Embedded Linux behavioural component.
Alternatively, I am able to draw Component Exchanges between the Embedded Linux and GPSD Service components. From there I can draw a Component Port Allocation from the RS-232 Physical Link ports to flow ports on the Embedded Linux component.
The intent of my modelling threefold:

• To explain the functional exchanges in the system.
• To identify which physical links each functional exchange will take place upon.
• To provide a comprehensive list of components to populate in my build strategy.
  My questions are:
  *How should I be structuring the behavioural components when it comes to software images or operating systems and the software installed onto them?
  *Capella has several tools in the Palette that use the word ‘Deployment’. For example, ‘Manage Behavior PCs Deployment’. However, the word ‘Deployment’ isn’t used in Jean-Luc Voirin’s book on the Arcardia method in this way. What word in Jean-Luc’s book is synonymous with ‘Deployment’ in Capella so I can understand this further?
  Thanks in advance.

[JVoirin]

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

[Stacy_Walker_old]

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.