[CDB] ( ExchangeItem, Class) and [IDB] (Interface)

Arcadia
1

Hi all !
I have some questions about the [CDB] diagram (the classes) and I will probably comment this post in the future for questions about the interfaces ([IDB] or [CII])
I have studied the slides linked with the [CDB] from
An_Introduction_to_Arcadia_20150115.pdf,
ExempleCapellaRadioReveilOA_SA.pdf and the 3 [CDB] from the IFE and now I think that I need some help (such as document?) and others looks (about my work) to progress
The context : I wish to
modelize a fluidic system (with pump, pipes, valve, sensors,…) which is a part of a nuclear island
and the command-control of this system. Actually I have only modelized the links (FE, CE, PL) of the fluidic system and I just start to add the links between the command-control and my system. Also, I have made a model using the 4 views (particularly thanks to the previous post
Physical Arch : Node vs Behaviour, thank you all) and I’m actually wondering
how my [CDB] could be improved and I have some
questions about this kind of diagram. In fact, the ExchangeItem(EI), the class and the interfaces are now the concepts with which I’m not comfortable manipulating (mainly because of the rich Palette and my lack of knowledge in UML) but i would like to start to use the EI, allocating them to the CE (CE1 = water --> fluidic system, CE2 = electrical --> command-control) and later to the FE.
The [CDB] first version
Explanation :
I wish to use a [CDB] firstly in the view LA because here appears how the system will work and especially because this view has for aim to manage the complexity, so it let me to make
some test more easily which few EI, classes and properties.
I have created

  • 1 class (and 1 EI) for the fluidic system which let me to characterize the water
  • 2 classes (and 2 EI) for the control-command which let me to characterize the information sent to the actuator (mainly : valve and pump) and received from sensors (pressure/flow/concentration sensors)
    I have a lot of questions about it such as : for a signal start/stop (“open/close” for a valve and “startup/trip” for a pump, I think) should i use something else than a Boolean Type ? What is the best way to modelize a threshold crossing …?
    Question 1 : But I think it’s better if I “just” ask : do someone have any suggestion or remark … ? Does it looks a good way to modelize ?
    General questions about the [CDB]
    Question 2 : what are the
    Union and
    Collection and when should we use it ?
    Question 3 : why some concept have in their name the word
    Reference ? When I double click I can add “referenced value” and “referenced property” so I thought there was a link with the “property value pkg” but i couldn’t allocate, I probably missed something
    Question 4 : i don’t know how to formulate it … my problem is about the correct meaning (so use) of all the concepts of the 2 “Pin Open” (from
    Boolean Type to
    Collection Value Reference)
    Maybe could you provide me an overview of the utilization of these concepts or anything to help me ? Why are they separated in 2 parts (the 2 “Pin Open”) ? At the beginning I thought it was : the first part is for the type, the 2nd part for the sub-type but it doesn’t seem right … hence my “general questions” to try to get an high view of this diagram, my wish being to understand the whole palette to use it the more correctly as possible
    Thank you for reading !
    Pierre
2

Hi Pierre,
You have a lot of questions, which is nice and quite normal as the CDB is very rich in Capella!
I will try to give you several hints in this post and promise to complete it later on…
In your first CDB, you should rename the properties (as you did properly in the second one).
If you do not need any Unit concept, you’d better use a Numeric Type. Physical Quantity = Numeric Type + Unit.
For your start/stop, I would not recommend a Boolean Type. Just imagine one day you need to add also pause/resume? I think an Enumeration is more flexible.
Do not use
Unions unless really necessary!
Unions are structures that can take different forms according to the values of a Discriminant.
This construct is mainly used in relation with software programming languages. For instance, in the Interface Definition Language (IDL) from OMG, a union is essentially a group of attributes, only one of which can be active at a time, according to the discriminant. A union saves memory space, because the amount of storage required for a union is the amount necessary to store its largest attribute.
A
Collection is a data modeling construct allowing the definition of sets of elements. Min and max cardinalities should be indicated and they appear in diagrams.
The type of the Collection specifies which kind of elements forms the set. It can be a class or a simple type.
Stay tuned!
Pascal

3

Hi Pascal,
Thank you for your answer, with it and a coaching session I now have a better understanding about the reason to create ExchangeItem(EI) and PropertyValue(PV)
A few words about it : I think I would use for my model the PV to deal with, to export, data i would like to use to get (later) a dynamic model. I would use EI to define as correctly as possible the envelop of data which will be exchanged
I am not feeling the need to ask others questions actually so I will wait to see how advance my model in the related diagrams and also for your hints
Regards,
Pierre

4

Hello,
is there any additional details about the palette and Value/refence elements?
Best kinds.
Nesrine.