Aggregate of individual
In Part 2 we have EnumeratedSetOfClass, but we don't have something like a EnumeratedSetOfIndividual. Yet we do need that often in any context (box of 100 screws, team of 11 soccer players, etc) .
This topic shows how an aggregate of individuals can be modelled, in valid Part 2 constructs.
First the diagram of this application model:
aggregate of individually identified objects
At the bottom you see the usual composition diagram. But in a distributed world it is possible that more 'parts' would be added. In order to avoid that, or at least signal that, we can classify the 'whole' with a class that defines the number of allowable 'parts'.
We use for that the entity type ClassOfParticulateMaterial, in this example with an instance called 'AGGREGATE OF POSSIBLE INDIVIDUAL' with the subclass '2 BOLTS'. Using the entity type Cardinality we can define that the aggregate shall contain 2 possible individuals, expressed in a computer-interpretable manner.
NOTE - Which of the two attributes of the class of relationship is meant by end1 and which by end2 depends on the alphabetical order (in English) of the attribute names.
For an explanation of the cardinalities refer to this topic.
The template for each 'whole' - 'part' combination is:
In case you deal with bulk material (e.g. 9 bolts of a certain kind), where the bolts are not being recorded individually, you can use the following template:
counted aggregate of bulk material
When you have a Bill of Material or Purchase Order with one or more lines with counted bulk material, then use an instance of this template for each such line and use the ExpressInteger (here '9' ) and the definition or description of the class involved (here 'BOLT' ). What his template boils down to is that you express that you deal with a number of unidentified members of that class.