Data modelling using Exchange Item Elements vs Class

It is not obvious for me, what method of data exchange model to take in the project I am currently working on.

Let’s say there are three Physical Components. Components A and B produce some common runtime data (healthchecks, status, etc). Apart from the common data, both components produce specialized data as well. Component C is there only to gather the data. It is worth noting that the common data and specialized data are produced at different rates, and they are not published atomically.

From what I reckon, one course of action would be to model three classes: one for common data and one for each specialized data (though it is not clear to me, whether to use a “regular” or a “primitive” class). Then I would create three Exchange Items, each with single Exchange Item Element of a corresponding type.

However I can see another solution: no classes are created and data is modelled directly as Exchange Item Elements. Instead of Exchange Items having only a single Exchange Item Element, linked to the created classes, I could create Exchange Items with multiple Exchange Item Elements, as if Exchange Item was a class.

Is there any significant difference between those methods? I am aware that the first approach would be more scalable, especially in big and complex models, where encapsulation and reusability would be beneficial. But let’s assume that the model is not that big or that common data will never be reused, only in that one Exchange Item.

Hi,
About “regular” or a “primitive” class, There are three kinds of classifiers in Capella : “regular” classes (including unions and collections), complex data types (primitive classes) and simple data types. On a data type (complex or not), any instances of that data type with the same value are considered to be equal instances. For example a Date, a Vector, a Point may be considered as complex types, as two instances of a Date with the same property values cannot be distinguished ; A date does not have any intrinsic identity, it is a « primitive » class or complex type. (see #data-model

About the use of Classes or Exchange items, one goal is to distinguish the data from their use. does the data is sent through an event, is it an operation or a flow. (see #communication-model).

For instance, for the healthcheck, maybe it’s an healthcheck event that will not be sent at same frequency than another healthcheck event depending on which component is sent from or on which function it applies.
On the exchange item, it will be able to define the non functional property onto it. (pedioridicity)
So you would have several exchange items with different frequency but each composed of exchange item element typed by healthcheck.

About one or many exchange item elements, it depends on how the healthcheck data is gathered, composed or used on C component. Some samples:

  • gathered: does the healthcheck data sent to C is an heathcheck of all allocated functions of A at once, if so the EI (ExchangeItem) can be defined with x EIE (Exchange Item Element) ‘is alive’ as x bit,
  • gathered: does the healthcheck data send to C is an heathcheck of all allocated functions at same time, if so the EI can be defined with one element ‘are alives’, as a byte with a bit per function.
  • composed: does the healthcheck data is an ‘is alive and date’ per function and the date is provided by the same allocated function monitored and passed towards C as an EI with one EIE.
  • used: does the healthcheck data is an ‘is alive’ and the date is provided by another dedicated function of A and B and passed as another EIE of the EI, so two EIE and C component may compose them to a new data type.
  • used: does the healthcheck data is an ‘is alive’ and the date is provided within C component to create a ‘dated log data’ for log purpose, if so, one EI with one EIE is enough between A and C.

As you see it depends.

The thematic highlight about Data Modeling worth a try I think.

Regards