I’m fairly new to Capella and have a question about classes. I’ll use one of the example models to demonstrate: the In-Flight Entertainment System.
In this model under there is a class diagram which specifies that a passenger has a name and a first name. The class view seems to provide quite a rich set of grammar for defining attributes and data of objects.
However, when I query the Passenger structure, I can’t see any way that it is or can be connected to this class in order to imply that the Passenger structure is ‘an instance of’ the Passenger class?
This would be really helpful as I’d be able to assign attributes to my structures, the same way that you can assign content to functional exchanges. Potentially I could then use these attributes to control state behaviour (e.g. WHEN parameter X > 1). Is there a way to do this?
I want to set ‘Left’ and ‘Right’ to be of type ‘wheel’:
Is this possible in ARCADIA? If not, is there a reason? Why is there a ‘Passenger’ class in the ‘In-Flight Entertainment System’ model which is not / cannot be linked to the ‘Passenger’ structure?
Now I understand your question.
You want a structure component to be typed by a class.
There is no such possibility for class but there is another way (REC\RPL)
In Capella Class is used
for typing data that communicate between functions\components.
for typing simple properties inside components
I’ve explained before how to add an internal property (typed by class)
for a component.
There is a notation part\definition for structural components in Capella.
But it’s hiden by default in user interface. And it’s not
common to use it. And I also does not advise to use it.
In fact Capella is meant to work with an “instance” model created by hand
or from templates (REC\RPL). Commonly you can’t define one definition and
and use it to type several parts. You need to create every component
instance explicitly.
For example if you have 10 tables with 4 legs. You need to create
40 legs by hand. Or create REC for table definition withs legs and after that
create 10 RPL that will automatically create 40 legs in the model.
In both cases you will obtain explicit legs in the model. In the case with
REC\RPL if you will add some new feature to the table you will
be able to update all REC automatically.
Thanks dsryzhov for your reply, I wanted to reply before to @JackHutton, but other priorities came in.
That is the strategy to use with Capella to handle “definition” and “instance”. In Capella all model elements are considered instances, definitions are created and managed by the tool. Definitions created can be seen in the project explorer if filter “parts” not applied.
However, I will take this opportunity to ask/discuss what is your view and approach to create REC/PPL model elements and considering the tables and legs above from @dsryzhov.
Create the structural physical nodes: table, 4 legs, and any properties identified and allocated to them (e.g., size).
Define a REC for the all the elements above, e.g., REC Table and legs.
Create RPL from REC, e.g., RPL: Long table and long legs.
Create a Physical Components Breakdown Structure (PCBD) diagram.
With the above steps there will be in the PCBD, nodes for table, legs, long tables and long legs.
Do you follow the above or do you share a different view to capture model elements when using REC and RPL?
Another example could be:
Create model element Tyre as REC, also know as definition.
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?
At first I should say we need complete instance model to be able to specify some properties\constraints\requirements for instances in context (not only for definitions). For example be able to specify that 3rd leg of 5th table should be painted green. Another example from safety analysis. We need to be able analyze how failure modes of component instances influence system functions.
I think that creating instance model manulally (including REC\RPL) is not the best way in many cases. It’s not very easy to use it when there is a RPL inside REC and so on.
I like AADL-way of automatic creation\update of instance models from definition models.
This approach is much more productive than REC\RPL. And results in possibility of creating many instance models. You can use any definition to create instance model from it.
In AADL every definition may have only one level deep structure.
It’s not good for very use cases.
SysML 2.0 combines two approaches. You may create instance models (of any deep level) in the same way as in Capella. But also may create definitions and use them to type instances. But as I know reference implementation tool does not have feature to create\show instance model.
Another approach to create instance models on the fly is used in PDM or CAD software.
We can define components (definitions) and it’s properties. But can add\modify different properties for each component instance. Ability to define different variant for each component and instantiate selected variant also very productive.
The main reason for REC\RPL that I understand
it that Capella and ARCADIA is mostly top-down approach.
ARCADIA process go from functions to components.
As a result Capella model has separate hierarchies of functions \ components.
In bottom-up approach system is composed from bricks.
In this approach every brick should contains all information.
Structure of Capella model (with separete hierarchy for functions and components) is not very suited for this approcah. It’s not easy to create an UI that will help to work with this model structure and bottom-up approach.
I think REC\RPL approach is the found solution.
You can include in one REC not only structure components but also functions, capabilities, requirements. And when instantiate RPL instances of this elements will be created each in own section of Capella model.
In Capella, you are not “typing” exchanges by classes. Exchange carries Exchange Items (Exchange items are literally what is flowing between functions through ports and functional exchanges). And Exchange Items are described using the Class Diagram, which is more a “Data modeling diagram” than a class diagram, actually.
In Arcadia (and Capella), a class will not represent (or type) structures in the model (they do not represent actors, or components). As dsryzhov said, “You want a structure component to be typed by a class. There is no such possibility for class…”.
You’re right, I should have said in an earlier comment that classes type exchange items rather than exchanges.
If a class does not represent or type structures/actors in any way, then in the In-Flight Entertainment System example model, what is the relation between this Passenger class and this Passenger actor? (Same question for all the other classes that have the same names as actors.)
@JackHutton maybe the example tries to capture an ontology for the system under development?
The ontology may help to identify elements and the relationship between them.
