Background: A model can have associated weak and strong requirement models. During forward or backward chaining, these can instantiate strong or weak requirements. If there is a matching weak requirement, then the model can be instantiated, but if there is also a matching strong requirement then this prevents it being instantiated. ("Being instantiated" means that if there is a matching LHS then the model can fire.) The method retrieve_imdl_fwd examines the weak and strong requirements which are attached to a model and returns the "chaining status" which can be one of the following:
These have ascending value for allowing the model to be instantiated. Only the last two (WEAK_REQUIREMENT_ENABLED and NO_REQUIREMENT) allow the model to be instantiated. The others give reasons why the model can't be instantiated. The "normal" case is WEAK_REQUIREMENT_ENABLED where a model only has an associated weak requirement model and there is a matching weak requirement so that the model can be instantiated. (If there is no matching weak requirement model then the status is WEAK_REQUIREMENT_DISABLED and the model is not instantiated). An interesting case is where there are no associated weak or strong requirement models (which is the case for most requirement models themselves). In this case the chaining status is NO_REQUIREMENT and the firing of the model only depends on a matching LHS.
Another interesting case is if the model only has associated strong requirement models but no weak requirement models. If there is a matching strong requirement, then obviously the model should not be instantiated and the chaining status is STRONG_REQUIREMENT_NO_WEAK_REQUIREMENT. But what if there are no matching strong requirements? In this case, the model should be instantiated and the chaining status is currently set to WEAK_REQUIREMENT_ENABLED. The problem is that there are no weak requirements. In this case it seems that the chaining status should be the same as the other case where there are no associated weak requirement models, which is NO_REQUIREMENT.
This pull request has two commits. The first commit updates retrieve_imdl_fwd (and the other related methods) to return a chaining status of NO_REQUIREMENT if the model only has associated strong requirement models but there are no matching strong requirements. As with the previously-used chaining status of WEAK_REQUIREMENT_ENABLED, this allows the model to be instantiated.
(Note: There is a technical question which must be addressed: An imdl has a parameter called wr_enabled for "weak requirement enabled". Some parts of the code set this based on the chaining status, for example:
case WEAK_REQUIREMENT_ENABLED:
f_imdl->get_reference(0)->code(I_HLP_WEAK_REQUIREMENT_ENABLED) = Atom::Boolean(true);
What is wr_enabled and how is it used? One comment from the original code says "wr_enabled: true if there is at least one weak requirement stronger than at least one strong requirement". Clearly, if there are no attached weak requirement models then wr_enabled doesn't need to be true. So it's OK for the chaining status to be NO_REQUIREMENT in this case.)
The second commit clarifies another case relating non-simulated and simulated requirements when there are only associated strong requirement models. In this case retrieve_imdl_bwd returns STRONG_REQUIREMENT_NO_WEAK_REQUIREMENT meaning that there is a matching strong requirement (and the model should not be instantiated). But the model controller continues to call retrieve_simulated_imdl_bwd to check for simulated strong requirements. When there are no matching simulated strong requirements this returns NO_REQUIREMENT as explained above. This alone would allow the model to be instantiated, but the matching strong requirement should prevent being instantiated. This commit updates the logic in this case so that the chaining status remains STRONG_REQUIREMENT_NO_WEAK_REQUIREMENT and the model is not instantiated.
Background: A model can have associated weak and strong requirement models. During forward or backward chaining, these can instantiate strong or weak requirements. If there is a matching weak requirement, then the model can be instantiated, but if there is also a matching strong requirement then this prevents it being instantiated. ("Being instantiated" means that if there is a matching LHS then the model can fire.) The method
retrieve_imdl_fwdexamines the weak and strong requirements which are attached to a model and returns the "chaining status" which can be one of the following:These have ascending value for allowing the model to be instantiated. Only the last two (
WEAK_REQUIREMENT_ENABLEDandNO_REQUIREMENT) allow the model to be instantiated. The others give reasons why the model can't be instantiated. The "normal" case isWEAK_REQUIREMENT_ENABLEDwhere a model only has an associated weak requirement model and there is a matching weak requirement so that the model can be instantiated. (If there is no matching weak requirement model then the status isWEAK_REQUIREMENT_DISABLEDand the model is not instantiated). An interesting case is where there are no associated weak or strong requirement models (which is the case for most requirement models themselves). In this case the chaining status isNO_REQUIREMENTand the firing of the model only depends on a matching LHS.Another interesting case is if the model only has associated strong requirement models but no weak requirement models. If there is a matching strong requirement, then obviously the model should not be instantiated and the chaining status is
STRONG_REQUIREMENT_NO_WEAK_REQUIREMENT. But what if there are no matching strong requirements? In this case, the model should be instantiated and the chaining status is currently set toWEAK_REQUIREMENT_ENABLED. The problem is that there are no weak requirements. In this case it seems that the chaining status should be the same as the other case where there are no associated weak requirement models, which isNO_REQUIREMENT.This pull request has two commits. The first commit updates
retrieve_imdl_fwd(and the other related methods) to return a chaining status ofNO_REQUIREMENTif the model only has associated strong requirement models but there are no matching strong requirements. As with the previously-used chaining status ofWEAK_REQUIREMENT_ENABLED, this allows the model to be instantiated.(Note: There is a technical question which must be addressed: An
imdlhas a parameter calledwr_enabledfor "weak requirement enabled". Some parts of the code set this based on the chaining status, for example:What is
wr_enabledand how is it used? One comment from the original code says "wr_enabled: true if there is at least one weak requirement stronger than at least one strong requirement". Clearly, if there are no attached weak requirement models thenwr_enableddoesn't need to be true. So it's OK for the chaining status to beNO_REQUIREMENTin this case.)The second commit clarifies another case relating non-simulated and simulated requirements when there are only associated strong requirement models. In this case
retrieve_imdl_bwdreturnsSTRONG_REQUIREMENT_NO_WEAK_REQUIREMENTmeaning that there is a matching strong requirement (and the model should not be instantiated). But the model controller continues to callretrieve_simulated_imdl_bwdto check for simulated strong requirements. When there are no matching simulated strong requirements this returnsNO_REQUIREMENTas explained above. This alone would allow the model to be instantiated, but the matching strong requirement should prevent being instantiated. This commit updates the logic in this case so that the chaining status remainsSTRONG_REQUIREMENT_NO_WEAK_REQUIREMENTand the model is not instantiated.