I am trying to model a database of data flowing in my system, using capella data modeling. The following approach seems to be intuitive to me :
signals: represented by “exchange item element” (e.g. “enable signal”)
signals are grouped into “exchange item” to give context for set of signals (e.g. “Control data”)
interfaces can group one or more exchange items (“the protocol”) to define the direction of data flow, and sometimes at higher level of components.
My problem is this:
“exchange item element” as a signal, has its attributes that require values (scaling factor for example). To do that, PVMT is the most relevant solutio - meaning setting a custom “scaling factor” property in the PVMT table. So far reasonable. But at the same time, this “exchange item element” also have a type, in the CDB diagram (it can be “boolean”, “numeric” or class named “signal”). Technically speaking, the signal is not “boolean” or “numeric” but its value can be. It would be more correct to say the “exchange item element” is of type “signal” class, that has its properties. And then these properties I would be able to control in the PVMT. But it seems that PVMT does not work like that, which creates disconnection between properties of a type of an element (via the class), and the ones i create via the PVMT. Am I missing something?
Is it possible in the PVMT to create a rule (attribute/Eclass) that depends on the type of the element I am referring to? for example, to define set of custom properties for exchange item element if it is typed to certain class/numeric type with some name..
I would quickly say that PVMT is just some additional tooling to better manage PV, which stands for Property-Values. So semantically speaking, PV are quite poor (and not really comparable with what you can do in terms of data modelling in Capella).
Exchange Items are linked/holding data that you model in CBD. Generally you do not “enrich” the exchange items themselves but the data it links to.
I recommend you look at the “Thematic highlights” section in the Capella documentation (Capella Guide→User Manual → Thematic Highlights) and specifically the sections “Functional Analysis to Interface Engineering” and “Interface and Data Modeling in Capella”.
You are generally limited with the types of rules you can do with PVMT. PV can be attached to certain “metamodel objects”, you cannot really make a rule that depends on the type of objects that your object contain (if I understood your question correctly).
yes I went over this documentation, thank you. I have 2 big issues that are currently only proposed by PV. But I will be happy to know otherwise
(1) setvalued attributes. Some attributes are set as literals (scaling factor, length,ID..). I cannot really see how to set it in the standard (non-PV) approach. I saw some proposals using constraints, but this is really not elegant IMO.
(2) observing the attribute/values on a diagram or via the semantic browser. PV offer that in 2 ways (either through PV tab, or through diagram styler). without PV, if I set an exchange item element to be of type certain class, when selecting the element I cannot know what are its properties (and values, but this is related to issue #1)
I would be happy to know if i am missing something