Thanks both,
Regarding REC/RPL, I can see that these work fine if all you want to do is copy/paste structures that you’ve created with the ability to manually update all the copies if a change is needed. (Although I’ve had a problem with RECs regarding needing to update many RPLs with values added via PVMT, which was partly why I was asking about linking classes in this topic as it would provide a nice workaround, see this topic: Creating a shared library of components with attributes)
For this topic though, I’m trying to understanding how any classes representing structures (like in the example In-Flight Entertainment System model) relate to the structures in the model. There is a Passenger class, and a Passenger structure. It feels like there should be some kind of relationship or connector here? Otherwise, you could argue that the model is not complete, since the class defines properties about something that it is not linked to?
If this is not the case and there is no way to link these two model elements, why is this? Why is it possible to type exchanges by classes, but not structures? And why does the example model have a class definition for a structure that cannot be linked? The class diagram provides a way to describe much richer relationships and property information about structures than RECs, but is it valid to use it in this way?
Following on from this, is it valid to say that Capella can perform ‘instance modelling’ if each structure component can only ever have a 1-to-1 relationship with its ‘structure definition’ (the element that is hidden by default)? Instance modelling requires that ‘A Class, Data Type, Interface or Signal can have many Instances.’ (Source: PTC Help Center)
I just can’t quite get my head around this design choice. Is there rationale for it?
Thanks,
Jack.