Deployment vs Hierarchy of Behavioural Components [message #1823984] |
Mon, 06 April 2020 05:14 |
Stacy Walker Messages: 2 Registered: March 2020 |
Junior Member |
|
|
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.
[Updated on: Mon, 06 April 2020 22:58] Report message to a moderator
|
|
|
Re: Deployment vs Hierarchy of Behavioural Components [message #1824078 is a reply to message #1823984] |
Tue, 07 April 2020 13:31 |
Jean-Luc Voirin Messages: 8 Registered: February 2020 |
Junior Member |
|
|
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
|
|
|
|
Powered by
FUDForum. Page generated in 0.03843 seconds