#241 Incorrect property types for some identifiers

[Phil Spiby]

The Effectivity subtypes LotEffectivity and SerialEffectivity use identifiers to identify which objects are effective. However, these identifiers should be reference properties, since they are NOT the identifiers belonging to the effectivity, but to other objects. In the case of SerialEffectivity it is assumed that the two identifiers are owned by instances of ProductAsIndividual. For LotEffectivity I am not sure what owns the identifier (a ProductGroup or a Collection), but again it should not be the LotEffectivity.

[Phil Spiby]

Looking into this problem has identified that both these entities/blocks use collections of identifiers which is causing some confusion. For example, what does LotEffectivity.lotId with a value ['foo', 'bar'] mean? Does it mean a lot with both these identifiers or does it mean a union of the lots with identifiers either 'foo' or 'bar'. A similar problems exists for SerialEffectivity.

I would like to propose that we just use single identifiers in both these entities since meaning of multiple identifiers is not defined in the description/definition.

[Rob Bodington]

Agree - For lot effectivity you also have a lotSize [1] - if the lotId was to identify mutliple lots, as opposed to mutlipe identifierd for the same lot - you woudl have the same problem.

The SerialEffectivity represents a range of serial numbers so It does not make sense to have multiple starts and ends.

So the identifiers should have cardinality [1] and be reference properties.

However, there is an assumption that the serialeffectify is referencing an existing Id of a ProductAsIndividual, or a reserved Id ie an identifier for a product not yet realised

Where the identifier is "reserved" it will need to be related to the identifier that is actually being used to identify say the productasinfividual when the productasindividual is created.

[Phil Spiby]

Checking in dvlp/plcs_psm.uml;
/cvsroot/plcslib/plcslib/data/PLCS/psm_model/dvlp/plcs_psm.uml,v <-- plcs_psm.uml
new revision: 1.17; previous revision: 1.16
done
Checking in dvlp/plcs_psm.ump;
/cvsroot/plcslib/plcslib/data/PLCS/psm_model/dvlp/plcs_psm.ump,v <-- plcs_psm.ump
new revision: 1.21; previous revision: 1.20
done
Checking in dvlp/plcs_psm_module.mdxml;
/cvsroot/plcslib/plcslib/data/PLCS/psm_model/dvlp/plcs_psm_module.mdxml,v <-- plcs_psm_module.mdxml
new revision: 1.84; previous revision: 1.83
done
Checking in images/SysML_Block_Definition_DiagramDiagramsEffectivity.png;
/cvsroot/plcslib/plcslib/data/PLCS/psm_model/images/SysML_Block_Definition_DiagramDiagramsEffectivity.png,v <-- SysML_Block_Definition_DiagramDiagramsEffectivity.png
new revision: 1.26; previous revision: 1.25
done
Checking in plcs_psm.exp;
/cvsroot/plcslib/plcslib/data/PLCS/psm_model/plcs_psm.exp,v <-- plcs_psm.exp
new revision: 1.101; previous revision: 1.100
done
Checking in plcs_psm.sch;
/cvsroot/plcslib/plcslib/data/PLCS/psm_model/plcs_psm.sch,v <-- plcs_psm.sch
new revision: 1.48; previous revision: 1.47
done
Checking in plcs_psm.xmi;
/cvsroot/plcslib/plcslib/data/PLCS/psm_model/plcs_psm.xmi,v <-- plcs_psm.xmi
new revision: 1.96; previous revision: 1.95
done
Checking in plcs_psm.xml;
/cvsroot/plcslib/plcslib/data/PLCS/psm_model/plcs_psm.xml,v <-- plcs_psm.xml
new revision: 1.97; previous revision: 1.96
done
Checking in plcs_psm.xsd;
/cvsroot/plcslib/plcslib/data/PLCS/psm_model/plcs_psm.xsd,v <-- plcs_psm.xsd
new revision: 1.96; previous revision: 1.95
done