About cardinality of ThermalComponents

[gioagu]

So far, each ThermalBounday MUST have at least one ThermalComponents. If I use a single ThermalComponent, I can define the area and - e.g. by Construction - how it is made. If I use two ThermalComponents, I may define how many m^2 are wall and how many are glazing.

However, if I do not have this information, but just the ThermalBoundary, I still need to generate at least one ThermalComponent for each ThermalBoudary. This makes sense if I am using the data as input for simulation software, but (sometimes) not if I simply want to transfer data.

Imagine I have a city with 1000000 ThermalBoundaries and no other information. My XML file needs 1000000 ThermalComponents to be valid. But do I really need them? I will generate the ThermalComponents depending on the type of library I am using (e.g. from where I get the window_to_wall ratio and the construction) in order to feed the simulation tool, but do I really need to store this information in advance?

Maybe the cardinality from ThermalBoundary to ThermalComponent could be relaxed to 0..n. If so, I would also add an area attribute also to the ThermalBoudary object.

[JoachimBenner]

Im agree. The relation composedOf (ThermalBoundary -> ThermalComponent) should be optional, and a new (optional) attribute area (Type Area) should be introduced in ThermalBoundary. Additionally, we can formulate a conformance requirement that this new attribute shall not be used in case a ThermalBoundary is related to one or more ThermalComponents.

[RomainNouvel]

Agree also.

[JoachimBenner]

Delete Boolean attributes in ThermalComponent, change cardinality to 0..* Add optional attribute "area" in ThermalBoundary. Mention base attribute "relativeToTerrain" in guidelines.

[oliviertournaire]

Implemented in latest version of the UML model